Enterprise Continuum & Architecture Repository: Your Architecture Asset Library

Framework: Enterprise Continuum & Architecture Repository Perspective: Enterprise Architect

Every architecture programme reinvents the wheel. The Enterprise Continuum and Architecture Repository exist to stop that — and to build organisational architecture capital over time.

Key Inputs

Industry reference architectures (TOGAF TRM, eTOM, BIAN, SABSA, etc.)
Existing internal architectures and patterns
Vendor and partner architecture frameworks
Solution patterns from completed projects
Regulatory and compliance frameworks
Standards bodies publications

The Process

Identify and classify architecture assets
Position assets on the Architecture Continuum spectrum
Adapt generic frameworks to organisational context
Establish the Architecture Repository structure
Define governance for adding and retiring assets
Promote reuse across architecture and project teams

Deliverables

Populated Architecture Repository
Architecture Patterns Library
Reference Architecture(s) for key domains
Standards and Guidelines Catalogue
Architecture Principles Register
Governance Models documentation

Practitioner Perspective

The Enterprise Continuum is a classification spectrum running from generic industry frameworks at one end to organisation-specific solutions at the other. It answers the question: how do we connect what industry knows to what our organisation needs?

At the generic end sit TOGAF's own reference models (TRM, III-RM), industry frameworks (eTOM for telecoms, BIAN for banking, APQC for process), and vendor reference architectures. At the specific end sit your organisation's deployed solutions and custom-built systems.

As an EA, your job is to move assets deliberately along this continuum: take an industry reference model → adapt it to your sector context → tailor it further to your organisation's specific operating model and constraints. Each step adds specificity and therefore usefulness — but also reduces reusability. Know where on the continuum each asset belongs.

The Architecture Repository is where all of this lives and where the EA function's institutional memory resides. Structure it around four distinct areas:

Architecture Metamodel: how you describe architecture (your modelling conventions, notations, and standards)
Architecture Capability: how you do architecture (your methods, governance structures, and team practices)
Architecture Landscape: what your architecture currently is (baseline, transition, and target states)
Standards Information Base: what standards and guidelines constrain architecture decisions

The most common mistake: Building a repository that is an archive rather than a living resource. If architects do not consult the repository before making decisions, it has failed its purpose regardless of how well-populated it is.

Practical tips:

Define a "publishing standard" for the repository: any artefact added must include author, date, status (draft/approved/superseded), and associated ADM phase
Create a monthly "what's new" digest for the EA community highlighting recently added patterns, updated standards, and retired assets — discoverability drives reuse
Conduct an annual "repository health check": identify stale content, missing content, and orphaned artefacts with no clear owner
Connect the repository to your governance process: Architecture Review Board decisions should automatically generate repository updates

Part of a series: TOGAF from an Enterprise Architect's Perspective