A Scrapbook of Past Projects

Link: https://eawheel.com/blog/2026/03/a-scrapbook-of-past-projects/

From EAWheel

Enterprise Architecture has a reputation problem. Not because it lacks rigor or structure — quite the opposite. But because too often, architecture feels like something that exists next to the organization rather than within it. Diagrams live in tools, standards sit in documents, and architectural knowledge slowly fragments across folders, platforms, and people’s heads. It’s kind of like an intangible scrapbook of past projects.

The Architecture Repository, as described in the TOGAF® Standard, is an attempt to fix that. Not by introducing yet another tool or database, but by introducing a way of thinking. A way of treating architecture as a coherent, evolving body of knowledge — one that can be reused, governed, and continuously refined.

What makes the Architecture Repository interesting is not what it stores, but what it connects.

An Intangible Concept with Tangible Consequences

One of the first things the TOGAF Standard is very explicit about is also one of the most easily misunderstood points: the Architecture Repository is not a tool.

This often comes as a surprise, even to experienced architects. Many organizations believe that once they buy an enterprise architecture tool, they “have” a repository. But the repository is not software. It is an intellectual construct. A conceptual container that defines what architectural assets exist, how they relate, and how they are governed over time.

Tools can implement the repository. They cannot replace it.

This distinction matters because it shifts the conversation away from features and dashboards and back toward intent. The Architecture Repository exists to ensure that architecture is consistent, reusable, and evolvable, regardless of how fashionable the tooling landscape becomes. In practice, the repository functions as the backbone of the Enterprise Architecture practice. It is where principles, standards, models, requirements, and building blocks come together. Not as isolated artifacts, but as parts of a larger whole.

The Repository as a Central Hub

If you imagine Enterprise Architecture as a living system, then the Architecture Repository is its nervous system. Everything passes through it:

• architectural principles
• reference models
• standards
• requirements
• building blocks
• views and viewpoints
• governance decisions

This does not mean the repository contains everything. Quite the opposite. A well-designed repository is selective by design. It contains what is architecturally reusable, governable, and meaningful across initiatives. Another important aspects that is often misunderstood.

One of the more important points to remember is that solution diagrams do not belong in the Architecture Repository. The repository is not a scrapbook of past projects. It is a curated collection of assets that can be applied again and again.

This alone changes how architects should think about their work. Instead of producing one-off deliverables, they should begin producing architectural capital.

The Architecture Landscape

At the heart of the repository lies the Architecture Landscape. This landscape provides a structured view of the organization’s architecture across time and scale. It answers three deceptively simple questions:

• What does the architecture look like today?
• Where is it heading?
• How detailed do we need to be right now?

To manage this, the TOGAF Standard introduces three levels of granularity:

• Strategic Architecture: This is the long view. Strategic Architectures describe the organization at a high level and provide direction rather than detail. They are primarily concerned with alignment between business intent, operating models, and long-term change.
• Segment Architecture: Segment (or domain) architectures zoom in on specific areas of the organization. They translate strategy into operating models that portfolios and programs can actually work with.
• Capability Architecture: At the most detailed level, Capability Architectures show how specific capabilities are realized, evolved, and incrementally improved. This is where architecture meets delivery.

Together, these levels allow architecture to be both stable and adaptable — a theme that becomes increasingly important when working in agile or hybrid environments.

Libraries That Enable Reuse, Not Reinvention

To the side of the Architecture Landscape sit two deceptively simple components: the Reference Library and the Standards Library.

• The Reference Library contains guidance: patterns, templates, reference architectures, and viewpoints. It accelerates architecture work by making proven approaches easily accessible.
• The Standards Library, on the other hand, defines non-negotiables. Legal mandates, industry standards, and internal policies all live here. Together with governance mechanisms, they ensure consistency and compliance.

What matters is not the size of these libraries, but their curation. Too many organizations collect standards and references without ever integrating them into architectural practice. In a well-functioning repository, libraries are actively used — not passively stored.

Governance and Capability

Architecture does not govern itself. The Governance Repository captures decisions, waivers, approvals, and compliance assessments. It provides traceability and accountability — two qualities that architecture desperately needs in complex organizations.

Closely related is the Architecture Capability itself: the roles, skills, processes, and structures that enable architecture work to happen at all.

Together, these elements are typically overseen by an Architecture Board — not as a bureaucratic hurdle, but as a forum for direction, escalation, and alignment. Without governance and capability, even the best repository becomes a static archive.

Building Blocks Are Architecture’s LEGO¹ Bricks

Remember what I said earlier about the repository?

The repository is not a scrapbook of past projects. It is a curated collection of assets that can be applied again and again.

At the most fundamental level, architecture is built from building blocks. The LEGO analogy is more than a metaphor. Like LEGO bricks, building blocks are modular, reusable, and combinable at different levels of detail.

The TOGAF Standard distinguishes between:

• Architecture Building Blocks (ABBs): the what and why
• Solution Building Blocks (SBBs): the how

ABBs define required capabilities without committing to technology. SBBs implement those capabilities using concrete products and services.

This separation allows architecture to remain stable even as technology choices change — a critical property in today’s fast-moving landscapes.

Architecture Is About Communication

Architecture only has value if it can be understood. That is why views and viewpoints are such an essential part of the Architecture Repository. A viewpoint defines how to look; a view shows what is seen.

Different stakeholders care about different concerns:

• executives care about direction and risk
• engineers care about structure and integration
• users care about usability and outcomes

The repository does not force a single perspective. Instead, it enables many perspectives on the same underlying architecture. This is where architecture stops being abstract and starts becoming persuasive.

From Concept to Practice

Eventually, the intangible must become tangible. Architecture tools are the most common way to implement an Architecture Repository in practice. However, these tools should follow the repository concept — not redefine it.

A good tool supports the relationships between entities, a consistent metamodel, reuse across artifacts, and the publication and communication of the architecture. The repository should contain only what the Enterprise Architecture actually needs.

A significant factor that results in a well-run sustainable EA Repository is the ruthless minimization of information gathered and maintained.²

Architecture as a Living System

The Architecture Repository is not glamorous. It does not promise instant insight or colorful dashboards. What it offers instead is something far more valuable: continuity.

Continuity between strategy and execution, between past decisions and future change, and between architecture as theory and architecture as practice.

When done well, the Architecture Repository becomes the place where architecture stops being episodic and starts being institutional.

Not a tool. Not a document. But a shared, evolving understanding of how the organization works — and how it intends to change.

This blog is based on the chapter Architecture Repository from my book Mastering the TOGAF® Standard.

1. LEGO® is a registered trademark of the LEGO Group ︎
2. A Practitioners’ Approach to Developing Enterprise Architecture Following the TOGAF® ADM ︎

The post A Scrapbook of Past Projects appeared first on EAWheel.