TOGAF Architecture Repository: Organising EA Assets

What is the TOGAF Architecture Repository? (Quick Answer)

The TOGAF Architecture Repository is the central store for all architecture-related assets. It contains six classes of information: the Architecture Metamodel, Architecture Capability, Architecture Landscape, Reference Library, Standards Information Base, and Governance Log. Together, these give the architecture team a single source of truth for current-state designs, approved standards, reusable patterns, and governance records.

After you've mapped your architecture entities using the Content Metamodel, you need a place to store them. This is where the Architecture Repository comes in.

In the world of Enterprise Architecture, information is your most valuable asset. But information that is scattered across different spreadsheets, emails, and outdated diagrams is useless. The TOGAF Architecture Repository is the central vault that organizes all your architecture-related data, standards, and governance records.

The Six Classes of the Architecture Repository

TOGAF defines six distinct classes that make up the repository. Each class has a specific purpose and holds different types of information.

1. Architecture Metamodel

Think of the Architecture Metamodel as the instructions for the rest of the repository. It defines what data you collect and how that data is structured. If you're using the standard TOGAF Content Metamodel, this is where it lives.

2. Architecture Capability

The Architecture Capability class contains information about the architecture team itself. This includes the team's charter, roles and responsibilities, skills and training records, and the governance structures they use to make decisions.

3. Architecture Landscape

The Architecture Landscape is the most active part of the repository. It contains the actual diagrams and documentation for your enterprise at different levels of detail.

Strategic Architecture: High-level, enterprise-wide views.
Segment Architecture: Detailed views of specific business units or programs.
Capability Architecture: Granular designs for specific projects or solutions.

4. Reference Library

Architects don't need to reinvent the wheel. The Reference Library contains reusable design patterns, industry templates, and best-practice models that the architecture team can draw from when starting a new project.

5. Standards Information Base (SIB)

The Standards Information Base (SIB) is the rulebook. It contains the list of all approved standards the enterprise must follow. This includes technology standards (e.g., "All databases must be PostgreSQL"), security standards, and business standards.

6. Governance Log

The Governance Log is the historical record. It contains the outputs of all architecture governance activity, including:

Minutes from the Architecture Board meetings.
Compliance assessments.
Approved architecture waivers (where a project was allowed to deviate from standards).
Status reports on implementation projects.

Why a Central Repository is Vital for EA Success

A well-maintained Architecture Repository provides several critical benefits:

1. Single Source of Truth

No more arguments about which "v3_final_final.pdf" diagram is the current one. The repository ensures everyone is working from the same baseline.

2. Reusability

By storing reusable patterns in the Reference Library, you speed up new projects and ensure a consistent "look and feel" across the enterprise.

3. Impact Assessment

When something changes, you can use the repository to trace the impact. If a technology standard in the SIB is updated, you can instantly see which systems in the Architecture Landscape are now non-compliant.

4. Continuous Improvement

The Governance Log allows the architecture team to learn from past mistakes. By reviewing previous waivers and project outcomes, you can refine your standards and metamodels over time.

Tooling Choices for the Architecture Repository

Organizations implement the Architecture Repository using a range of tools:

Enterprise Architecture platforms: Tools like Sparx EA, BiZZdesign HoriZZon, and Alfabet provide built-in support for all six TOGAF repository classes, including structured metamodels, governance logging, and impact analysis.
Wiki-based repositories: Teams early in their EA maturity often use Confluence or SharePoint. These work well for the Reference Library and Governance Log but lack the structured relationship management needed for a complete Architecture Landscape.
ArchiMate modeling tools: Tools like Archi (free) or iServer support the Architecture Landscape with structured, navigable models. See our ArchiMate modeling guide for how diagrams relate to repository classes.

The key principle is that the tool should serve the process, not the other way around. A well-maintained Confluence repository outperforms a neglected enterprise platform.

For governance guidance on what goes into the Governance Log and how the Architecture Board uses the SIB, see our architecture principles and governance post. The official TOGAF repository specification is available from The Open Group.

Key Takeaways

