Section 1: Enterprise Continuum Overview
The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying architecture and solution assets as they evolve from generic, vendor-neutral foundations to organisation-specific implementations. It is not a tool or a database — it is a conceptual framework for organising architectural assets so they can be discovered, evaluated, and reused across projects and ADM cycles.
A classification mechanism for architectural and solution assets that spans from fully generic (applicable anywhere) to fully specific (tailored to one enterprise). It consists of two complementary continua: the Architecture Continuum and the Solution Continuum.
The Enterprise Continuum serves three purposes: (1) a classification mechanism for storing and finding assets; (2) a communication framework that helps architects explain relationships between architectures at different levels of abstraction; and (3) a reuse enabler — assets at the generic end are immediately applicable to many scenarios, reducing the cost of new architecture work.
Section 2: Architecture Continuum
The Architecture Continuum spans from fully generic architectures on the left to organisation-specific architectures on the right. Moving right adds context, constraints, and industry-specific patterns, making each level less reusable but more directly applicable to the target organisation.
| Level | Definition | Examples | Reusability |
|---|---|---|---|
| Foundation Architecture | Completely generic; applicable to any enterprise regardless of industry or technology | TOGAF TRM, III-RM, ISO/IEC standards | Universal |
| Common Systems Architecture | Relevant to multiple industries; captures cross-sector architectural patterns | Security reference architectures, Systems Management frameworks | Multi-sector |
| Industry Architecture | Relevant to a specific industry or sector | Banking Reference Architecture (BIAN), eTOM for telecoms, ARTS for retail | Sector-specific |
| Organisation-Specific Architecture | Tailored to one enterprise; incorporates constraints, brand, legacy, and regulatory context | Enterprise-specific roadmaps, custom reference models | Single-enterprise |
The exam tests the direction: moving right (towards Organisation-Specific) increases specificity and decreases reusability. Moving left (towards Foundation) increases reusability and decreases specificity. TOGAF encourages starting from the left — reuse what exists before creating new assets.
Section 3: Solution Continuum
The Solution Continuum mirrors the Architecture Continuum and contains the actual implementations — products, packages, and custom solutions — that realise the architectures defined in the Architecture Continuum. Each level of the Architecture Continuum corresponds directly to a level in the Solution Continuum.
| Architecture Continuum Level | Solution Continuum Level | Typical Content |
|---|---|---|
| Foundation Architecture | Foundation Solutions | COTS products, open-source frameworks, standards-compliant platforms (e.g., Linux, Java EE) |
| Common Systems Architecture | Common Systems Solutions | Standard enterprise platforms — IAM suites, monitoring tools, message brokers |
| Industry Architecture | Industry Solutions | Industry-specific packaged applications — core banking systems, EHR platforms, utility billing software |
| Organisation-Specific Architecture | Organisation-Specific Solutions | Custom-built implementations, enterprise-configured packages, bespoke integrations |
The two continua work together: the Architecture Continuum provides the design blueprint, while the Solution Continuum provides the implementation artefacts. An architect selects from the Solution Continuum to populate Work Packages and realise the Target Architecture.
Section 4: Architecture Repository Components
The Architecture Repository is the physical implementation of the Enterprise Continuum — it is the storage system for all architectural work products, reference models, standards, and governance records. TOGAF defines six classes of content within the Architecture Repository:
| Component | Purpose | Key Contents |
|---|---|---|
| Architecture Metamodel | Formal description of the organisation's architecture content framework, including types of building blocks, artefacts, and their relationships | Entity definitions, relationship schemas, metamodel diagram |
| Architecture Capability | Documents the parameters, processes, skills, roles, and responsibilities of the Architecture function itself | EA team structure, governance processes, skills inventory, maturity assessment |
| Architecture Landscape | Holds all current architectural work products organised at Strategic, Segment, and Capability levels | Baseline and Target architectures, Architecture Definition Documents, roadmaps |
| Standards Information Base (SIB) | Repository of technical standards that apply within the enterprise, including mandatory, recommended, and emerging standards | Technology standards, open standards references, vendor certifications, deprecated standards |
| Reference Library | External and internal reference materials that provide guidance, best practices, and templates for architecture work | Industry reference architectures (BIAN, eTOM), TOGAF documentation, patterns library |
| Governance Log | Record of all architecture governance activity — decisions made, dispensations granted, compliance assessment results | Architecture Board decisions, dispensation requests, compliance assessments, change log |
TOGAF defines exactly six Architecture Repository components. A frequent exam error is confusing the Governance Log with a separate "Architecture Board Record" or conflating the Reference Library with the Standards Information Base. The SIB holds technical standards; the Reference Library holds reference models and guidelines.
Section 5: Architecture Landscape
The Architecture Landscape — one of the six Repository components — is subdivided into three levels that reflect different time horizons and scopes of architectural work. Each level feeds into the others in a top-down direction:
- Strategic Architecture captures the long-term (3–5 year) direction and vision for the whole enterprise. It provides context for all segment and capability architectures. Typically owned by the Chief Architect.
- Segment Architecture describes an area of the enterprise (a business segment, division, or domain) at a medium-term (1–3 year) horizon. It refines the Strategic Architecture for a bounded scope.
- Capability Architecture describes a focused, enabling capability with a short-to-medium time horizon. It typically drives specific projects and work packages. Multiple capability architectures may exist within one segment.
Section 6: Technology Reference Model (TRM)
The Technology Reference Model (TRM) is TOGAF's Foundation Architecture reference model for technology services. It provides a generic taxonomy of technical services and a visual representation (the TRM diagram) that any enterprise can use as a starting point for its own Technology Architecture in Phase D.
The TRM is composed of two elements: (1) a taxonomy that defines and categorises the services that an application platform can provide; and (2) a TRM graphic that provides a visual representation of the taxonomy. The services are grouped into: Data Interchange Services, Data Management Services, Data Security Services, Operating System Services, Network Services, and others.
The TRM also defines a set of technical service qualities — non-functional characteristics that should be considered for every service: availability, manageability, performance, reliability, scalability, security, and usability. These qualities are cross-cutting concerns applied across all service categories.
Section 7: Integrated Information Infrastructure Reference Model (III-RM)
The III-RM is the second TOGAF Foundation Architecture reference model. Where the TRM focuses on the technology platform services, the III-RM addresses the application layer — specifically, how applications and data management components should be structured to support Boundaryless Information Flow: the idea that business information should flow seamlessly across organisational and technical boundaries.
| Dimension | TRM | III-RM |
|---|---|---|
| Layer addressed | Technology (platform services) | Application and data management |
| Primary goal | Standardise technology services | Enable Boundaryless Information Flow |
| ADM phase most relevant to | Phase D (Technology Architecture) | Phase C (Information Systems Architecture) |
| Key components | Service taxonomy, quality criteria | Business applications, infrastructure applications, data entities |
The III-RM is built on top of the TRM — it assumes the technology services the TRM defines and adds the application and data layer. Together, TRM + III-RM form TOGAF's complete Foundation Architecture.
Section 8: How Enterprise Continuum Supports the ADM
The Enterprise Continuum is not standalone theory — it is actively used during ADM execution:
| ADM Phase | Enterprise Continuum Usage |
|---|---|
| Preliminary | Architecture Repository is established or updated; the metamodel and capability components are configured to reflect the organisation's tailored framework |
| Phase A — Architecture Vision | Architect scans the Architecture Continuum to identify which Foundation, Common, or Industry architectures are applicable to the current engagement, avoiding reinvention of existing assets |
| Phases B, C, D | Architecture Landscape is updated with new Baseline and Target architectures; Standards Information Base is consulted for applicable technology standards |
| Phase E — Opportunities & Solutions | Solution Continuum is consulted to identify reusable COTS products, industry solutions, and common platforms that can fulfil Work Package requirements |
| Phase G — Implementation Governance | Governance Log is updated with compliance assessments and Architecture Board decisions; dispensations are recorded |
| Phase H — Change Management | Architecture Landscape is updated to reflect the new Baseline; the continuum grows richer with each completed ADM cycle |
A key exam point: the Enterprise Continuum is not static. Every completed ADM cycle contributes new Organisation-Specific assets to the Repository. Over time, these assets can be generalised upward — a successful pattern from one project becomes a reusable Common Systems asset for the next. This accumulation of reusable assets is one of the primary long-term benefits of practicing EA with TOGAF.
Section 9: Revision Summary
Revision Summary — Chapter 13
- The Enterprise Continuum is a classification mechanism for architectural assets, not a tool or database; it spans from fully generic (Foundation) to fully specific (Organisation-Specific).
- The Architecture Continuum has four levels: Foundation → Common Systems → Industry → Organisation-Specific; moving right increases specificity and decreases reusability.
- The Solution Continuum mirrors the Architecture Continuum with corresponding implementation assets: Foundation Solutions, Common Systems Solutions, Industry Solutions, Organisation-Specific Solutions.
- The Architecture Repository has exactly six components: Architecture Metamodel, Architecture Capability, Architecture Landscape, Standards Information Base, Reference Library, and Governance Log.
- The Architecture Landscape has three levels: Strategic (3–5 years, enterprise-wide), Segment (1–3 years, business area), and Capability (short horizon, specific outcome).
- The TRM provides a taxonomy of technology platform services and quality attributes; the III-RM addresses application-layer Boundaryless Information Flow — both are Foundation Architecture reference models.
- Phase A uses the Architecture Continuum to find applicable reusable architectures; Phase E uses the Solution Continuum to identify reusable implementation assets.
- Each completed ADM cycle enriches the Repository, increasing the stock of reusable assets available for future projects.
Practice Questions
Five exam-style questions covering this chapter. Click a question to reveal the answer and explanation.
A. A project management tool for tracking ADM phase outputs
B. A database of vendor technology products approved by the Architecture Board
C. A classification mechanism for architectural and solution assets that spans from generic to organisation-specific
D. A governance framework for approving architecture changes
Explanation: Option C is correct. The Enterprise Continuum is explicitly defined as a classification mechanism for assets — not a project tool, not a product list, and not a governance framework. Its primary value is enabling reuse by helping architects locate and apply existing assets before creating new ones. Options A, B, and D describe other TOGAF concepts (ADM artefact management, SIB, and Architecture Governance respectively).
A. Foundation Architecture
B. Industry Architecture
C. Common Systems Architecture
D. Organisation-Specific Architecture
Explanation: Option B is correct. The Industry Architecture level holds patterns and reference models that are relevant to a specific industry sector — in this case, financial services. The Banking Industry Reference Architecture (BIAN) is a classic example. Foundation Architecture (A) applies universally to any enterprise. Common Systems Architecture (C) applies across multiple industries, not one specific sector. Organisation-Specific Architecture (D) is tailored to a single enterprise, not an industry category.
A. Standards Information Base
B. Architecture Capability
C. Reference Library
D. Governance Log
Explanation: Option D is correct. The Governance Log is the component that stores the record of all governance activity — including Architecture Board decisions, dispensation requests and outcomes, compliance assessments, and the change log. The Standards Information Base (A) holds technical standards, not governance decisions. Architecture Capability (B) documents the EA function's structure and skills. The Reference Library (C) holds external reference materials and guidelines.
A. Phase A — Architecture Vision
B. Phase D — Technology Architecture
C. Phase E — Opportunities and Solutions
D. Phase G — Implementation Governance
Explanation: Option C is correct. Phase E — Opportunities and Solutions is the primary phase for identifying implementation options, including reusable COTS products, common platforms, and industry solutions held in the Solution Continuum. Phase A (A) primarily consults the Architecture Continuum to find reusable architecture patterns (not solutions). Phase D (B) develops the Technology Architecture. Phase G (D) governs implementation projects; it checks compliance against the architecture, not solution discovery.
A. Strategic Architecture
B. Segment Architecture
C. Capability Architecture
D. Foundation Architecture
Explanation: Option A is correct. Strategic Architecture covers the enterprise-wide direction with a 3–5 year horizon — matching "four years, all business units." Segment Architecture (B) is scoped to a specific business area with a 1–3 year horizon, not enterprise-wide. Capability Architecture (C) is focused on specific enabling outcomes with a short time horizon. Foundation Architecture (D) is a level of the Architecture Continuum, not the Architecture Landscape — it is a common mistake to conflate these two different classification systems.