Enterprise continuum, repository, and enterprise services

TOGAF uses the enterprise continuum to help you think about architecture and solution assets along a spectrum from the most generic (useful to almost any organisation in any industry) to the most specific (useful only in your particular organisation). The continuum is a classification device, not a repository and not a deliverable. It helps practitioners think about reuse, standards adoption, and how industry patterns inform local design.

“A categorization mechanism useful for classifying architecture and solution artifacts, both in developing architectures, and as a means for communicating and reusing them.”

TOGAF Standard, 10th Edition - C220 Part 0, Introduction and Core Concepts

The continuum is about classification, not storage. It answers the question: where on the spectrum from generic to specific does this asset sit? That answer determines how you govern it, how you communicate its scope, and how confidently you can reuse it.

The continuum identifies four named points along the spectrum. These are not rigid buckets. They are reference points that help you place any architecture or solution asset in context.

Point 1: Foundation Architectures

At the most generic end of the spectrum sit Foundation Architectures. These are architecture assets that are so broadly applicable they could be used by almost any organisation in any industry. They define fundamental computing concepts, networking principles, operating system models, and basic application patterns. Think of them as the equivalent of physics in engineering: the laws that apply everywhere, regardless of what you are building.

For London Grid Distribution, foundation-level assets would include things like the TCP/IP networking model (which defines how all computer networks communicate), the relational database model (which defines how structured data is stored), and basic cybersecurity principles (such as the CIA triad of confidentiality, integrity, and availability). These are not specific to electricity distribution. They are universal.

Point 2: Common Systems Architectures

Moving along the spectrum, Common Systems Architectures are assets that apply across many industries but are more specific than foundation concepts. They define patterns for common business capabilities that most large organisations need: customer relationship management, human resources, financial accounting, supply chain management, and enterprise resource planning.

For London Grid, common systems assets would include API gateway patterns (used across industries for managing service interfaces), identity and access management architectures (used across industries for controlling who can access what), and enterprise data warehouse patterns (used across industries for consolidating reporting data). These are not unique to energy but they are more specific than foundation-level networking principles.

Point 3: Industry Architectures

Further along, Industry Architectures are assets that are specific to a particular sector. They capture the patterns, standards, and regulatory structures that apply to all organisations within that industry.

For London Grid, industry-level assets are substantial. The Common Information Model (CIM) is an international standard (IEC 61968/61970) that defines how electricity networks should be described in data. The SCADA architecture patterns are specific to industrial control environments. The distribution management system reference architecture is specific to electricity networks. The regulatory data publication requirements (such as the LTDS) are specific to Great Britain's energy sector. These assets are shared across all DNOs but would not apply to a bank or a hospital.

Point 4: Organisation-Specific Architectures

At the most specific end of the spectrum sit Organisation-Specific Architectures. These are assets that apply only to your particular enterprise. They capture the specific way your organisation has implemented industry standards, the specific integration patterns between your systems, the specific data models that reflect your asset base, and the specific governance structures that reflect your organisational culture.

For London Grid, organisation-specific assets would include: the specific way London Grid maps its 36 primary substations and 4,800 secondary substations into the CIM model; the specific integration architecture between the GIS, the DMS, and the connections workflow; the specific data quality rules that apply to London Grid's asset register; and the specific Architecture Board charter that reflects London Grid's governance structure.

The practical value of the continuum is that it stops teams from treating every architecture decision as if it starts from zero. When London Grid designs its data publication architecture, it should not reinvent the CIM (that is an industry asset). It should adopt the CIM and then design the organisation-specific mapping that connects the standard to London Grid's actual asset data. The continuum makes this reasoning explicit.

TOGAF actually describes the enterprise continuum as comprising two related continua: the Architecture Continuum and the Solutions Continuum.

The Architecture Continuum classifies architecture descriptions and designs. These are the conceptual models, the blueprints, the logical designs. An architecture building block sits on this continuum. It says what is needed without specifying the exact product or technology.

The Solutions Continuum classifies the implementations, products, and technologies that realise those architectures. A solution building block sits on this continuum. It names a specific product, tool, or technology.

The two continua mirror each other. For every point on the Architecture Continuum, there is a corresponding point on the Solutions Continuum. A foundation-level architecture description (such as "the system needs a relational database") has a foundation-level solution (such as "use PostgreSQL" or "use Oracle"). An industry-level architecture description (such as "the network model must conform to CIM IEC 61968") has an industry-level solution (such as "use a CIM-compliant modelling tool from vendor X").

For London Grid, this distinction matters practically. When the architecture team says "we need a reference architecture for data publication," that is an architecture-continuum statement. When the delivery team says "we will use Apache Kafka for event streaming and a CIM adapter for data transformation," that is a solutions-continuum statement. Both are valid. They sit at different levels of abstraction and serve different audiences.

