Salesforce Anti-Patterns E-Book

Lars Malmqvist

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 430

Veröffentlichungsjahr: 2025

Beschreibung

While Salesforce is a powerful platform, it is prone to common pitfalls that can result in suboptimal performance, increased costs, and reduced user satisfaction. Known as anti-patterns, these problems can arise from design flaws, poor implementation choices, or a lack of understanding of best practices.
Written by a seasoned Salesforce professional and 33-time certified Salesforce Certified Technical Architect, this revised edition will teach you how to identify and avoid common issues, optimize your Salesforce architecture, and ensure successful implementation. This second edition is updated with a comprehensive exploration of Salesforce, along with the addition of the most common Salesforce anti-patterns, providing in-depth analysis and practical solutions. These key learnings will further refine your skills to help you build more robust, scalable, and efficient Salesforce architectures. The chapters offer an expanded coverage of emerging technology trends such as AI and DevOps, updated examples, and additional case studies to ensure that you have the latest information and insights.
By the end of this book, you’ll have gained the confidence and expertise needed to design and implement effective Salesforce solutions.

Leseprobe

Salesforce Anti-Patterns

Build resilient Salesforce solutions using expert advice to create robust and efficient programs

Lars Malmqvist

Salesforce Anti-Patterns

Copyright © 2025 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Aaron Tanna

Publishing Product Manager: Kushal Dave

Senior Editor: Nisha Cleetus

Technical Editor: Vidhisha Patidar

Copy Editor: Safis Editing

Associate Project Manager: Manisha Singh

Proofreader: Nisha Cleetus

Indexer: Pratik Shirodkar

Production Designer: Ponraj Dhandapani

Business Development Executive: Saloni Garg

First published: November 2022

Second edition: January 2025

Production reference: 1131224

Published by Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1RB, UK.

ISBN 978-1-83546-784-8

www.packtpub.com

To Damiana, Ada, and Pino. To my mother, Inger Bejder, and the memory of my father, Finn Malmqvist.

– Lars Malmqvist

Contributors

About the author

Lars Malmqvist has spent the past 16 years working as an architect and CTO within the Salesforce ecosystem. He has worked on over 40 Salesforce implementations, ranging from simple out-of-the-box scenarios to advanced, bespoke, multi-cloud solutions for large global brands. He is a 33-time certified Salesforce CTA with degrees in anthropology, mathematics, and technology management, an MBA from the University of Cambridge, and a Ph.D. in computer science from the University of York. Currently, he is a partner at Implement Consulting Group.

I would like to thank my wife, Damiana, for her undying support, and my children, Ada and Pino, for their constant inspiration.

About the reviewers

Ashvin Bhatt is an enterprise architect, technical writer, trainer, and speaker with over 11 years of experience with the Salesforce platform working on various clouds. He has trained over 600 people on Salesforce through various initiatives. He is a certified Application Architect and holds a wealth of experience with various Salesforce products. Ashvin is the co-organizer of the Salesforce Architect Summit and has been a speaker at various events, such as Dreamforce and TDX. He has worked in a variety of domains, such as high tech, advertising, manufacturing, healthcare, insurance, and pharma, to name a few. He believes in sharing his knowledge through community-led initiatives to help foster learning and innovation.

Rafael Gutiérrez Castillo is a Salesforce Architect with multi-cloud implementation experience. With more than 10 years of working experience, he started his career in the education industry, developing leadership programs for university students.

He has worked in different positions within the Salesforce ecosystem, as a business consultant, tester, solution consultant, and solution architect.

Working as an associate manager at Accenture, he designs solutions that bridge the gap between business processes and technology and advises companies on their digitalization and transformation journeys. Being the proud owner of 24 Salesforce certificates, he is passionate about automation processes, solution design, process management, innovation, and leadership.

Table of Contents

Preface

Part 1: Technical Anti-Patterns

1

Why Do We Need to Understand Salesforce Anti-Patterns?

Understanding anti-patterns

From pattern to anti-pattern

Where do anti-patterns come from?

An anti-pattern template

How can anti-patterns deepen your architectural skills?

How great architects learn from mistakes

An example – the Hero anti-pattern

Hero (development life cycle and deployment planning)

Analyzing the example

Summary

2

How to Keep Your System Architecture Clean

Muddling up the systems landscape

Stovepipe

Architecture as Requirements

A Big Ball of Mud

Too much coupling

Intense coupling

Org complications

Ungoverned Org Proliferation

Knowing the takeaways

Summary

3

How Not to Get Confused about Security

Getting confused about shared responsibility

Shared Belongs to Salesforce

Mistaking other things for security

Compliant Is Secure

Declarative Is Always Safe

Sharing isn’t always caring

Spaghetti Sharing Model

Knowing the takeaways

Summary

4

What Not to Do about Data

Mistaking Salesforce for a regular database

Salesforce as a Relational Database

Forgetting about governance

Disconnected Entities

Unplanned Growth

Synchronizing excessively

