2.1 The Enterprise Continuum
Key Takeaways
- The Enterprise Continuum is a categorization mechanism for classifying architecture and solution assets from generic to specific applicability, or vice versa.
- The Enterprise Continuum comprises two complementary concepts: the Architecture Continuum and the Solutions Continuum.
- Both continua progress through Foundation, Common Systems, Industry, and Organization-Specific levels of specialization.
- The practical implementation of the Enterprise Continuum typically takes the form of an Architecture Repository.
- The Architecture Continuum guides and supports the Solutions Continuum, and assets can be specialized or generalized along the continuum.
2.1 The Enterprise Continuum
Learning Unit 1 asks you to briefly describe the Enterprise Continuum. It is one of the most abstract TOGAF concepts, so anchor it to one idea: the Enterprise Continuum is a categorization mechanism that lets architects classify assets from the most generic to the most organization-specific, so they can find and re-use what already exists instead of starting from scratch.
Definition and Purpose
The TOGAF Standard, 10th Edition describes the Enterprise Continuum in two complementary ways:
- Core Concepts: "a categorization for assets held in the Enterprise Repositories that provides methods for classifying assets, including architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures."
- Glossary: "a categorization mechanism for classifying architecture and Solution Building Blocks (SBBs) as they evolve from generic to specific applicability (or vice versa)."
The Enterprise Continuum sets the broader context for an architect and explains how generic solutions can be leveraged and specialized to support the requirements of an individual organization. The ADM chapter adds that the Enterprise Continuum categorizes architectural source material — both the contents of the organization's own repositories and the relevant reference models and standards in the industry. In practice, the continuum is used to classify inputs to and outputs from the Architecture Repository.
It is not a database or a tool. The practical implementation of the Enterprise Continuum typically takes the form of an Architecture Repository (see Section 2.2).
The Two Complementary Continua
The Enterprise Continuum comprises two complementary concepts:
| Continuum | What it classifies | Glossary wording |
|---|---|---|
| Architecture Continuum | Architectures and architecture building blocks — specifications of what is needed | A categorization mechanism, with increasing detail and specialization, for the components and artifacts stored in the Architecture Landscape or Reference Library; it begins with foundational definitions like reference models, core strategies, and basic building blocks, and spans Industry Architectures to an Organization-Specific Architecture |
| Solutions Continuum | Solutions and Solution Building Blocks — implementations of what is needed | A categorization mechanism, with increasing detail and specialization, for the components and artifacts stored in the Solutions Landscape or Reference Library |
The Architecture Continuum guides and supports the Solutions Continuum: each architecture level provides the specification against which solutions at the corresponding level are selected or built.
The Four Levels of Specialization
Both continua move from generic (left) to specific (right) through four levels:
| Level | Architecture Continuum | Solutions Continuum | Illustrative example |
|---|---|---|---|
| Foundation | Foundation Architecture — generic building blocks, their inter-relationships, and the principles and guidelines that provide a foundation on which more specific architectures can be built | Foundation Solutions — generic products and services, such as programming languages, operating systems, and foundational structures | The TOGAF Technical Reference Model (TRM), now published as a TOGAF Series Guide |
| Common Systems | Common Systems Architectures — architectures for services that are relevant to many enterprises and industries, such as security, management, or network services | Common Systems Solutions — implementations of common system capabilities, such as security or management products | The TOGAF Integrated Information Infrastructure Reference Model (III-RM), which addresses Boundaryless Information Flow |
| Industry | Industry Architectures — architectures relevant to a particular vertical industry, integrating common systems components with industry-specific components | Industry Solutions — packaged solutions for a vertical industry | Banking, telecommunications, or insurance reference models |
| Organization-Specific | Organization-Specific Architectures — the architectures for one enterprise, reflecting its requirements | Organization-Specific Solutions — the solutions actually deployed in that enterprise | An insurer's own target claims architecture and its deployed claims platform |
Moving left to right is specialization (adapting generic assets to specific needs). Moving right to left is generalization — the glossary's "(or vice versa)" — for example, when a solution built for one business unit is generalized so the whole enterprise can re-use it.
How the Continuum Supports the ADM
- Re-use: at relevant places in the ADM, architects are reminded to consider which assets from the Architecture Repository to use — for a Technology Architecture this might be a foundation-level reference model; for a Business Architecture, an industry reference model.
- Common language: placing an asset on the continuum tells stakeholders how generic or specific it is.
- Growing assets over time: the first ADM cycle is often the hardest because re-usable assets are scarce; each later cycle adds content to the repository, populating it with re-usable building blocks taken from the more generic "left" side.
- Governance: criteria for including source material in the Architecture Repository typically form part of the EA governance process, deciding when general resources can be adapted and when specific solutions can be generalized for wider re-use.
- Developing the Enterprise Metamodel: the continuum lets architects consider resources on a scale from the most general ("Foundation") to the most specific ("Organization-Specific") when tailoring the metamodel.
Scenario: Re-using Before Building
A hospital group plans a patient portal. Before designing, architects search the repository using the continuum: a Common Systems identity and access reference architecture already exists, a healthcare industry interoperability model is available externally, and a sister hospital built an organization-specific appointment service. The team specializes the common identity architecture, adopts the industry model for record exchange, and generalizes the sister hospital's appointment service for group-wide use — moving in both directions along the continuum.
Common Exam Pitfalls
- Calling the Enterprise Continuum a physical repository or a tool. It is a categorization mechanism; the Architecture Repository is its practical implementation.
- Reversing the direction. Foundation is the most generic; Organization-Specific is the most specific.
- Confusing the two continua. The Architecture Continuum classifies architectures and ABBs; the Solutions Continuum classifies solutions and SBBs.
- Forgetting "or vice versa." Assets can be generalized as well as specialized.
What is the Enterprise Continuum in the TOGAF Standard?
Which two complementary concepts make up the Enterprise Continuum?
An architecture for security and network management services that is relevant to many enterprises across industries belongs at which level of the Architecture Continuum?
A payments service built for one business unit is reworked so every business unit in the group can re-use it. How is this movement described on the Enterprise Continuum?