The repository is where the enterprise keeps the architecture knowledge that needs to stay connected: principles, standards, requirements, baseline views, target views, transition states, decisions, and governance records.

A repository is useful only if it lets a practitioner, board member, or delivery lead answer important questions quickly. What was decided? Why was it decided? What requirement or principle does it trace back to? What target state or work package does it affect? What exception, if any, was approved?

If the answer to any of these questions takes more than a few minutes to find, the repository is not doing its job. It might be storing information, but it is not making that information useful. The opening story of this module illustrates what happens when volume replaces traceability: the repository becomes a filing cabinet rather than a working system.

TOGAF C220 Part 5 identifies the following components that an architecture repository should contain. Each component serves a different purpose and stores a different type of architecture knowledge.

1. Architecture Metamodel

The metamodel defines the types of architecture content the repository can hold and the relationships between them. Think of it as the schema for the repository. It says: "a principle can be linked to a decision, a decision can be linked to a work package, a work package can be linked to a building block." Without a metamodel, the repository is an unstructured collection of files. With a metamodel, it becomes a connected knowledge system.

2. Architecture Capability

This component stores the parameters, structures, and processes that define the architecture practice itself. It includes the architecture organisation structure, the roles and responsibilities, the skills framework, the tools used, and the governance processes. It is the "how we do architecture" section of the repository.

3. Architecture Landscape

The architecture landscape stores the architectural representations at different levels of detail: strategic architectures (enterprise-wide, long-term direction), segment architectures (architectures for major divisions or business areas), and capability architectures (architectures that deliver specific capabilities). This component is where the baseline, transition, and target architecture descriptions live.

4. Standards Information Base (SIB)

The SIB captures the standards with which new architectures must comply. This includes industry standards (such as the CIM for electricity networks), regulatory standards (such as Ofgem data publication requirements), technology standards (such as approved platforms and products), and internal standards (such as integration patterns and security baselines). The SIB gives compliance reviews a clear reference point: every project's design can be checked against the SIB to determine conformance.

5. Reference Library

The Reference Library stores reference architectures, architecture patterns, templates, and other reusable assets. This is where the enterprise continuum meets the repository: assets classified as foundation-level, industry-level, or organisation-specific are stored here for reuse. When a new project starts, the team should check the Reference Library before designing from scratch.

6. Governance Log

The Governance Log stores the records of architecture governance activity: Architecture Board decisions, compliance review outcomes, waivers (exceptions approved when projects cannot fully comply), architecture contracts (agreements between architecture and delivery teams), and change requests. This is the audit trail. When the programme director asks "who approved the exception to use vendor X?" the answer should be in the Governance Log.

These six components are not six separate databases. They are six categories of content that the repository must organise and connect. The specific technology (a wiki, a modelling tool, a SharePoint site, or a purpose-built platform) is less important than whether the traceability between components works. Can you follow a chain from a principle (in the SIB) to a decision (in the Governance Log) to a work package (in the Architecture Landscape) to a building block (in the Reference Library)? If yes, the repository is working. If no, it is just a filing cabinet.

A reference architecture is a template architecture for a particular domain or technology area. It provides a starting point that can be tailored to the specific needs of an organisation. Reference architectures sit in the Reference Library component of the repository and are classified using the enterprise continuum.

Reference architectures save significant time and reduce risk because they capture proven patterns from prior implementations. Instead of designing a data publication architecture from scratch, London Grid could adopt an industry reference architecture for utility data publication and tailor it to the specific requirements of the LTDS.