Unconstrained Data Synchronization

Too much AI is not always a good thing

Let’s Add AI to It

AI Architecture Is Like Normal Architecture

Knowing the takeaways

Summary

Part 2: Solution Anti-Patterns

5

Unpicking Solution Architecture Troubles

Picking the wrong thing

Ignoring the Ecosystem

License-Based Solutioning

Applying the thing wrong

Assumption-Driven Customization

Golden Hammer

Engineering overflow

Automation Bonanza

Overweight Component

Making a mess of code

God Class

Error Hiding

Knowing the takeaways

Summary

6

Keeping Integration Straight

Messing up the integration landscape

Middleware in name only (MINO)

Service proliferation syndrome

Interfacing indecently

Fat interface

Chatty integration

Getting the patterns wrong

Integration pattern monomania

Event hell

Example

Problem

Proposed solution

Results

Better solutions

AI’s impact on integrations

Knowing the takeaways

Summary

Part 3: Process and Communication Anti-Patterns

7

Keeping the Development Life Cycle from Going Off Track

Misaligning the process

Big-Bang Release

Project Pieism

Infrequent Check-In

Unpacking the pipeline

Using Packages to Create Silos

Testing without testing

Dummy Unit Tests

The challenge of DevOps integration

Knowing the takeaways

Summary

8

Communication without Mistranslation

Communicating too much

Cognitive overload

Being unclear in several ways

Ambiguous solution

Groundhog Day

Drawing diagrams with excess creativity

Non-standard documentation

Mismanaging change

Ignoring stakeholder concerns

Example

The problem

Proposed solution

Results

Better solutions

Underestimating the impact of change

Example

The problem

Proposed solution

Result

Better solutions

Knowing the takeaways

Summary

9

Conclusion

Summarizing the key messages

Explaining how to use anti-patterns in practice

Using anti-patterns constructively

Going further with anti-patterns

Diving deeper into the anti-pattern literature

Extending your knowledge of Salesforce architecture

Extending your general architecture knowledge

Summary

Index

Other Books You May Enjoy

Preface

Salesforce is the world’s leading enterprise systems platform. This is a position it has reached over the last decade, with its scope having grown from its roots in sales and customer service to encompass a wide range of business domains.

However, as Salesforce has grown, so have the complexities of the technological environments that contain it. And with that growing complexity, a number of common mistakes have emerged that often end up derailing Salesforce projects in a number of interesting ways.

These mistakes are what we will learn to call anti-patterns and investigate in a structured manner in this book. There are quite a few books on Salesforce architecture already available on the market today, but they all approach the subject from a normative view, grounded in good practice.

In this book, we flip that perspective around. We look at bad practices that commonly occur in Salesforce projects, and that, in fact, can seem like a good idea at the time you make the decision.

By doing that, we see what happens when things don’t go to plan – when you don’t make the right call, and your solution suffers as a consequence. That gives a great background for us to review key architectural concepts and good practices as they apply across a range of scenarios.

In this book, you will get information structured into the seven domains of the Certified Technical Architect (CTA) exam roadmap. That way, while all the information is based on real-world examples, you will also be able to directly apply it in your journey to becoming a CTA, should that be a path you are on or are considering.

In this second edition, we have included many new anti-patterns as well as updates to the existing content. In particular, we have included sections and references about the increasing use of artificial intelligence and DevOps in the Salesforce ecosystem.

Who this book is for

This book is for anyone who has a position of responsibility in a Salesforce implementation and wants to see it avoid the common mistakes that plague many projects. While the primary audience is architects or aspiring architects, it will also be of value for project managers, business analysts, functional consultants, and executives overseeing Salesforce projects.

What this book covers

Chapter 1, Why Do We Need to Understand Salesforce Anti-Patterns?, starts by explaining what anti-patterns are by going through a number of different definitions and ways of looking at them. You will then learn how they can help you deepen your understanding of architecture by understanding how these common mistakes are made and how they can seem like a good idea at the time. We then finish the chapter by understanding the book and the ways in which you can approach the content.

Chapter 2, How to Keep Your System Architecture Clean, guides you through common anti-patterns relating to the systems landscape, the mix of systems you use in your solution, and how they can be combined. We will start by looking at anti-patterns at the highest level that describe problems around the composition and scoping of systems. Then we will look at anti-patterns that create highly coupled and brittle system landscapes, after which we will look at anti-patterns around selecting the right systems to include. The chapter will end with a review of the key takeaways for real life and the CTA Review Board.

Chapter 3, How Not to Get Confused about Security, includes anti-patterns related to securing your Salesforce org. It starts by reviewing a key anti-pattern around the shared security model that is integral to Salesforce. Then we will look at anti-patterns that can occur when you mistake other things for security. We will continue to look at how not to make a mess of your sharing model and once again finish up with a review of the takeaways.