The Architecture Repository is the central store for all EA assets — not just diagrams, but standards, governance records, reference patterns, and the metamodel itself.
The six classes (Metamodel, Capability, Landscape, Reference Library, SIB, and Governance Log) each serve a distinct purpose; conflating them leads to a disorganised repository that nobody trusts.
The Standards Information Base is the most operationally powerful class — it defines what technology teams must use, not just what is recommended.
Governance Logs earn their value during impact assessments and audits; organisations that maintain them consistently can answer compliance questions in hours rather than days.
A well-maintained Reference Library turns one-time architecture work into reusable institutional knowledge, compounding the value of every engagement.
The Governance Log is particularly important for the Architecture Board: it provides the historical record that justifies waiver decisions and informs future standards updates.
The repository is defined formally in the TOGAF standard published by The Open Group, and the full specification of each class is available in the TOGAF 9.2 Architecture Content chapter.
Start small: even a well-structured SharePoint or Confluence space is a functioning repository if the six classes are represented and consistently maintained.

Summary

The TOGAF Architecture Repository is much more than a file server. It is a structured information environment that supports the entire architecture lifecycle. From the standards in the SIB to the detailed designs in the Landscape, the repository gives the architecture team the data they need to provide strategic value to the organization.

In our next post, we will look at the specific items generated during the ADM: TOGAF Artifacts and Deliverables — The Complete Architect’s Checklist.

This post is part of the TOGAF 9.2 Masterclass series. Don’t forget to check out our previous post on The TOGAF Content Metamodel.

Common Mistakes with the Architecture Repository

1. Treating the repository as a document archive rather than a living system The Architecture Repository's value comes from its contents being current, cross-referenced, and actively used by architects and governance bodies. A repository that contains only historical project artefacts — never updated, never referenced — provides no governance benefit. Assign a named owner for repository maintenance and build update triggers into the architecture governance process.

2. Not distinguishing between Architecture Landscape levels The Architecture Landscape has three levels of abstraction: Strategic (enterprise-wide capability direction), Segment (business unit or programme), and Capability (specific solution). Mixing artefacts from all three levels in the same view creates confusion. Organise the repository to reflect these levels clearly, with explicit traceability relationships showing how segment architectures implement strategic intent.

3. Storing tools and implementation artefacts in the wrong location The Standards Information Base (SIB) holds approved standards and technology positions. The Solutions Continuum holds vendor solutions, packaged applications, and reusable components. Storing a vendor-specific implementation guide inside the Architecture Continuum (which should hold vendor-neutral architecture descriptions) corrupts the conceptual integrity of the repository structure.

4. No access control policy The Architecture Repository contains sensitive information: security architectures, infrastructure designs, and strategic transformation plans. Without access controls, this information is accessible to anyone who can find the repository. Define access tiers: public (architectural principles, approved standards), internal (current state architecture), restricted (security architecture, strategic options).

5. Failing to connect the repository to project governance The repository's real governance value comes when project teams are required to reference it at Architecture Compliance review gates. If project architects can produce designs without consulting the Architecture Landscape or the Standards Information Base, the repository has no impact on delivery consistency. Make repository consultation a mandatory step in the project lifecycle.

Frequently Asked Questions

What are the six components of the TOGAF Architecture Repository? The six components are: (1) Architecture Metamodel — the organisation's specific application of TOGAF's content framework; (2) Architecture Capability — parameters and standards governing the architecture practice itself; (3) Architecture Landscape — the portfolio of architecture descriptions at Strategic, Segment, and Capability levels; (4) Standards Information Base (SIB) — approved technology standards and patterns; (5) Reference Library — external reference architectures and guidelines; (6) Governance Log — the record of governance activity, decisions, and compliance assessments. The TOGAF standard Architecture Repository section defines each component in detail.

What is the Standards Information Base (SIB)? The SIB is the section of the Architecture Repository that records approved technology standards — hardware, software, middleware, cloud services, and development frameworks — along with their status (Current, Containment, Retirement, Emerging). The Technology Standards Catalogue produced in Phase D feeds directly into the SIB. It is the definitive reference a project team consults to determine which technologies are approved for use in new solutions.

What tools can host an Architecture Repository? Enterprise architecture tools that support TOGAF repository structures include BiZZdesign HoriZZon, Sparx Enterprise Architect, Mega HOPEX, Avolution ABACUS, and LeanIX. For smaller organisations or teams just establishing an EA practice, a structured SharePoint site, Confluence space, or even a well-organised Git repository can fulfil the repository role. The tool matters less than the discipline of keeping the content current and the governance process connected to it. The Open Group TOGAF Tooling guidance provides evaluation criteria.