Change Management: the key to Salesforce architecture

Problem Statement

The traditional top down approach to architecture does not fit well with Salesforce. The reason for that is you cannot take a full top down and business driven solution and technology approach, because of the XaaS characteristics of Salesforce:

• The PaaS aspect means the technology architecture is a given, providing constraints to higher domains and layers of architecture
• The SaaS aspect should be leveraged, not replaced or conflicted with

The other way around - bottom up - doesn't work either, but is what you often see in Salesforce implementations: hardly any big architecture is done, the solution is designed story by story, without properly considering end-to-end UX/CX, dependencies and conflicts.

It's the approach I like to call stacking sheds: you cannot stack up a few hundred sheds and expect to end up with a skyscraper. The implementation will not form one harmonious end-to-end solution and the foundation does not support the solution built on top of it.

Traditional Approach to Architecture

Conceptual Structure to Solution

The traditional approach to architecture is captured well in the TOGAF ADM, shown in the diagram above.

Architect the enterprise on a conceptual level with architecture building blocks (ABBs) in phase B-D, which provides the structure of the solution in the form of blocks of requirements, but not the detailed solution to those elements. In development terminology it's very similar to an interface, not an implementation of that interface.

In each layer of architecture those requirement blocks are mostly black boxes, focusing on input and output specs and the interaction between the different boxes, often depicted as a process diagram. Detail is provided in the lower layers of architecture: each block could become a diagram of its own in a lower layer of architecture, describing the steps within that block.

Finally, you translate the ABBs to solution building blocks (SBBs) by providing specific solutions to the requirements of each ABB in phase E and F.

Business to Technology and Top to Bottom

There are multiple frameworks that define layers of architecture. SAFe for instance defines the layers Enterprise Architecture (Portfolio), (Large) Solution Architecture and System Architecture (Essential SAFe). The How to Build Salesforce Diagrams article on architect.salesforce.com mentions the C4 Model though, so let's go with that for now.

In the traditional architecture approach, combining the TOGAF ADM with the C4 model to define layers of architecture results in a model that moves from high level business architecture to low level technology architecture.

• Business architecture drives the information systems architecture, which in turn drives the technology architecture
• Higher levels of architecture drive the lower levels of architecture

Using a house as metaphor you would design it in the following order:

• Business: how you want to live in it: cook, relax, work, study, sleep, etc.
• Information systems: what furniture, appliances, lighting, etc. you need to facilitate that
• Technology I: which rooms you need for that and their layout
• Technology II: what outer structure should look like to support that, i.e. outer walls and roof
• Technology III: the foundation of the house to support everything

The Bottom Up Implementation

The implementation goes in the opposite direction. Taking the house again as metaphor it look something like this:

• Foundation
• Outer walls, load bearing walls and floors
• Roof
• The other inner walls
• Furniture
• Appliances
• Etc.

Going back to IT, this could look something like this:

• Datacentres providing network infrastructure with outside world, redundant power supplies, cooling, etc.
• Servers, switches, routers
• Operating systems, runtime environments
• Applications and databases
• Features and capabilities inside the applications 

Problems With Using Traditional Approach For Salesforce

The traditional approach does not work with Salesforce though, because of the SaaS and PaaS characteristics of the system, which results in conflicting influence. It’s no longer solely left to right (Business → Information Systems → Technology) and top down, but a mix.

C1 level doesn’t give conflicts yet, because this layer looks at the entire enterprise, across systems. Salesforce would be a single SBB per stack (e.g. core platform, Marketing Cloud, CRM Analytics) satisfying the requirements of an ABB

The conflicts arise at the C2 architecture layer when a C1 information system ABB is translated into a Salesforce SBB:

• Technology architecture is suddenly fixed for all ABBs below that C1 ABB, because of the PaaS characteristics of Salesforce
• The information system architecture is partially fixed by the OOTB capabilities of Salesforce on both application and database level, i.e. the SaaS aspect of Salesforce

This means that across the layers C2-C4 it’s no longer possible to work with ABBs in a vacuum, i.e. ignoring the context provided by Salesforce (or any SaaS or PaaS for that matter). Technology architecture will provide the constraints to the Information Systems architecture, which in turn will influence the business architecture, and in the same way SBBs will drive ABBs just as much as the other way around.

This means you adjust Salesforce to the organization, but also vice versa.

Issues with Traditional Architecture Approach On Salesforce

Salesforce is not a system or platform that's designed to be implemented exactly how the client wants. It's a back and forth process where change management is key.

Forcing the traditional approach to architecture on Salesforce typically results in two things:

1. The implementation becomes very code heavy
2. The implementation struggles to stay within the governor limits

The reason for this is that requirements that should map to a standard Salesforce solution, but are too strict to be fully satisfied by a standard solution, typically have no alternative as Salesforce add-on license or AppExchange (Salesforce's app store) solution either, because it’s already provided OOTB. These solutions are typically also too complex to recreate in point & click customization in an NFR compliant way, therefore the implemented solution must rely heavily on code.

Moving away from OOTB, add-on and AppExchange solutions towards point & click customization and code customization in turn puts a high strain on the system’s resources, making it difficult to stay within governor limits and risk exceeding those in peak moments.

A Better Approach to Salesforce Architecture?

NFRs, NFRs, NFRs! The NFRs will be ingredient that will drive change management in this context. This is not the kind of change management where you redesign the whole business, for instance as part of a large merger. This is much smaller: adjusting the business to an IT system, especially when it's from legacy on-premises systems to cloud SaaS.

If there is a requirement to do a major overhaul of the business, that should happen before you even start with architecting Salesforce.

So what could an approach like this look like?

1. Top Level Architecture + Business Architecture

• Create the C1 level architecture
• Create the business architecture

Now, let's assume that there are one or more C1 information system ABBs that could be satisfied by translating them into a C1 information system SBB that leverages Salesforce (or a different multi-tenant cloud SaaS platform).

2. C2-C4 Information System ABBs below C1 ABB that resulted in Salesforce

In step 1 there were one or more C1 Business Architecture ABBs (let's call these A) that resulted in one or more C1 Information System ABBs (B) that in turn resulted in a C1 Information System SBB (C) that leverages Salesforce.

So A drives B which in turn drives C.

The C2-C4 Business Architecture ABBs (D) below those C1 Business Architecture ABBs (A) will also drive the C2-C4 Information System ABBs (E) below the C1 Information System ABBs (B).

So A drives D, and B+D drive E.

So in this step we create the C2-C4 Information System ABBs (E), based on B+D, but we already do this with Salesforce capabilities in mind, so not fully solution agnostic as you normally would do with ABBs.

3. Solution the C2-C4 Architecture: ABB to SBB

Solution the C2-C4 Business and Information System ABBs (D+E) for Salesforce, keeping best practices, governor limits and other NFRs in mind.

This is really where those NFRs come into play. Any solution that would result in poor NFR compliance / performance should result in strong pushback from the Design Authority / Architecture Review Board to the business: we're not going to do this.

In most cases poor NFR compliance will come from the fixed Technology Architecture (PaaS), but it could also very well be coming from within the Information System architectural domain. In those cases it's typically from NFRs related to avoiding any duplication (capabilities, features, responsibilities, data), e.g. it would not be aligned with best practices to create a custom Lead object (table) and lead conversion logic, if that's already provided OOTB, especially if that can later on result in conflicts in downstream logic, for instance with Opportunity, Quote and Order.

4. The Change Management

If translating the C2-C4 Information System ABBs into SBBs in step 3 result in any solutions with poor NFR compliance - don't worry, it always does - then that's where the change management kicks in:

It's not just about making Salesforce fit the organization, but just as much about making the organization fit Salesforce.

This means the C2-C4 Information System SBBs will drive changes to the C2-C4 Information System ABBs and C2-C4 Business Architecture SBBs, which in turn drive change to C2-C4 Business Architecture ABBs. In other words, changing the requirements around how the business should work, thereby changing the business.

5. Repeat

You'll typically find that this is not something that you can just do once or twice over the course of an implementation project. It's something that happens continuously all the way to the end of the build phase. To a minor extent even until the production go-live of the final release.

Especially steps 2-4 will therefore be repeated many times. Sometimes you just cannot make it work, there simply isn't an acceptable compromise. In those cases you might even loop back to step 1 and reconsider the decision to go with a cloud SaaS. Maybe it's better to go with just cloud PaaS (e.g. Heroku) or even cloud IaaS (e.g. AWS, Azure Cloud, Google Cloud).

Final Remarks

Something I would like to emphasize here is that I'm not trying to come up with yet another framework.

Instead, I see this as a way to leverage existing frameworks, such as TOGAF ADM, C4 model (or similar models for layering architecture), SAFe, etc. Nothing is preventing you from using the Salesforce Well Architected Framework in combination with this approach. In fact, I encourage it, because it could be a good baseline to come up with the NFRs and other KPIs for the Design Authority / Architecture Review Board, that would drive this whole approach.