Creating powerful Salesforce architecture....

Hey Everyone!

Hope you had a great week.

I read a killer Salesforce book this week about creating powerful Salesforce architecture.

I thought you might enjoy thinking about these apply to you.

Book: Salesforce Anti-Patterns by Lars Malmqvist

Who wrote it?

The author, Lars Malqvist, is a Salesforce architect with 13 years experience and 29 certifications.

Most importantly, you can tell in the book he is a seasoned professional.

He goes through twenty-ish different Salesforce Anti-Patterns that, if you want to be a great Salesforce Architect, you should know.

Even if you're just starting out, learning what NOT to do when building Salesforce solutions will give you an edge.

What is an Anti-Pattern?

 Charlie Munger has a great quote:

 With anti-patterns, we learn where our Salesforce environment "goes to die" and then we too can "never go there".

We can invert our way to success. By avoiding the worst mistakes, we're way more likely to get a good outcome.

5 Surprising Examples

As I was reading I was surprised to see how many of these are traps I'd fallen into.

1. The Hero Anti-Pattern

A team member who is the only person that can fix serious technical issues in an environment.

Its seductive to be the only one who can fix some thorny automation issue.

You feel special. 

But being the only person who can do something in Salesforce doesn't scale for the organization.

Emphasize roles and process, not individuals, when building the system.

2. Ignoring the Ecosystem

Willfully ignoring third-party options in favor of in-house solutions can become an anti-pattern. 

I had a client who insisted I build him a custom lead round robin.

I recommended using an AppExchange product called Distribution Engine but was overruled.

He ignored the ecosystem. 

It's easy to say, "not my fault", but if I had been more persuasive I could have gotten him a better result.

A custom solution is often less capable, has a higher Total Cost of Ownership, gets fewer new features, and requires an additional team skillset to maintain.

In many cases its cheaper, faster, and higher quality to get the 3rd party app.

3. Licensed-Based Solutioning

Creating a solution based on a license set you can afford rather than the license set you really need without making the necessary compromises. 

I once moved about 200 users from a regular Salesforce license to a Community license to save $300,000 in the IT budget.

I found it increases the amount of custom work, adds complexity, increases long-term maintenance cost, and limits access to new features.

Strongly consider the long-term effects before designing your solution solely around the cost of licenses.

4. God Class

The God class is a single class that contains all or most of the business logic defined for an application. 

Building one Process Builder to rule them all is something I've done.

Building one Flow to rule them all is also something I've done.

This anti-pattern is ineffective because future changes to your "god class" affect every automation you currently have.

The single flow gets hard to understand.

Versioning the flow if multiple people need to work on it gets difficult.

And troubleshooting/rolling back issues because time intensive.

Balance the Single-Responsibility Principle with your need to group similar functionality together.

5. Big Bang Release

The big bang release anti-pattern places the release of all functionalities in a single event at the end of a long-running project.

Go as small as you can with your development cycles.

Release early, release often. 

Get feedback and iterate.

The longer you wait to deploy, the riskier it gets.

That's a wrap!

I would definitely encourage you to include anti-patterns on your Salesforce learning journey (when you think you can fit it in).

They are a high-leverage way to create powerful Salesforce architectures that don't fail.