The Enterprise Continuum is a classification mechanism — it categorises architecture and solution artifacts by how generic or organization-specific they are. It is NOT a database. The Architecture Repository is the actual storage that holds those artifacts, organised into eight classes.
The Enterprise Continuum gives you a consistent way to describe where any architecture or solution asset sits on the spectrum from "totally generic" to "unique to our organization".
- ▸🗂️ It is a CLASSIFICATION / categorisation mechanism — a view, not a repository
- ▸📈 Spectrum: generic (Foundation) → organization-specific — assets are refined as they move right
- ▸🧩 Two constituent parts: the Architecture Continuum (ABBs) and the Solutions Continuum (SBBs)
- ▸🔗 The Solutions Continuum realises the Architecture Continuum — they are paired, not separate
- ▸⚠️ Trap: "the Enterprise Continuum stores architecture artifacts" — FALSE. The Architecture Repository stores them.
Click the cells to explore the four levels of the Architecture and Solutions Continuum, then expand the classes of the Architecture Repository.
Continuum
Continuum
Defines the organization's tailored version of the ADM and the architecture content framework — the rules for HOW architecture is done here.
Defines the parameters, standards, and guidelines that govern the operation of the Architecture Capability — staffing, roles, budgets, tools, processes.
The architectural representation of assets in use or planned — showing what exists and what is planned across three levels: Strategic, Segment, and Capability.
Industry and internal standards that architectures must comply with — regulatory requirements, technical standards, approved products list.
Guidelines, templates, patterns, and reference architectures from external sources (TOGAF, Open Group, industry bodies) that inform architecture decisions.
Formal governance records — architecture change requests, compliance assessments, dispensations, decisions made by the Architecture Board.
A view of all authorized architecture requirements that have been agreed with the Architecture Board.
An architectural representation of the Solution Building Blocks (SBBs) that support the Architecture Landscape and have been planned or deployed by the enterprise.
Both the Architecture Continuum and the Solutions Continuum have the same four levels, moving from most generic to most specific:
The Architecture Repository is the real storage structure. The TOGAF 10 Standard (Introduction & Core Concepts, Figure 3-5) lists eight major components:
- ▸🗺️ Architecture Metamodel — the organization's tailored ADM and content framework
- ▸⚙️ Architecture Capability — parameters, roles, budgets and governance that run the EA function
- ▸🏙️ Architecture Landscape — ABB assets in use/planned, held at three levels: Strategic, Segment, Capability
- ▸📏 Standards Library — the standards architectures must comply with
- ▸📚 Reference Library — guidelines, templates, patterns and reference models (e.g. TOGAF TRM)
- ▸📋 Governance Repository — the record of governance activity (change requests, compliance assessments, dispensations)
- ▸✅ Architecture Requirements Repository — all authorized architecture requirements agreed with the Architecture Board
- ▸🏗️ Solutions Landscape — the SBBs (planned or deployed) that support the Architecture Landscape
These are not standalone concepts — they feed and are fed by the ADM:
- ▸📥 Preliminary / Phase A: pull reference models and patterns FROM the Reference Library (via the Continuum)
- ▸🏗️ Phases B–D: reuse existing ABBs/SBBs classified in the Continuum instead of designing from scratch
- ▸📤 Throughout: newly created architectures are classified on the Continuum and stored in the Repository
- ▸📋 Phase G/H: governance decisions are written to the Governance Repository