9

Conclusion

This conclusion gives a broad overview of the content of the book, including the overarching takeaways from the preceding chapters. It then explains how you can use the anti-pattern method and perspective in your own work to improve your architecture skills. Finally, it gives you pointers on how you can go to progress further in this direction.

In this chapter, we’re going to cover the following main topics:

• The key messages from the book – specifically, we will look at some underlying root causes of anti-patterns
• How to use anti-patterns in your own architectural practice to improve the quality of the architectures that you create
• How you can go to further your understanding of anti-patterns and develop your own architecture skills

After completing this chapter, you will have a good understanding of how further your own architectural development and know how to integrate antipattern-based thinking in your day-to-day practice as an architect.

Summarizing the key messages

In this book, we have covered dozens of anti-patterns across seven different architectural domains. However, it won’t have escaped the perceptive reader that many of the problems and suggested solutions are similar across several different patterns in seemingly different domains.

That indicates that, at a deeper level, anti-patterns have similar root causes that are often due to larger organizational or even psychological factors. Let’s look at some of these recurring causes:

• Wishful thinking: Several anti-patterns are based on some form of wishful thinking – that is to say, not wanting to confront the technical reality in front of you. In Project Pieism, it is an inability to confront trade-offs and uncertainty; in Golden Hammer, it’s an overoptimistic belief in a single tool; and in Unplanned Growth, it’s the belief that a solution can be found later. Always be wary of optimism in technical architecture.
• Systemic blindness: Many anti-patterns originate in an inability to see the entire system and focusing on a local solution to the detriment of the overall architecture. This includes anti-patterns such as Disconnected Entities, Ignoring the Ecosystem, and Using Packages to Create Silos, and more could be added. Forgetting about the overall sociotechnical system that you are working inside is a sure way to end up with anti-patterns.
• Replacing a simpler problem with the real problem: Quite a few anti-patterns originate in a wish to make things simple. Many architectural problems are wicked and allow only for solutions that are imperfect and highly complex. Often, that is not entirely satisfactory to stakeholders who cry out for an easy-to-understand answer, the giving of which often leads to an anti-pattern. Compliant Means Secure and Declarative Means Safe are two examples in the security domain, where we substitute a simple answer for a complex reality. But also, anti-patterns such as MINO, Assumption Driven Customization, and Big Bang Release have much of their background in this factor.
• Organizational constraints: Another very common underlying cause of anti-patterns is working to the constraints given by the current organizational setup you find yourself in. Whether it is because of silos within the organization, bad relations with vendors, or political games, the place in which you find yourself organizationally can sometimes lead or even force you down the path of an anti-pattern. This is true for anti-patterns such as Automation Bonanza and Stovepipe, and this is a secondary factor for many other anti-patterns.
• Weak technical governance: A lack of effective technical governance is another common cause of anti-patterns. When you don’t have any architectural authority or clear standards or conventions, you often get drift that results in anti-patterns. This includes many patterns, such as Intense Coupling, System Proliferation, and Unconstrained Data Synchronization.
• Lack of discipline: Finally, a number of anti-patterns boil down to a lack of discipline in the software development life cycle. This includes patterns such as Big Ball of Mud, Spaghetti Sharing Model, Fat Interface, and Dummy Unit Tests, among others. These are, to some extent, the simplest to deal with as the solutions are obvious, but the underlying pressures that drive teams towards taking the easy road can be much harder to deal with.

Looking at the underlying reasons why anti-patterns occur and finding the kinds of patterns that can explain many different ways in which projects go wrong is one of the most fruitful uses of anti-patterns.

We will now proceed to look at how you more concretely can use anti-patterns in practice to improve your architecture skills.

Explaining how to use anti-patterns in practice

If you’ve gone through this book cover to cover, you will have encountered a large number of patterns for how things can go wrong on a Salesforce project. We have structured this by architecture domain to facilitate your understanding and give you more context.

However, you may still be left with some questions about how to best go about applying this new storehouse of knowledge in your day-to-day work. We propose that there are two main ways in which you can proactively use your knowledge of anti-patterns to improve your architecture practice and hone your architecture skills:

• First, you can use it constructively as part of your architecture and design process
• Second, you can use it diagnostically as part of your approach to understanding architectures designed by others

We will now go through each of these alternatives in the following sections.

Using anti-patterns constructively

Using anti-patterns constructively means that you incorporate antipattern-based thinking in your normal architectural process. There are several ways you can do this from simply having a mental checklist of common anti-patterns that you validate your work against to a systematic check against all the anti-patterns that apply to the current stage of your architecture process.

We recommend a halfway house between these two extremes where you do the following:

1. At the beginning of your architecture process, you make an assessment against the six factors mentioned in the previous section. For each factor rate your environment for how much it is likely to impact your work on a standard 1-5 scale.
2. For all the factors you’ve rated 4 or 5 on the assessment, compile a list of the various anti-patterns that could potentially happen in your environment. Not all anti-patterns are applicable across the board, so be selective.
3. For those anti-patterns you have selected, make a check both during the initial design and regularly throughout the project to see if they are starting to occur.
4. If you start to see a drift towards a certain anti-pattern, take proactive steps as indicated under the Better solutions part of the pattern description.