TOGAF distinguishes between reference architectures at different points on the continuum. A foundation-level reference architecture (such as a generic microservices reference architecture) is applicable across industries. An industry-level reference architecture (such as a DSO integration reference architecture) is specific to the energy sector. An organisation-specific reference architecture (such as London Grid's standard integration pattern for connecting new applications to the enterprise service bus) is specific to one company.

The practical discipline is to adopt from the generic end of the continuum first and only create organisation-specific material when the generic or industry pattern does not fit. This maximises reuse and minimises the amount of bespoke design work the architecture team must maintain.

Part 0 of the Fundamental Content introduces architecture services as part of the conceptual front door to TOGAF. The idea is that the enterprise architecture capability does not just produce documents. It provides services to the enterprise. Those services are the practical ways the architecture capability creates value.

At this stage, the safest practical way to read that idea is to think about what the enterprise architecture capability does for the enterprise. In plain language, enterprise architecture services typically include:

• Guiding cross-enterprise design choices. When a project team needs to make a technology or integration decision that affects other parts of the enterprise, the architecture capability provides guidance to ensure coherence.
• Maintaining standards and reference material. The SIB and Reference Library do not maintain themselves. The architecture capability keeps standards current, publishes approved patterns, and retires outdated material.
• Supporting architecture work across change initiatives. When a transformation programme needs baseline analysis, gap analysis, or target state design, the architecture capability provides the expertise and the method.
• Keeping the repository usable. The repository needs curation, quality assurance, and ongoing structural maintenance. Without active stewardship, it degrades into the filing cabinet described in the opening story.
• Helping governance forums reach defensible decisions. The Architecture Board needs architecture input to make informed decisions about compliance, waivers, and technology direction. The architecture capability provides that input.
• Providing stakeholder communication and education. Architecture work is only effective if stakeholders understand and trust it. The architecture capability communicates architecture decisions, educates delivery teams about standards, and builds the organisational awareness that sustains the practice.

That is a practical interpretation, not a fixed universal service catalogue. The exact service set depends on the enterprise and the maturity of the capability. An organisation just starting its architecture practice might offer only two or three of these services. A mature organisation might offer all of them and more.

The danger is inventing a rigid catalogue that exists on paper but not in practice. The test is the same as for the repository: does the service actually help someone make a better decision? If the architecture team claims to provide "technology advisory services" but no project team has ever asked for advice, the service exists in name only.

Five common patterns signal that the continuum, repository, or services concepts have been adopted in name but not in practice:

• A repository that stores files but does not expose traceability. Documents are uploaded but there is no link from a principle to a decision to a work package. Finding the answer to a governance question requires manual search across multiple disconnected stores.
• A reuse conversation that ignores the continuum. Teams debate whether a pattern is "reusable" without asking whether it is generic, industry-shaped, or enterprise-specific. The result is either false universalism (treating an organisation-specific pattern as if it were universal) or unnecessary duplication (rebuilding a pattern that already exists at the industry level).
• A standards library that sits apart from requirements, decisions, and governance. The SIB exists as a list of approved technologies, but nobody connects it to the compliance review process or the governance log. Projects ignore the standards because there is no mechanism to check conformance.
• A capability that claims to provide services but cannot name who it helps. The architecture team has a service catalogue on paper, but no delivery team has ever requested any of the services. The services exist to justify headcount, not to create value.
• A repository organised only by folder hierarchy. Documents are filed by domain, by phase, or by date, but there is no cross-cutting traceability. The structure looks organised, but nobody can follow a decision from its rationale to its implementation without opening dozens of folders manually.

The London repository is deliberately atlas-like. Principles, stakeholder concerns, requirements, decisions, baseline, transition, target, and governance all point to one another so the learner can follow the architecture logic instead of opening disconnected pages.

What London Grid's repository would look like

Mapped to the six repository components from Section 4.4:

• Architecture Metamodel: defines the relationships between London Grid's architecture content. A regulatory driver (such as LTDS publication) links to a principle ("data published for regulatory purposes must come from a single authoritative source"), which links to a decision ("adopt the CIM for all network asset data"), which links to a work package ("migrate the asset register to CIM-compliant format").
• Architecture Capability: describes the architecture team structure, the tools used (modelling tool, repository platform, collaboration space), and the governance processes (Architecture Board terms of reference, compliance review schedule).
• Architecture Landscape: holds the baseline architecture (how London Grid operates today), the target architecture (how it should operate after transformation), and the transition architectures (the intermediate states that keep the lights on while the enterprise changes).
• Standards Information Base: contains the CIM standard, the Ofgem data publication requirements, the approved technology standards (platforms, security baselines, integration patterns), and the internal architecture principles.
• Reference Library: stores the industry reference architectures (DSO integration patterns, SCADA modernisation patterns, smart metering integration patterns) and the organisation-specific patterns (London Grid's standard integration approach, London Grid's data quality framework).
• Governance Log: records every Architecture Board decision, every compliance review outcome, every waiver granted, every architecture contract signed, and every change request processed.

Where London Grid sits on the continuum

London Grid's architecture assets span all four points of the enterprise continuum:

• Foundation: TCP/IP networking, relational databases, basic cybersecurity principles, cloud computing fundamentals.
• Common Systems: API gateway patterns, identity management, enterprise data warehouse, workflow engine patterns.
• Industry: CIM (IEC 61968/61970), SCADA architecture patterns, DMS reference architecture, LTDS data publication requirements, smart meter integration standards, flexibility market participation models.
• Organisation-specific: London Grid's asset register CIM mapping, London Grid's connections workflow integration, London Grid's Architecture Board charter, London Grid's data quality framework.

The course uses the repository to move from pressure to requirement, from requirement to standard, from standard to work package, and from work package to governance. Each important London artefact declares state, authority, date context, related artefacts, and the anti-pattern it is intended to prevent. The atlas is the applied version of the repository idea. It turns TOGAF vocabulary into a navigable enterprise system.