Architecture principles for Salesforce implementations

As an architect (Salesforce and Enterprise), one of my favourite things in the world are architecture principles. Principles define the foundation for the way your teams must work and the rules you want to have set in stone (they can't be broken without extensive and clear justification). They are mandatory, but they shouldn't be adversary, they need to be an agreement, a consensus that allows everyone involved to understand how things need to be done, and more importantly, why they need to be done. They have to believe it for the whole thing to work!

I googled the definition of principle and this is what came out:

"a fundamental truth or proposition that serves as the foundation for a system of belief or behaviour or for a chain of reasoning."

I like that very much. I want to focus on the way principles serve as a foundation for a system of belief, behaviour or for a chain of reasoning. They are what you need to build upon, when creating teams of people, not just for Salesforce implementations, but for everything in life. We'll focus on Salesforce implementations in this post, though, wouldn't want to get too philosophical! Or would I?

Moving on... If you ask me (and not just me, but also the open group - the TOGAF guys -, for example), when starting a project of any shape or size, one of the first things that need to be created and agreed upon are a list of architecture principles. These principles are not necessarily the same for every project of every shape and size, but agreement of a set of principles is definitely key, to frame the way all solutions are to be thought of and how the architecture needs to behave.

In this post, I'll put a list of principles that are quite common and that I believe every project should follow, on a high level. Again, I'm not the single owner of the truth, and there are many different dimensions of principles, but this is my foundation, the ones I normally use to start the conversations that will end with the desired agreement. Let's get to it.

Note: I'm not going to get too deep into the enterprise architecture concepts in this post, maybe I'll write one on how to apply/extrapolate TOGAF's architecture development method (ADM) on a Salesforce implementation, but this is not it. It's also important to note that I'm not going to be talking about microservices architectures and how to design those, maybe there's another post for that, and maybe there's other people that have done it already better than I can!

Enterprise architecture principles

Not THAT enterprise! (terrible joke)

I'll start with the principles a company should follow on a high level. These are a bit more examples than solid rules, but they are, in my experience, a good list of principles that an enterprise should follow, if they're thinking of going into the Salesforce world (and overall, as well). In all honesty, I can't take full credit of coming up with these solely on my own, as they're based on previous implementations that I've collaborated on, but they're generic enough to be understood, I believe.

Technology

• Buy technology before building: we will only build solutions which strategically differentiate us from our competitors or where there is a valid business case for doing so
• Cost effective Technology: technology should be sourced leveraging the company's size, scale, existing agreements and aligned to overall strategy
• Up to date and sustainable technology: technology choices must be made with consideration for the duration of the investment and the technology roadmap
• Measurable Service Levels: all technology supported services will have pre-defined measures to support service level agreements and targets
• Re-use existing assets: existing technologies should be prioritised over new, providing business and technology requirements are met

Application

• Applications are easy to use: applications are intuitive, and designed with the user outcomes and business scenarios in mind
• Systems must be appropriately secured: appropriate security controls are assessed and built in from design
• Applications are interoperable: all applications should be designed to expose core functionality through standard APIs
• Application integration must be loosely coupled: applications should be integrated avoiding direct application dependencies
• Compliance with regulation: all applications will meet the compliance requirements

Data

• Data is an asset: data must be designed and managed in a way that is appropriate to its level of risk and value
• Data is made available: data must be made available for reuse to improve collaboration and consistency and drive business efficiencies. Think of a single view of the customer
• Data is independent of divisional boundary: data that supports company-wide objectives must be managed without divisional separation
• Data quality must be maintained: data controls must be applied to ensure data quality is maintained to the appropriate standard
• All data concepts must be clearly defined: data concepts must be clearly defined and communicated to avoid ambiguity and confusion
• Defined data roles and responsibilities: data ownership and stewardship must be clearly defined and assigned to accountable parties
• Compliance with legislation: data supporting regulatory mandates should be readily available on a global basis
• Data retention: all stored data is compliant with business requirements

Salesforce technical design and architecture principles

After we know how our company should behave when it comes to technology, and we know that we're a very good match for implementing Salesforce, we have to agree on the rules that we need, in order to do so. You'll notice that some of these align to the ones above.

I want to be clear again that I don't mean these to be the absolute truth of what everyone should be doing, these are just my view of the foundation that should be followed for usual implementations, and I believe in these. Having said that, everything can be changed with enough justification, but this shouldn't be the case, after the principles are firmly agreed and the implementation is on the way.

We'll also assume here that a Centre of Excellence (COE) or a proper Enterprise Architecture Capability is implemented in the company, and the following principles are agreed with the Technical Architecture committee or similar relevant body.

Implementation and methodology

• Standard methodology: follow the methodology and governance defined as standard – Scrum, Agile, 2-week sprints, for example. As defined by the company or the SI (or both)
• Follow the DevOps culture: no surprise here, if you want more info, go to my DevOps series. This should be agreed depending on the size and type of project
• Use the Dev tools: more info on dev tools. Give DX a try, if you can! More info on DX
• Use the Ops tools: more info on ops tools
• Measure velocity: measure project resourcing and progress with both story points and time estimates / burndowns

Customisation

• Config over code: always choose config over custom code when possible
• Don’t reinvent the wheel: make good use of the AppExchange, as appropriate
• Use standard frameworks: create and make use of frameworks to standardise the way code is written (for triggers, logging and others). Involve your dev team in their creation, and you'll get them even more on board!
• Follow the configuration and coding standards and guidelines: you already have a huge document detailing these, right?
• Reusability: all code and components must be reusable and implemented following a modular approach
• Lightning first: always choose lightning experience and lightning components over classic, if business requirements are met

Integration

• Avoid data synchronisation when it’s not needed: favour Salesforce Connect, Canvas apps and mashups (or similar solutions) whenever possible
• Make use of standard APIs: always use standard Salesforce APIs, in order to connect to Salesforce, at all times, unless specifically needed. This will mean that very clear justification is needed, if a custom method is to be created and exposed
• Make use of Salesforce's declarative integration features: such as named credentials, authentication providers, outbound messages, platform events and Streaming API to send information out of Salesforce
• Go Canvas: make use of Canvas apps over html IFrames whenever possible
• Avoid point to point integrations: as much as possible, unless they’re Salesforce's out of the box features, such as Salesforce Connect, integrations to MS 365 and so on
• Avoid the frequent movement of content (attachments and other files): always favour Salesforce files and content internally or go with Files connect solutions, in case external file management services are present and are compatible

Data

• Keep an eye on large data volumes (LDV): follow guidelines for working with LDV, but avoid having big amounts of data idly stored in Salesforce when possible. Use skinny tables, bulk API, selective queries and so on, as appropriate, to improve the performance, when LDV are present. Archive and backup as much as possible, complying with regulation and data retention policies
• Avoid Personally identifiable information (PII): PII should be stored in Salesforce only when the company agrees to it specifically. Non compliant data should not be stored in Salesforce in any case. This will vary for companies in different industries, of course, but it's key to agree on what is and what isn't compliant at the very beginning
• Data migration ownership: in case of data migration exercises, data manipulation should only be undertaken by the owners of the data themselves, while there should be a team to support extracting and loading the data, making use of the standard Salesforce APIs for this: REST, SOAP, Bulk, and so on, as appropriate

Identity and Security

• Follow the company's security criteria for identity: use SSO (SAML, out of the box) as possible, unless a different method is implemented in the company, in which case use out of the box features for identity
• Define application security rigidly: by default, no access should be given to the users on creation. For this purpose, always use read only profiles (or clones of them) for base access and use permission sets on top for security. This also helps in the deployment of the security features, as mentioned previously on the DevOps series
• Define data sharing rigidly: manage org wide defaults (OWD), role hierarchies, public groups and sharing rules appropriately, following the above principle (no access is given by default on user creation, everything is opened afterwards)

Mobile

• Salesforce mobile is preferred: favour standard Salesforce or mySalesforce mobile apps above custom ones, whenever possible
• Favour hybrid apps over native apps: again, whenever possible and business requirements are met

Wrapping up

As you can hopefully see, if you agree to a list of architecture principles, you already have most of the battle won!

With this, I mean that you have the guidelines for your implementation's behaviour and the teams have agreed to them, believe in them and are on board. This way, when the requirements are gathered and validated, the design team are already on track, as they need to follow the rules and guidelines to design and decide quickly, accurately and with less hassle.

After that, comes the fun part, the actual implementation! 

By this point, the teams are hopefully truly engaged and they truly believe in the implementation needs and the solution that has been designed. This, in turn (again, hopefully) makes them eager to carry on providing value and making the company's vision come to life.

As I said, I love principles, and I'm always striving to be a principled man! But as I said, I won't go into too much philosophy today...

Please comment if you agree, disagree, have cool principles to add, anything!