There’s a lot of talk and focus on the role of architects in the Salesforce ecosystem. Commonly Solution Architects get a lot of attention, as do Technical Architects – but what about Enterprise Architects? What is Enterprise Architecture and how does it relate to Salesforce? This article focuses on concepts from one of the most popular EA frameworks, TOGAF, but there are other approaches out there.
First, a quick note on TOGAF. TOGAF stands for The Open Group Architecture Framework which is administered by The Open Group. The TOGAF Architecture Development Method (ADM) is a method for developing architecture and is at the core of the TOGAF standard.
Introduction to Enterprise Architecture
The term Enterprise Architecture (EA) is used frequently, especially in the context of large complex transformation projects. It is often assumed that EA focuses on the largest, most complex projects. However, that is a misunderstanding. Enterprise Architecture is about building a common understanding and alignment between business and IT to support business strategy.
EA should be focused on making architecture approachable and usable by broad stakeholder groups to drive alignment. With that in mind, EA is an incredibly useful tool that can help any Salesforce professional elevate their perspective and improve overall solutions.
Clarifying definitions is always helpful. In this context, what is an ‘enterprise’ and what is ‘architecture’? Here’s what is outlined by TOGAF:
- Enterprise: An organizational unit, an organization, or a group of organizations with common goals. Enterprise is often confused with ‘enterprise clients’, usually indicating the largest organizations in the market. However the EA definition of ‘enterprise’ can scale up or down as needed to support a given initiative. The ‘enterprise’ may relate to just one department within an organization, or it may relate to the entire organization. The point is that the term ‘enterprise’ should be used to provide focus, not to describe size or complexity.
- Architecture: A description of a system, its components, and their relationships. The system could be one application (like Salesforce), it could be a component of a system’s data architecture within Salesforce, or it could mean an entire application landscape spanning multiple technologies (CRM, ERP, CLM, middleware, etc.). The definition of architecture is another flexible term that can scale up or down and should be used to help align stakeholders on the systems, components, and relationships relevant to a given challenge.
Relationships of EA and Solution Architecture
So what is the relationship between Enterprise Architecture and Solution Architecture? Enterprise Architecture is typically broader than Solution Architecture and aims to align broad stakeholder concerns in terms of business objectives, processes, technology and outcomes. On the other hand, Solution Architecture is generally focused on how a particular technology component, for example Salesforce, will be implemented to meet a set of business requirements.
Ideally, Enterprise Architecture supplies the context and insight to guide Solution Architecture. To address broad considerations, and align diverse stakeholder viewpoints, Enterprise Architecture often needs to be broader, less specific, and often less technical than Solution Architecture.
The most valuable, and reusable Enterprise Architecture is often technology agnostic and describes generic components, for example, a ‘CRM System’ rather than specific CRM solutions, like Salesforce. After establishing a common understanding of goals and outcomes, EA should help to accelerate solutions efforts.
Below are three different viewpoints for explaining the relationship between Enterprise Architecture and Solution Architecture. Remember that definition of ‘an architecture’ from a few paragraphs back – a system, its components, and their relationships – well, here is ‘an architecture’ that describes…architecture!
Pretty simple right? But also very helpful to clearly illustrate the relationships and develop a common understanding for anyone reading.
Why Should I Care?
Done well, Enterprise Architecture should provide long-term guidance on how different technology components support overall business objectives. It should not prescribe how technology is, or should be, implemented, but rather provide guardrails that help inform design decisions and prioritization.
Additionally, most organizations have several technology components that support business operations; Salesforce is usually just one. Understanding how the various technology components work together will enable you to be a well-informed contributing member of a larger team.
EA can help to provide valuable context about how Salesforce interacts with other systems and might spark ideas on how Salesforce specifically can be better utilized to support an organization.
If some of these components feel like they are missing, or are not usable for your role, consider creating your own!
The TOGAF Architecture Development Method
The TOGAF Architecture Development Method (ADM) outlines four architecture subdomains that should be considered to develop architecture. Why would a Salesforce professional care about these domains? They provide a very structured and easy-to-follow approach that can be tailored to your specific needs. Just like how the terms ‘Enterprise’ and ‘Architecture’ can scale based on the challenge at hand, so too can the following concepts.
This subdomain focuses on business applications, their relationships, and high-level functions. Sometimes just creating a list, or catalog, is enough to spark valuable conversations. For example, why do we have three different marketing systems: Account Engagement (Pardot), Marketo, and Eloqua? Salesforce has created a great set of templates that can help you quickly get started developing your own application architecture diagrams:
The data subdomain can get a bit technical, but it doesn’t have to. This is a great domain to keep in mind when adding new applications, add-ons, or clouds to the mix. Often business applications come with their own data entities out of the box. Taking time to understand how new data entities relate to, conflict with, or duplicate existing data entities can be a very helpful exercise. Again, Salesforce provides some fantastic resources to get started:
Don’t let this subdomain fool you, it really doesn’t have to be all that ‘technical’ depending on your needs. Sometimes the ‘technology’ architecture is as simple as listing those technology components that impact Salesforce, but aren’t actually Salesforce products. For example, DevOps tools or SSO solutions could be considered technology architecture components.
You can also dive deeper and get more technical if needed. It might make sense to understand how technologies like Visualforce or LWC are used in your particular org or how specific integration patterns are used to connect systems. Here is a great library to get you thinking:
I don’t touch on this domain in this article, but it is a big one. If you are involved in a focused EA engagement, this is probably where you would start. Business Architecture is largely technology agnostic, focused more on how an organization is structured, what its core capabilities are, and how they deliver value to customers (value streams).
If something you need right now, Salesforce has created a great template that can help get you started with capability mapping:
Enterprise Architecture is a broad knowledge domain and it will be applied differently at different organizations for varying challenges. The key is understanding the nature of the problem at hand and adjusting your viewpoints, methods, and techniques to match.
Hopefully, this article has provided a good overview of what EA is, and how you can get started using some of its methods and techniques. Salesforce-focused professionals likely won’t be focused exclusively on developing an Enterprise Architecture, but awareness of what EA is, and how it is used, can help any Salesforce professional enhance skills, collaboration, and solutions.