Chapter 4, What Not to Do About Data, contains anti-patterns related to data architecture, modeling, and governance. We will start by looking at what goes wrong when you don’t design with Salesforce’s object model in mind. Then we will look at some of the common governance disasters that can happen around data. From there, we will look intently at data synchronization and the ways in which it can go wrong, and finish up with takeaways for life and the CTA Review Board.

Chapter 5, Unpicking Solution Architecture Troubles, covers anti-patterns related to your solution architecture. We will start by looking at anti-patterns related to your choice of solutions. Then we will look at things that can go wrong when you do functional design. Thirdly, we will look at some particular anti-patterns that affect customizations, first at the conceptual level and then at the code level. We will end the chapter by summarizing the key takeaways.

Chapter 6, Keeping Integration Straight, looks at anti-patterns around your integrations with other systems. The first part of the chapter looks at anti-patterns around the integration landscape and integration patterns. The second part looks at what can go wrong in the design and use of interfaces, and the third zooms in on problems with particular integration styles such as event-based architectures and batch transfers. As always, we end the chapter by distilling the key takeaways.

Chapter 7, Keeping the Development Life Cycle from Going off Track, looks at anti-patterns related to areas such as development process, governance, and DevOps. We will start by tackling a few significant process-level anti-patterns and then move on to a couple that deal with DevOps and packaging. Finally, we will tackle a common and very unfortunate anti-pattern related to testing. At the end of the chapter, we will summarize the key takeaways for real life and the CTA Review Board.

Chapter 8, Communication without Mistranslation, deals with anti-patterns centered around the way you communicate architecture to different audiences. The first part relates to anti-patterns that relate to information control. Then we look at a few anti-patterns that relate to the clarity of your communication. Thirdly, we look at an anti-pattern specifically about the way you create architectural artifacts. As we’ve been doing all along, we will end the chapter by summarizing our key takeaways.

Chapter 9, 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 progress further in this direction.

To get the most out of this book

This book is intended for anyone who has a stake in making Salesforce projects successful. While some of the technical chapters will make assumptions about general technical knowledge and experience, the only real precondition is a general knowledge of and interest in the Salesforce platform.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “Pranit, one of the Salesforce architects, makes a proposal to simplify the current system architecture by creating a CentralDispatch Apex class that will take the role of dispatching calls to other code or flow.”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Salesforce Anti-Patterns, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/978-1-83546-784-8

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1: Technical Anti-Patterns

This part will teach you how to identify and mitigate anti-patterns in the technical domains of system architecture, data architecture, and security architecture.

This part has the following chapters:

Chapter 1, Why Do We Need to Understand Salesforce Anti-Patterns?Chapter 2, How to Keep Your System Architecture CleanChapter 3, How Not to Get Confused about SecurityChapter 4, What Not to Do About Data

1

Why Do We Need to Understand Salesforce Anti-Patterns?

Salesforce anti-patterns tell us about the kinds of systematic mistakes that make their way into many Salesforce projects – mistakes that can even seem like a good idea at the time of implementation but end up having serious drawbacks in the long run. We’ll learn about the most common types of mistakes and how to think about them throughout this book. However, to do so, we must understand what anti-patterns are and how understanding them can help us architect and design better systems.

In consequence, this chapter will start by explaining what anti-patterns are by going through several different definitions and ways of looking at them. Then, you’ll learn how they can help you deepen your understanding of architecture by knowing how these common mistakes are made and how they can seem like a good idea at the time. We’ll finish this chapter by explaining what will be covered in this book and how you can approach the content provided.

In this second edition, we’ve expanded our exploration of Salesforce anti-patterns to include new patterns and insights that address the latest trends and developments in the Salesforce ecosystem. These additions are based on feedback from readers of the first edition and our ongoing research into the evolving landscape of Salesforce architecture. Notably, we’ve included new patterns related to AI and DevOps practices, such as “AI architecture is like normal architecture” and “Let’s add AI to it,” as well as updates to existing patterns to reflect the current best practices.

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

Understanding anti-patternsWhere do anti-patterns come from?How can anti-patterns deepen your architectural skills?Learning about anti-patterns from an example

Understanding anti-patterns

Most developers and architects will be familiar with the concept of a pattern – a good solution to a recurring problem within an architectural domain described in a formalized and reusable way. Some classic examples are as follows:

Singleton: A software design pattern that limits the number of instances of a given type to 1Fire-and-forget: An asynchronous integration pattern that sends off a message from a computational context and proceeds without waiting for a responseModel-View-Controller (MVC): An architectural pattern that divides an application into three tiers with specifically defined responsibilities:First, a model maintains the state of the application and is responsible for any changes to data.Second, a view shows a particular representation of that model to an end user via some interface.Third, a controller implements the business logic that responds to events in the user interface or changes in the model and does the necessary mediation between the view and the model.

This pattern is shown in the following diagram:

Figure 1.1 – MVC pattern diagram

Patterns such as these have been defined at many levels of abstraction and for many different platforms.

References

Take a look look at the following resources to get a good introduction to the various patterns that you can apply from a Salesforce perspective:

The integration patterns guide lists all the main patterns you should use when designing Salesforce integrations: https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_intro_overview.htm. In a Salesforce world, this may be the most commonly referenced set of patterns as they’re ubiquitous for integration design.

The book Apex Design Patterns from Packt, by Anshul Verma and Jitendra Zaa, provides patterns at the software design level and the concrete code level for the Apex language.

The Salesforce Architects site, while new, contains a range of patterns across domains, from code-level specifics to reference architectures and solution kits to good patterns for selecting governance: https://architect.salesforce.com/design/#design-patterns.

The point is that we have lots of good patterns to choose from on the Salesforce platform, many of which are provided by Salesforce themselves, though others are provided by the wider community. Many patterns that apply to other platforms are also relevant to us and we learn much by studying them.

But this is a book about anti-patterns, not patterns. So, why am I starting with a discussion about patterns? It turns out that the two are nearly inseparable and originate in the same tradition. So, understanding anti-patterns begins with understanding what a pattern is. One common form of anti-pattern is a design pattern that has been misapplied. We’ll explore this in the next section.

From pattern to anti-pattern

The design pattern movement in software architecture originates from the work of Christopher Alexander, an architect whose job was to design buildings rather than systems. In his work The Timeless Way of Building, he introduced a pattern template for physical architecture that consisted of a name, a problem statement, and a solution in a standardized format.

The rhetorical structure provided by the Alexandrian template was rapidly adopted by architects of a different kind – the ones that build software. They recognized the power of a standardized way to describe problem-solution sets for communicating good practice. With the publication of the classic Gang of Four book, Design Patterns: Elements of Reusable Object-Oriented Software, the use of patterns became mainstream within software development and remains so to this day.

The research on patterns inspired an incipient community of practitioners and researchers in software engineering to think about failure modes of software systems analogously to how design patterns were being used. This happened over an extended period, and it isn’t possible to point to anyone in the anti-patterns movement who can be seen as the genuinely foundational figure.

However, many research papers on this topic start with the definition given by Andrew Koening in Journal of Object-Oriented Programming in 1995. This definition says that an anti-pattern is very similar to a pattern and can be confused for one. However, using it doesn’t lead to a solution; instead, it has negative consequences.

This definition captures much of the essence and can be combined with the following thoughts from Jim Coplien, another early pioneer. He thought that good patterns in and of themselves weren’t sufficient to define a successful system. You also have to be able to show that anti-patterns are absent.

So, in a nutshell, an anti-pattern is a pattern that occurs in unsuccessful software systems or projects that can look superficially like a good solution but, in practice, gets you into trouble. The following are some common anti-patterns that have been around for ages and are still relevant:

Stovepipe: A system or module that’s effectively impossible to change because of how its interfaces are designed. See the following diagram for an illustration:

Figure 1.2 – The Stovepipe anti-pattern

Blob: A design where a single class effectively encapsulates all the business logic and functionality, leading to major maintenance headaches.Intensive coupling: A design that uses an excessively large number of methods from another class or module in implementing a feature, leading to a deep dependency that’s hard to understand or change.

We’ll dig into all these anti-patterns from a Salesforce perspective in later chapters, underscoring the unfortunate fact that Salesforce, while a great platform, is still a software system that’s prone to the kind of mistakes that have plagued software systems for decades. If this weren’t the case, then there’d be no need for this book – or Salesforce architects, for that matter.

In addition to having a foundational understanding of anti-patterns, it’s crucial to recognize how these patterns align with the latest trends in the Salesforce ecosystem. With the growing interest in AI and DevOps, new anti-patterns have emerged that specifically address challenges in these areas. For instance, the “Let’s add AI to it” pattern warns against the temptation to incorporate AI into solutions without a clear, justified need, leading to unnecessary complexity and maintenance challenges.

DevOps practices have also introduced new anti-patterns, such as “Infrequent check-in,” which underscores the risks of not integrating code changes frequently enough, leading to integration hell and deployment issues. By understanding these new trends and their associated anti-patterns, architects can better navigate the complexities of modern Salesforce implementations.

Having discussed the historical origins of anti-patterns, let’s discuss how they arise in the real world.

Where do anti-patterns come from?

Anti-patterns tend to arise again and again because the circumstances that drive technology projects into trouble are at least somewhat predictable. Equally predictable are the responses of people put into those situations. Since people in tough spots frequently make the same bad decisions, we get systematic patterns to study.

Generally speaking, the most important thing to remember about anti-patterns is that they seem like a good idea at the time. They aren’t simply bad practices that someone should know better than to apply. You can make a reasoned argument that they should lead to good or at least acceptable outcomes when applied.

Sometimes, the decision to apply an anti-pattern is down to inexperience, while other times, it’s down to desperation. But as often as not, it’s down to experienced professionals convincing themselves that in this case, doing what they’re doing is the right call or that this situation is different.

