Purpose of Major Architecture Repository Components

Hello. Last lesson, you distinguished catalogs, matrices, and diagrams by the questions they answer. Those artifacts are useful during a project, but they become more valuable when people can find them again, understand their status, and reuse them. That is the purpose of an Architecture Repository.

This lesson is about recognizing the repository’s major areas by what each holds or enables. You do not need experience with a repository tool to understand it: think of an architecture team trying to answer questions such as “What architecture do we have?”, “Which standards apply?”, and “Why was that decision approved?”

A repository is more than a document store

The Architecture Repository organizes information used to develop and govern enterprise architecture. It holds descriptions of architectures, materials that can be reused, applicable standards, and records of governance. Keeping these distinct matters. A proposed application design, an approved application standard, and a record of an exception to that standard might concern the same application, but they serve different purposes.

Start with the overview in Architecture Repository, reproduced by the QualiWare Center of Excellence. This page presents an earlier TOGAF edition, so use it to learn the components’ functions rather than treating every boundary or term on the page as a definitive exam list for the TOGAF Standard, 10th Edition.

The illustration below brings these functions together. Its labels include the six areas named in the reading, plus areas for architecture requirements and solutions. Follow the labels first; the connecting lines show that information in one area can inform or be governed through another.

There is a source-version distinction worth noticing rather than hiding. The earlier-edition reading lists six classes of information in the Architecture Repository and describes requirements and solutions as supporting repositories in the wider Enterprise Repository. The illustration places Architecture Requirements Repository and Solutions Landscape within its pictured repository structure. Do not use their differing boundaries to infer that one picture supplies an authoritative list for your current-edition exam. The dependable learning target here is the purpose of every named area.

Where architecture descriptions and reusable guidance live

Consider the order-status example from the previous lesson. An architecture team has described the Customer Portal, Order Service, and Notification Service in catalogs, matrices, and diagrams. If another team later needs to understand that architecture, where should it look?

The Architecture Landscape holds architectural representations of the enterprise at particular points in time. It can describe what is in use and what is planned—not merely an inventory of today’s systems. Different levels provide different scopes of understanding: a strategic architecture gives a broad enterprise view; a segment architecture concentrates on an area of the enterprise; and a capability architecture examines what is needed to support a particular capability. The portal’s relationships with other applications might appear in a relevant landscape view. The artifact could be a diagram or catalog; the Landscape is the repository area in which such architecture descriptions are organized.

Before creating a new architecture, however, the team may want an established pattern for describing customer-facing services, or a template for an architecture view. That points to the Reference Library. It holds materials intended to help people develop architectures: for example, reference architectures, reference models, viewpoints, templates, guidelines, and patterns. A reference architecture is not automatically the architecture this enterprise has adopted; it is material the team can consider and adapt.

There is a third, easily confused area. The Architecture Metamodel defines how the organization structures its architecture information and applies its architecture method. Recall the Content Metamodel from an earlier lesson: it specifies the kinds of architectural concepts and relationships that can be described. The repository’s Architecture Metamodel area concerns that organizing framework, including the organization’s tailored method and content structure. It is not the collection of portal diagrams themselves.

A useful distinction is therefore: the Metamodel defines how architecture information is structured; the Landscape holds representations of architectures; the Reference Library offers material to draw on when creating them.

Read the Reference Library’s opening description in the same source before considering standards.

The Standards Information Base, often shortened to SIB, holds standards and specifications with which architectures must comply. An adopted data-format standard for exchanging order information would belong here. A helpful example data model for designing an order service might instead belong in the Reference Library. The difference is not whether both are useful or whether both came from outside the enterprise. It is their role: one provides an applicable standard against which compliance can be assessed; the other provides material to guide design.

“Standard” also does not mean “anything published by a standards body.” A standard may be a legal or regulatory obligation, an industry standard selected for use, or one set within the organization. Conversely, a reference model obtained externally does not become a mandatory enterprise standard merely because it is stored for reuse. What the enterprise has adopted, and on what terms, matters.

Who governs the architecture, and where are the decisions recorded?

A repository needs both a way to run the architecture function and a history of what that function has done. These are distinct areas.

Architecture Capability concerns the organizational ability to perform and govern architecture work: its structures, responsibilities, skills, and processes. In repository terms, it describes how that capability is established and how the repository is governed. If you ask, “Who is responsible for maintaining architecture assets and overseeing their use?”, you are asking about capability. This area is not simply a catalog of business capabilities or the detailed architecture of one business capability—the similar words refer to different things.

The Governance Log is the record of architecture governance activity. It can retain significant decisions, their rationale, approvals or deviations, and assessments of whether projects comply with architecture standards. Suppose a project is permitted to use a nonstandard integration method for a limited period. The applicable standard belongs in the SIB; the decision to grant a deviation and its rationale belong in the Governance Log. Keeping both makes a later review possible without pretending the exception changed the standard itself.

The illustration names two more areas whose purposes you should recognize. The Architecture Requirements Repository holds architecture requirements—the needs and constraints that drive architecture work and must be managed as that work develops. For the order-status initiative, a requirement that customers must be able to see an order’s current status belongs with requirements, not with the record of a governance decision about an exception.

The Solutions Landscape concerns the solution building blocks that put architecture into effect. If the order-status work results in an implemented portal or service, that solution is different from an architectural description of the intended arrangement. The reading uses the related term Solutions Repository; the illustration uses Solutions Landscape. For now, recognize the practical separation between requirements that drive the work, architecture descriptions, and solutions that realize it. A later lesson will examine how reusable architecture assets are classified.

Locating information by the question being asked

The component names become easier to retain when you imagine looking something up. If the question is “What are our existing and planned applications, and how do they relate?”, begin with the Architecture Landscape. If it is “What template or reference pattern could help us design this?”, look in the Reference Library. If it is “Which data standard must this design meet?”, consult the Standards Information Base.

Other questions concern the architecture practice itself. “How do we define and organize architecture content here?” points to the Architecture Metamodel. “Who maintains this practice, with what responsibilities and processes?” points to Architecture Capability. “Why was an exception approved, and what did the compliance review find?” points to the Governance Log.

Finally, “What need is driving the change?” points to the Architecture Requirements Repository, while “What solution building blocks address it?” points to the Solutions Landscape. These areas are connected, but connection does not make them interchangeable. An architecture diagram may refer to a requirement, follow a standard, depict a planned solution, and be subject to a governance decision. Each piece of information still has its own purpose and appropriate place.

Key takeaways

The Architecture Repository helps people find, reuse, and govern architecture information. Its major areas distinguish the structure used to describe architecture (Metamodel), architecture descriptions (Landscape), reusable design guidance (Reference Library), applicable standards (SIB), the ability to run architecture work (Architecture Capability), and records of governance (Governance Log). Also recognize the roles of the Architecture Requirements Repository and Solutions Landscape shown in the illustration, while remembering that the supplied earlier-edition text groups repository areas differently.

Next, you will look at the Enterprise Continuum: a way to classify architecture assets so that people can communicate what is broadly reusable and what has been adapted for a particular enterprise.