That way, you are likely to catch the most common anti-patterns well before they manage to make their way into your solution. This approach works fine when you are in charge of the architecture, but what do you do when faced with an existing architecture? We will explore this next.

Using anti-patterns diagnostically

When you come into a brownfield environment as an architect, doing an analysis based on anti-patterns to diagnose the health of the existing architecture can be a very fruitful endeavor that we highly recommend. This analysis can inform both your understanding of the strengths and weaknesses of the current environment and also indicate ways in which you may start to refactor it.

We recommend you do the following:

1. Gather information from existing users and team members familiar with the existing environment, particularly the non-functional characteristics that are likely to indicate the presence of an anti-pattern.
2. Based on the information you gather, make a shortlist of potential anti-patterns that may be found in this architecture.
3. Perform a thorough check of the relevant technical artifacts to confirm or refute the presence of each anti-pattern.
4. Based on your findings, start looking at potential mitigations and assess the impact of the work that you have been brought in to do.

Having now covered the day-to-day use of anti-patterns, we will proceed to discuss where you can go from here in adding to your architecture knowledge.

Going further with anti-patterns

While there is much information in this book, obviously your architectural learning journey does not end here. We suggest that there are three pathways you may want to consider going forward:

• Diving deeper into the anti-pattern literature
• Extending your knowledge of Salesforce architecture
• Extending your general architecture knowledge

For each of these areas, we have selected a range of helpful resources that we will cover in the following sections.

Diving deeper into the anti-pattern literature

There are three resources we particularly recommend for getting even deeper into the concept of anti-patterns:

• The original book, AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by Raphael C. Malveau, William J. Brown, Hays W. “Skip” McCormick, and Thomas J. Mowbray. This book, while highly dated, was extremely important in formalizing and popularizing the concept of anti-patterns. Several of the anti-patterns found in this book can be traced back to this one.
• The best overall discussion of anti-patterns, both in general and of specific anti-patterns, can be found on WikiWikiWeb, https://wiki.c2.com/?AntiPattern.
• DevIQ has an excellent repository of anti-patterns that discusses many of the common ones that can be found across platforms, https://deviq.com/antipatterns/antipatterns-overview.

We will now proceed to look at how you might fruitfully combine knowledge of anti-patterns with deeper knowledge of Salesforce architecture.

Extending your knowledge of Salesforce architecture

One of the best ways to apply your newfound knowledge of Salesforce anti-patterns is to combine it with deeper knowledge of the key Salesforce architecture domains. We recommend the following books for that:

• First, we recommend Becoming a Salesforce Certified Technical Architect by Tameem Bahri for anyone that is on the CTA track or might consider it in the future. Like this book, it is structured by the CTA architecture domains and is therefore highly complementary.
• Another very good Salesforce architecture book is the Salesforce B2C Solution Architect’s Handbook by Mike King.
• For people with a special interest in the data domain, Salesforce Data Architecture and Management by Ahsan Zafar is highly recommended.

However, Salesforce architecture is only one aspect to consider. You should also consider extending your general architecture knowledge.

Extending your general architecture knowledge

While anti-patterns are important, we should also strive to improve our knowledge of architecture in general. Here are some resources to do that:

• First, we recommend the Solutions Architect’s Handbook by Saurabh Shrivastava and Neelanjali Srivastav, which gives a good introduction to many general architecture subjects
• For a general introduction to CRM and its architecture, we recommend The Art of CRM by Max Fatouretchi
• Finally, we recommend Multi-Cloud Architecture and Governance by Jeroen Mulder to get a good overview of the increasingly common multi-cloud architecture scenario

We have now covered the content of this chapter and the book and will finish with a final summary.

Summary

Well done, you made it! This was the last chapter of the book and you are now an official anti-pattern aficionado.

In this chapter, we have summarized the main points of the book. In particular, we looked at six underlying factors that are common to many anti-patterns and are part of their root causes.

These provide signposts that architects can use to create an awareness of what anti-patterns are likely to occur in a given architectural context and what measures may be taken to mitigate them.

In order to use this knowledge in practice, we outlined two different approaches to incorporating anti-patterns into your architecture process. First, we looked at how to use it constructively for your own architectures and then how to use it diagnostically for examining existing architectures.

Finally, we looked at where you might go from here in order to expand your knowledge further. We outlined three pathways you might take and gave some suggestions for books and other resources.

Anti-patterns is one of the most interesting areas of general architecture because they tell you how things go wrong in repeatable ways. Learning from the mistakes of others is usually a better idea than making all the mistakes yourself and I hope sincerely that reading this book will have made you much less likely to repeat these anti-patterns yourself as well as how to spot them when others in your context are about to make them.

Software systems are important. Organizations rely on them. Users spend much of their working life interacting with them. As architects, we have a responsibility to help avoid the common errors that keep them working less well than they could have done.