Anti-patterns often arise from predictable circumstances in technology projects, but recent technological trends have introduced new contexts in which these patterns manifest. For instance, the rapid adoption of artificial intelligence (AI) and machine learning in Salesforce projects has led to the emergence of new anti-patterns, such as “AI architecture is like normal architecture.” These patterns often arise from a lack of understanding of the unique requirements and challenges associated with integrating AI into Salesforce solutions.

Similarly, the shift toward DevOps practices has highlighted new anti-patterns related to continuous integration and deployment. The “Infrequent check-in” pattern, for example, arises when teams fail to integrate code changes frequently, leading to significant integration challenges and deployment delays.

We’ll try to reflect this diversity of origins in the examples we’ll provide throughout this book. However, to do this, we need to explain how we’ll present the examples in a consistent way to enable learning.

An anti-pattern template

One of the key characteristics of both patterns and anti-patterns is that they’re written using a recognizable template. Many templates have been suggested over the years, with some more elaborate than others.

The template we’ll use in this book contains the bare bones that recur in nearly all existing anti-pattern templates. However, we won’t include a great number of optional elements. Most additional elements that are included in other templates serve to ease categorization or cross-referenceability. Those are highly desirable elements to have when creating a searchable catalog of patterns or anti-patterns but are less useful in a printed book. Therefore, we’ll omit them and include the following elements instead:

Name: An easy-to-remember moniker for the pattern that serves to identify it uniquely and help with discourse among architects.Type: In this book, we’ll categorize our anti-patterns by the domain from the Certified Technical Architect (CTA) review board examination that they’re relevant to. This is both to help people on the CTA journey, but also because this is a familiar typology for Salesforce architects.Example: We’ll introduce each anti-pattern by giving an example of how it might occur. The examples will be fictional but grounded in real-world events. This will frame the anti-pattern and give you an immediate understanding of the issues involved before we delve deep into the nuts and bolts.Problem: This section describes the problem(s) that the anti-pattern purports to solve more formally. These are the real issues that the anti-pattern is meant to be a solution for, although using it in practice will turn out to be a bad idea.Proposed solution: How the anti-pattern claims to solve the problem described in the previous section and how that can be tempting to believe given certain circumstances.Results: In the results section, we’ll outline what results you can expect from applying the anti-pattern, along with its main variations. We’ll explain why this is a bad solution, although it might look good at the outset.Better solutions: The final section in the template will tell you what to do instead when you’re faced with the problem that’s the basis for the anti-pattern. Not all problems have easy solutions, but you can generally do better than applying an anti-pattern.

Now that we understand what anti-patterns are and how they’re going to be structured in this book, we’ll move on and explain how you, as an architect, can improve your skills by using them to learn.

How can anti-patterns deepen your architectural skills?

While a theoretical understanding of what patterns and anti-patterns are and how they may generally be helpful is great, you’re no doubt looking for more from this book than just a theoretical discussion.

In this section, we’ll go through the value of learning from mistakes, both your own and other people’s, and show you how we’re going to use anti-patterns to sharpen your architectural chops in the context of a concrete example.

How great architects learn from mistakes

We work in an industry where failure is a normal occurrence. The Standish Group CHAOS report, which is the most commonly cited source on these matters, in 2020 estimated that 66% of all technology projects globally ended in partial or complete failure.

This is a little bit better than when I started my career more than 20 years ago. Then, the figure stood in the low 70s. However, while things have improved, they’ve only improved a little bit, despite agile development, cloud computing, AI, and great software platforms such as Salesforce.

This is disheartening, but it only proves the point of one of my heroes, Fred Brooks, that “The complexity of software is an essential property, not an accidental one,” which unfortunately means that we’ll never find a silver bullet to solve all problems in software architecture and design. Instead, we’re faced with the hard work of learning how to manage this complexity reasonably. To do so is the principal job of an architect.

It stands to reason that in an area with high failure rates and irreducible complexity, we need to have good rules and guidelines to keep us on the right path. That is what patterns and best practices are for. They’re indispensable, but they’re not enough.

To become great at our profession and to be able to design software that bucks the industry trend, we need to not just learn from our failures but also from the vast repository of failed projects and bad practices we see all around us.

That usually isn’t hard to do. Often, when the architect is brought into a project, it’s because there’s already an issue to fix. Using these occurrences as learning opportunities and analyzing them with that view in mind can be greatly rewarding.

However, there’s a step further to go in this direction, which is what anti-patterns offer. They encompass how things frequently go wrong in a way that allows both post-hoc learning but also real-time intervention.

While projects can go wrong, they don’t do so randomly. There are systematic patterns that repeat time and again. Learning how things go wrong in systematic ways can give you an entirely new set of responses in your toolbox that you can deploy to help make your project one of the 34% that don’t fail.

Understanding anti-patterns not only helps you avoid common pitfalls but also enhances your ability to navigate the complexities of modern Salesforce architectures, including AI and DevOps practices. These insights are particularly valuable for those preparing for the CTA review board examination as they demonstrate a deep understanding of the challenges and best practices in modern Salesforce architecture.

