This site is in beta. We welcome your feedback

Pattern Overview

The Salesforce Operating, Governance & Architecture Framework (SOGAF) applies the MIT-CISR Enterprise Architecture Framework to Salesforce implementations and programs. Within this framework, there are four generalized architecture types:

Each particular architecture type corresponds to a supporting SOGAF Operating Model. Selection of an architecture type should also include selection of the appropriate operating model, under SOGAF principles.

The Common System Layers

SOGAF uses a layered approach to structure systems into decomposable groups and sub-systems (or components).

architecture layers with arrow showing service direction

Each layer operates with different levels of abstraction. The layers build incrementally, so each layer should provide services to the next higher layer (if one exists).

All SOGAF architecture types use the same five layers to organize capabilities, systems and functions:

  1. Infrastucture Layer
  2. Data Layer
  3. Busines Logic Layer
  4. Application Layer
  5. Presentation / Experience Layer

The differences between SOGAF architecture types come from how much commonality there is (or isn't) between layers and components within layers, as well as the way that layers and components are managed.

Differences Between Architecture Types

Each architecture type has its own major characteristics. Boundaries between architecture types can be somewhat subjective in practice. Most organizations operate along a continuum. This is why teams following SOGAF principles pair the selection of an architecture type with an appropriate operating model.

Let's look at some examples of key characteristics in practice, and what each one might look like for each architecture type.

Key Characteristics Architecture Type
Single System Core Model Template Multiple Systems
Salesforce Instances (Number of orgs)1 Single org Most often one org, sometimes multiple Sometimes one org, most often multiple Multiple orgs
Application Development Style Single application, built and deployed centrally. Features managed locally. Shared 'core model' built and deployed centrally. Applications managed locally. Occasional features merged back to core model. Shared 'template' built centrally. Template customized and managed locally. Applications managed locally. Applications built, deployed, managed locally.
Processes Common processes, designed and managed centrally. Processes localized by line of business (LOB), business units (BU), or another mechanism. Designed and packaged centrally, deployed locally. Mutual or shared services capabilities. Some methods for gathering and sharing best practices. Local processes, designed and managed independently. May have some sharing mechanisms.

1Under SOGAF, the best options for Salesforce org strategy will come from the choice of operating model and matching architecture type.

You can learn more about each architecture type in the SOGAF Operating Models resources below. You'll find each type discussed in the context of its supporting operating model.

About the Contributors

Martin Griffiths is a Business Architect Director at Salesforce, with an Anglo-French background and based in Paris, France. Martin joined Salesforce 5 years ago. His 30-year career in CRM, ERP and digital transformation spans business consulting, enterprise architecture and program delivery roles. His focus is advising customers on complex Salesforce-based transformations, operating models and architecture, applying academic frameworks to guide decision-making and address governance at scale topics successfully.

You can connect with Martin Griffiths on LinkedIn.