Why Most Architecture Repositories End Up Gathering Dust
Ask any organization that has adopted TOGAF about its Architecture Repository, and you will often hear the same story: “We built it, but nobody keeps it up to date.” In practice, three problems are usually to blame:
- People disagree about what belongs in which part of the repository, so content is filed inconsistently.
- Extracting information from meeting minutes and design documents, then reformatting it, takes far too much effort.
- Nobody can trace the links between requirements, architectures, standards, and products, so the repository stops being useful.
This article walks through the eight classes of information that the TOGAF Standard, 10th Edition, defines for the TOGAF Architecture Repository, using a concrete example from an automotive parts manufacturer. It then shows how to populate the repository efficiently with generative AI, using three building blocks: AI prompts, input templates, and Excel output templates.
What Is the TOGAF Architecture Repository?
The Architecture Repository is where the outputs of architecture work are stored and managed. It sits within the broader Enterprise Repository. Note that “EA Repository” is not an official TOGAF term.
TOGAF 10 specifies eight classes of information to be held in the Architecture Repository:
| Component | Purpose |
| Architecture Metamodel | The rules for how architecture is developed and represented |
| Architecture Capability | The organization, roles, skills, and processes that support EA |
| Architecture Landscape | The architecture of the enterprise at specific points in time |
| Standards Library | The standards every new architecture must comply with |
| Reference Library | Reusable reference models, templates, and patterns |
| Governance Repository | Records of decisions, compliance assessments, and other governance activity |
| Architecture Requirements Repository | Architecture requirements approved by the Architecture Board |
| Solutions Landscape | The products and solutions (SBBs) that realize the ABBs |
In TOGAF 9.2, the Standards Library was called the Standards Information Base (SIB), and the Governance Repository was called the Governance Log. If you are preparing for certification, it pays to know both sets of names.
The 8 Components Through a Real-World Example
To make this concrete, consider “Company A,” a fictional automotive Tier 1 supplier. It operates in Japan, Thailand, and the United States and is consolidating its global ERP on SAP S/4HANA. Its goal is to achieve “One ERP, One Master” by 2030. The first area to go live is Order-to-Cash (O2C): Japan in April 2027, followed by Thailand in April 2028.
1. Architecture Metamodel: The Rules of Representation
This component defines how the organization tailors the ADM (Architecture Development Method), along with the entities and relationships it manages. Company A runs Phases A through F in quarterly cycles and folds Phases G and H into its existing PMO gate reviews. It also added a custom entity that is not part of the TOGAF standard metamodel, “Plant” (manufacturing site), to track site-by-site rollouts.
Always record why you added a custom entity. Extensions without a documented rationale become impossible to explain a few years later.
2. Architecture Capability: Organization and Skills
This component covers the Architecture Charter, the Architecture Board, roles, skills, processes, and tools. Company A’s Architecture Board, chaired by the CIO, meets monthly and must review every IT initiative worth ¥100 million or more. However, the company has no Data Architect yet and plans to appoint one by March 2027.
Recording current maturity, target maturity, and improvement actions together turns this component into a practical improvement plan for the EA function itself.
3. Architecture Landscape: The Enterprise at Points in Time
This component is described across three levels, Strategic (enterprise-wide), Segment (business area), and Capability (individual capability), and three states, Baseline (current), Transition, and Target.
| ID | Level | State and date | Description |
| AL-000 | Strategic | Target 2030-03 | A single ERP and unified master data across the enterprise |
| AL-001 | Segment | Baseline 2026-10 | O2C in Japan and Thailand, with a separate order system at each site |
| AL-003 | Segment | Target 2028-04 | Order, credit, shipping, and billing management on a single ERP |
| AL-004 | Capability | Target 2028-04 | Automated intake of EDI orders |
The key point: describe ABBs (Architecture Building Blocks) in functional terms such as “order management,” not by product name. Products belong in the eighth component, the Solutions Landscape. With this separation in place, you can replace a product without rewriting the architecture.
4. Standards Library: What Must Be Followed
Standards are classified into three types, legal and regulatory obligations, industry standards, and organizational standards. Each is managed through its lifecycle: Trial, Active, Provisional, Deprecated, or Obsolete. Company A registered Japan’s Electronic Bookkeeping Act (regulatory), TISAX AL3 (industry), and “Use SAP S/4HANA as the core ERP, implemented with a Fit-to-Standard approach” (organizational), among others. Direct point-to-point connections through its legacy EAI product are now Deprecated, and an integration platform standard has been designated as the replacement.
Write each standard’s compliance check as a statement that can be answered yes or no. That way, it doubles as a ready-made checklist for compliance reviews.
5. Reference Library: Materials to Reuse
These are reference materials that are not mandatory. Classify them along the Enterprise Continuum: Foundation (such as the TOGAF TRM), Common Systems (III-RM), Industry (SAP Best Practices), and Organization-Specific (the company’s own global ERP template).
A common mistake is putting mandatory rules in the Reference Library. Keep the distinction clear: what you must follow goes in the Standards Library; what you can draw on goes in the Reference Library.
6. Governance Repository: The Governance Record
This component holds the Decision Log, Compliance Assessments, Capability Assessments, the Calendar, the Project Portfolio, and Performance Measurement. Company A’s Decision Log records the decision to keep the Thailand site’s order add-on for a fixed two-year period, a dispensation (an approved exception) from the standard, together with the rationale and alternatives considered. A compliance assessment found that 3 of 12 add-ons did not conform to the standard.
7. Architecture Requirements Repository: Approved Requirements
Requirements agreed with the Architecture Board are recorded one per row, in a verifiable form. For example, Company A’s requirement “Customer EDI orders can be registered without manual intervention” has the acceptance criterion “At least 95% of EDI orders are registered automatically.”
8. Solutions Landscape: The Actual Products
This component manages the SBBs (Solution Building Blocks) that realize the ABBs. Company A registered SAP S/4HANA Cloud Private Edition, SAP Integration Suite, SAP Master Data Governance, and its plant MES, among others, each with its status (planned, in implementation, live, or scheduled for retirement) and timing.
The Real Value Comes From Connecting the 8 Components
The true value of an Architecture Repository lies in tracing a single decision across components. In Company A’s case, the chain looks like this:
- Requirement RQ-011, “Automated intake of EDI orders,” is approved.
- The target state is described in Capability Architecture AL-004 and Segment Architecture AL-003.
- It is realized by SB-004 (S/4HANA) and SB-007 (Integration Suite).
- Compliance with standards SL-003 (Fit-to-Standard) and SL-004 (integration standard) is verified.
- The Thailand exception is approved in GR-021, and the nonconformance is recorded in GR-022.
When every record carries a related requirement ID, related standard ID, and related architecture ID, you can trace the rationale behind any decision in seconds, whether for an audit or an investment review.
Using Generative AI to Populate the Repository Efficiently
Extracting information for the eight components from meeting minutes and design documents is exactly the kind of work generative AI does well. Left to its own devices, however, AI may introduce facts that are not in the source or produce inconsistent output formats. The solution is to combine three building blocks.
A Shared System Prompt
This defines the rules that apply to every component. The main rules are:
- Never invent facts that are not in the input. When inferring, lower the confidence rating and state the basis.
- Never leave a field blank; enter “To be confirmed” instead.
- Output TSV (tab-separated values) with a fixed column order.
- Always record links to IDs in other components.
- Never let AI fill in management fields such as status and approval date; people complete those.
Input Templates
For each component, the input templates define the required inputs (72 items in total), each marked as mandatory or optional and accompanied by an example. Consistent inputs produce consistent outputs.
Excel Output Templates
Each component has its own worksheet. Columns completed by AI are color-coded separately from management columns completed by people (status, owner, version, approval date, and run ID). Dropdowns restrict values to defined options, and a run log records which AI was used, which inputs it received, and who reviewed the output.
Sample Prompt: Architecture Requirements Repository
Of the eight components, here is the prompt for the Architecture Requirements Repository. Requirements tend to be scattered across meeting minutes and workshop notes, which makes this component the clearest demonstration of what AI can do.
Use this prompt with the shared system prompt placed in front of it.
text
# Task
Create entries for the “Architecture Requirements Repository” component of the Architecture Repository.
# Component definition (TOGAF Standard, 10th Edition)
Approved architecture requirements agreed with the Architecture Board. Includes requirements at the Strategic, Segment, and Capability levels, and is used across all ADM phases to record and manage requirements.
# Input
– Source of requirements: Requirements definition workshop record, 2026-09
– Business drivers and goals: Reduce order-processing effort by 30%; accelerate financial close
– Stakeholders: Sales Administration, Finance, Thailand site
– Original requirement statements: We want EDI orders to be imported automatically. We want to close the monthly books within three business days.
– Expected level: Segment
– Constraints and assumptions: Go-live in April 2028; a cloud ERP is assumed
– Related architecture ID: AL-003
– Existing IDs: RQ-001 to RQ-009
# Procedure
1. Break the input down into atomic requirements, one requirement per row.
2. Assign a level (Strategic / Segment / Capability) and a type (Functional / Non-functional / Constraint / Assumption / Principle-derived).
3. Phrase each requirement as “… can …”. Do not name products unless the input explicitly states them as a constraint.
4. Write acceptance criteria as measurable values or conditions (SMART).
5. Assign MoSCoW priorities (Must / Should / Could / Won’t). If there is no basis for a priority, enter “To be confirmed”.
6. If any requirements overlap or conflict, note this in the “Open questions” column with the other requirement’s ID.
7. Record the approval status exactly as given in the input; if unknown, enter “Not submitted”.
# Output format
Output TSV (tab-separated values) with the following columns, in this order:
Requirement ID / Requirement name / Level / Type / Domain / Requirement statement / Business driver / Stakeholders / Priority / Acceptance criteria / Related architecture ID / Related standard ID / Approval status / Basis and source / Confidence / Open questions
– ID convention: Three-digit sequential numbers starting at RQ-001 (continue from existing IDs if any)
– Allowed values: Level = Strategic / Segment / Capability; Type = Functional / Non-functional / Constraint / Assumption / Principle-derived; Priority = Must / Should / Could / Won’t; Approval status = Not submitted / Under review / Approved / Rejected; Domain = Business / Data / Application / Technology / Cross-domain; Confidence = High / Medium / Low
– In the “Basis and source” column, cite the document or input item used
# Quality checks before output
– Does any row contain more than one requirement?
– Are all acceptance criteria verifiable?
– Does every requirement have a business driver and stakeholders?
– Have you stated anything that is not in the input?
– Do all columns with allowed values contain only defined values?
Note: In the actual prompt, the output columns are separated by tabs. They are shown separated by ” / ” here for readability.
Sample Output
The prompt produces rows like these (key columns only):
| Requirement ID | Requirement name | Level and type | Acceptance criteria | Priority | Confidence | Open questions |
| RQ-010 | Faster monthly close | Segment, Non-functional | Monthly books closed within three business days for three consecutive months | Must | High | None |
| RQ-011 | Automated intake of customer EDI orders | Capability, Functional | At least 95% of EDI orders registered automatically | To be confirmed | Medium | Confirm the target automation rate |
| RQ-012 | Thailand site go-live deadline | Segment, Constraint | Pass the go-live decision on 2028-04-01 | Must | High | None |
Notice what the AI does when the input gives no basis for a priority, or when it has to infer a target value: it returns “To be confirmed” and a confidence rating of “Medium.” AI output is only a draft. It becomes an official repository record only after people review it and the Architecture Board approves it.
Practical Tips for Day-to-Day Operation
Separate the Roles of AI and People
AI handles extraction, formatting, and flagging gaps; people handle judgment and approval. Keeping status and approval dates out of AI’s hands makes this division of labor explicit.
Use Confidence Ratings to Focus Reviews
Concentrate your reviews on rows rated “Medium” or “Low” confidence and rows with open questions. This keeps review effort under control.
Handle Confidential Information With Care
Meeting minutes and design documents often contain confidential information. Always check your company’s generative AI usage policy and the data handling terms of the AI service you use.
Summary
- The TOGAF 10 Architecture Repository consists of eight components, and its value comes from connecting them.
- Separating ABBs from SBBs, and the Standards Library from the Reference Library, determines the quality of the repository.
- Combining a shared system prompt, input templates, and Excel output templates lets you populate the repository efficiently with generative AI.
- Treat AI output as a draft, and use confidence ratings and open questions to guide human review and approval.
The Excel template featured in this article, which includes prompts for all eight components, input templates, output worksheets, a run log, and the Company A example, is available at [Download page URL].
References
- The Open Group, “TOGAF Standard — Architecture Content: Architecture Repository”
- The Open Group, “TOGAF 9.2 — Architecture Repository”
- microTOOL, “What Is the TOGAF Standard?”
Disclaimer
Parts of this article were developed with reference to generative AI suggestions and were reviewed, refined, and supplemented based on the author’s professional expertise and judgment.
Leave a Reply