We’ll start that learning journey with an explanatory example.

An example – the Hero anti-pattern

There’s no better way to start learning than using an example. We won’t have the chance to cover many general management-level anti-patterns in this book, so I’ll use one of the classics in this genre to show you how the template works and how to read it to get the most out of it.

First, we’ll present the anti-pattern and then provide an analysis of what we can learn from it.

Hero (development life cycle and deployment planning)

Tom is the project manager for a large greenfield Salesforce implementation in the manufacturing industry working with Sales and Service Cloud for 2,000 users. The project is meant to be quite simple – a basic MVP to get the platform off the ground – and that’s how it’s been scoped and staffed. The project is meant to go into full production after 6 months, with 4 months of implementation followed by testing, training, rollout, and hypercare.

The first 3 months of implementation fly by and everything on the project management dashboard stays green. The team makes steady progress and relations with the external consultancy that’s helping provide specialist resources remain good.

However, when Tom delivers the first round of business reviews, things start to change quickly. It turns out that a lot of detailed requirements have been missed from the initial scope and that many edge cases aren’t covered by the current configuration. The feedback from the business is that they won’t be able to go live with the system unless a large list of additional functionality is included.

Tom goes to the steering committee to ask for a bigger budget and a scheduled increase to accommodate the business demands. The steering committee grants the request for an increased budget but tells him that the schedule is immovable. He must find a way to get it done within the current timeline.

Tom replans the project from the ground up. He can make it all fit by compressing the testing and cutover plan if he adds some new resources from the external partner and asks for some overtime from his existing team. He sends out the new plan to the team, along with a rousing email calling on everyone to rise to the challenge.

Over the next month, the project slips again, and Tom’s new plan is looking less and less likely to succeed. It’s not that anything big goes wrong, but lots of little things just aren’t completed on time or need to be reworked because of misunderstandings. In particular, the new consultants he’s brought in from the external partner seem to make a lot of basic mistakes.

Tom calls his boss, the senior director for IT, to tell him about the situation and ask for help in getting an extension to the schedule. She tells him that the schedule has been committed to the board of directors of the company and that heads will roll if it isn’t met. She says that this is the time for the team to pull out all the stops and get it done.

Tom goes back to his team to relay the news and once again calls for everyone to give it everything they’ve got to get things over the line. Unfortunately, most people are already working as hard as their situations allow. In addition, relations with the external partner have soured and they’re not willing to put in additional hours without additional funding, which Tom doesn’t have in the budget.

There are some bright spots, however. In particular, two young members of the technical staff, Kayleigh and Negash, prove willing to go above and beyond to get things done. Over the final month of delivery, they work 24/7 on the project, with Tom cheering them on:

Figure 1.3 – The dangerous feeling you might have when engaging in the Hero anti-pattern

Between the two of them, they manage to clear away enough of the new features and change requests during the final stretch that Tom becomes confident that he’ll be able to meet enough of the requests for the project launch to not be a disaster. There will be exceptions, but he can find a way of managing those later. So long as the impending go-live goes well, the project can still succeed.

However, user acceptance testing (UAT) throws a spanner in the works as major quality issues are discovered. The steering committee holds a crisis meeting that ends up concluding that the go-live will have to be postponed for a week. The team will have to work flat out during this period to fix the issues.

While everyone pitches in, the responsibility falls disproportionately on Kayleigh and Negash, who are both starting to show the strain of their continuous effort. Tom encourages them at every chance and singles them out for public praise. He also promises them a cash bonus and extra holidays when the project is done.

The day for retesting arrives and while many issues have been fixed satisfactorily, there are quite a few remaining issues, including a good number that had previously been fixed and are now recurring.

The steering committee holds another crisis meeting and they decide to go ahead with the launch, despite the issues. These issues will need to be fixed during the hypercare period, but they can be tolerated for a short amount of time.

The next few weeks of Tom’s, Kayleigh’s, and Negash’s lives happen in a blur of constant motion. They’re pulled from escalation to escalation as issues occur, are fixed, and reoccur. Kayleigh and Negash start buckling under the pressure, but with no alternative resources knowing the configuration, they’re effectively forced to carry on.

Eventually, the issues settle down. The important bugs are fixed, the business puts manual workarounds in place for the things that were missed, and life starts to go back to normal. Tom calls the team for a victory celebration, but it’s a muted affair.

After taking their extra holidays, Kayleigh and Negash both accept offers from big consulting companies, leaving the company with no one to support large chunks of functionalities on their newly implemented platform.

Problem

The Hero anti-pattern generally purports to fix an urgent delivery problem that has occurred either in a project context, as in our example, or during normal operations. When it occurs in normal operational mode, this is often in a context where firefighting issues with the system have become a run-of-the-mill occurrence.

Usually, the problem occurs in a context characterized by some of the following factors:

There are limited resources to carry out the work needed to fix the urgent problem and there are good reasons why new resources can’t be brought in at this time.The project has a tight schedule that’s perceived to be set in stone or the issue is live, critical, and affecting important business users adversely in ways that cause a lot of noise.There’s knowledge about the problem concentrated in a small number of heads – that is, a few people, such as Kayleigh and Negash, who volunteered to take on the role, or frequently a lead developer who’s the only one with the technical knowledge to fix the issue at the given time.The situation is considered somehow special: either this is a new project and there isn’t a precedent, or the issue is considered so unique that you can’t plan for it.The crisis element is often quite visible in situations that foster the Hero anti-pattern. Sometimes, important parts of the company’s future success or even survival are brought into play.

These factors can all make the problem seem more important to fix in a limited time scale and make the Hero anti-pattern seem attractive.

Proposed solution

The Hero anti-pattern proposes to solve the problem described in the preceding section by allowing an individual or a small group to take too much responsibility for resolving it effectively by working as much as is required, even at some cost to themselves, to get things done.

This can be attractive both to management and to the people involved for a variety of reasons:

The effort does tend to produce some results in the short term, giving a sense of momentum and success.Everyone, or at least nearly everyone, wants to be a hero and be singled out for praise and rewards. To some people, that’s worth the inconvenience of the additional effort.It’s always possible to imagine that the current situation is somehow unique and not reflective of a deeper problem with process or culture within the organization, thereby justifying what’s done as exceptional.Even if we acknowledge that there are underlying issues, often, these can be put out of mind as something to be dealt with later. Of course, in organizations that rely on the Hero anti-pattern, later never comes.

There are several common variants of the Hero anti-pattern that are worth mentioning:

Superman, a variant where someone, usually a senior technical person, is glorified and held up as the only person who can fix serious issues with a given system. Often, this myth becomes self-perpetuating.Rookies, the variant shown in the preceding example, where junior team members take on extra responsibilities to step up to the challenge that’s being presented to them.No Time for Knowledge Transfer, a situation where heroics are required by a seemingly never-ending time crunch that would make it possible for the hero or heroes to transfer required knowledge to others.

While this anti-pattern is seductive, and many of us have fallen prey to it several times throughout our careers, it almost invariably has negative long-term consequences, something we’ll explore next.

Results

While the Hero anti-pattern tends to give good short-term results, which is a major source of its enduring appeal, there’s a long list of negative results that tend to accumulate over time in organizations that rely on this anti-pattern to get things done.

Some of the most common negative results are as follows:

The creation of a single point of failure that increases risks to an organization substantially, should the hero fall under the proverbial bus, and gives the hero a lot of leverage in negotiations with the organization.Over time, the hero will start to feel pressure, just like Kayleigh and Negash did in our example, but they’ll have very limited options to change the situation. This situation is highly conducive to burnout, which brings with it all the problems of the first point, as well as the risk of the hero making serious errors due to the strain.Heroes don’t scale. This means that the organization won’t be able to deploy projects at a bandwidth that’s wider than what the hero can accommodate. This can be seriously limiting to new initiatives in some cases.Heroes aren’t replicable. You can’t replicate the hero or their special powers easily, so you have limited options for creating a predictable and repeatable process.Heroes can accumulate serious technical debt. This may often go unmanaged because they must do things quickly, under pressure, and without real supervision. This can lead to major maintenance issues in the long term.There’s low transparency into the process by which heroes get things done, leading to a lack of predictability and manageability.Heroes don’t have time to explain how things were implemented, so there’s often poor or entirely missing documentation.The rest of the team may feel disempowered, overlooked, and demotivated as all the attention goes to the heroes, with little opportunity for others to make contributions in a non-heroic way.

You don’t necessarily see all these negative outcomes in all instances of this anti-pattern, and unfortunately, this list isn’t exhaustive either. But hopefully, this is enough to make you think twice about applying this anti-pattern and look at better options, something we’ll explore next.

Better solutions

The fundamental problem with the Hero anti-pattern is that you’re relying on specific individuals with often hidden knowledge working hard – usually too hard – to get things done rather than on repeatable, transparent, and manageable processes that will allow you to continue to deliver, even as the context and the people involved change.

So, the primary way to get away from the Hero anti-pattern is to work on your processes and spread skills and knowledge systematically across the team. In our example, there were potential issues with scope management, the initial discovery work, governance and its understanding of the real issues on the ground, and the way the project had been structured to go live with a big bang rather than in small increments.

How specific interventions will provide the most leverage will vary a lot between organizations, but some good aspects to look at are as follows:

Moving toward a DevOps culture with smaller incremental releases that have lower risk profilesHaving multi-functional teams with frequent direct collaboration and peer review to spread knowledge aroundEncouraging and rewarding leads and specialists more for mentoring and bringing up juniors rather than for putting out the latest fireIncorporating better risk management and governance in projects so that you can have the right contingencies in place when things go wrong, as they inevitably willChallenging the cultural norms that put primacy on delivering big dramatic wins against the odds, rather than on making steady, undramatic, but repeatable progress regularlyEmphasize roles and processes, not individuals when planning, building, and operating systems, especially when communicating with the wider stakeholder communityMake the costs of the Hero anti-pattern visible by capturing the technical debt, the risk, and the missed opportunity to be able to replicate efforts that the organization loses by relying on this patternEnsure that detailed requirements and edge cases are planned for when beginning the project to reduce the probability that you’ll need a hero

In truth, it isn’t always possible to completely avoid the Hero anti-pattern. Sometimes, things are on fire and there’s only one person around who can fix it. What we need to recognize is that this isn’t a good situation but an anti-pattern that we need to work hard to fix so that it doesn’t recur. The more you do this, the less you’ll have to rely on heroes and the fewer fires you’ll have to put out.

Having covered our first example of a real anti-pattern, let’s analyze it a little more deeply to see how we can maximize our learning from it.

Analyzing the example

The Hero anti-pattern is a classic and most seasoned IT professionals will have encountered it during their careers. However, interesting as it is, in this book, we’ll also be looking to pull out the larger patterns so that we can learn from our examples to hone our architectural skills.

Throughout this book, we’ll do this by having a section toward the end of each chapter that extracts key learning points for you to take on your future architecture journey. We’ll do this while implementing a mind-to-real-life practice, but we’ll also list learning points specifically for those who are on track toward the CTA exam.

Considering the Hero anti-pattern, the following are a few learning points you might extract for real-life practice:

When you’re faced with a crisis that calls for extraordinary effort on the part of some or all of the team, take the time to step back and consider the process failures that led to this situation. Capture this for future use.Relying on a small number of extremely skilled individuals can be dangerous in the long run, even if it’s useful right now.The pressure you might feel toward going above and beyond may reflect a culture that doesn’t have its priorities right from a technical point of view. You may want to challenge that if possible.Go out of your way to empower and bring up junior staff to avoid being in a position where you have to be the hero.Be diligent about advocating for good governance both at the project and technical levels, as well as capturing and remedying the technical debt that accumulates from “special” situations.

Looking at the CTA review board, you can note the following lessons:

Be careful about suggesting big-bang delivery approaches. They can be the right choice, but frequently, they can lead to the issues highlighted in this example. Prefer using agile, incremental approaches unless there’s a specific reason not to.Ensure that you include the necessary governance functions, including a project management office (PMO), steering committee, design authority, and maybe a change advisory board. In this example, much could have been avoided if the latter two had been in place.Be explicit about risks and risk management. Include risks upfront and be ready to talk about how to manage and mitigate them.

While we’ll be able to pull out many learning points directly, we encourage you to go further with this method and see how much more you can get out of them. Learning from anti-patterns is a continuous and very rewarding activity for aspiring architects.

In addition to the traditional lessons learned from the Hero anti-pattern, it’s important to consider how this pattern intersects with modern trends such as AI and DevOps. For instance, in a DevOps environment, the reliance on a single “hero” to manage deployments can lead to significant bottlenecks and integration issues, highlighting the importance of practices such as continuous integration and frequent check-ins.

Similarly, in AI projects, the Hero anti-pattern can manifest when a single data scientist or AI specialist is relied upon to deliver complex AI solutions without adequate support or knowledge transfer. This can lead to burnout and a lack of scalability, underscoring the need for collaborative, multi-functional teams.

With that, we have a foundational understanding of what anti-patterns are and how they can help us achieve greater mastery of Salesforce architecture. All that’s left to do is summarize our progress before we dive into the deep end by looking at anti-patterns in the system architecture domain.

Summary

Phew – that was a lot of background! Thank you for sticking with it. You’re now in a position to move forward with this book since you understand the key facts about what anti-patterns are and how you can learn from them.

Here are a few things to remember as you go into the next chapters:

It’s important not to simply think about anti-patterns as bad practices. Bad practice is obvious, but anti-patterns are nefarious. They masquerade as good solutions and can be persuasive in certain situations, even to experienced professionals. That’s also what makes them so fun to study.While we’ll be presenting a lot of individual anti-patterns in this book, it’s important to draw out the parallels and meta-patterns that can be gleaned by comparing and contrasting them. We’ll do some of that work for you in the analysis sections that can be found throughout this book. You should also try to do this activity for yourself.While we’ll be focusing on a Salesforce context, many of the patterns you’ll learn about apply to other platforms as well. Some are even classics that will be known by a great number of grizzled architects.

As we move forward with this book, remember that anti-patterns aren’t just bad practices but deceptive solutions that can seem appealing in certain situations. In this second edition, we’ve expanded our exploration to include new anti-patterns related to AI and DevOps that reflect the latest trends and challenges in the Salesforce ecosystem. By understanding these patterns and their implications, you can enhance your architectural skills and better navigate the complexities of modern Salesforce projects, whether in real life or in preparation for the CTA review board examination.

With that out of the way, we’re now ready to look at our first architectural domain in detail: systems architecture.