41.1 Overview

Operating a mature architecture capability within a large enterprise creates a huge volume of architectural output. Effective management and leverage of these architectural work products require a formal taxonomy for different types of architectural asset alongside dedicated processes and tools for architectural content storage.

This section of TOGAF provides a structural framework for an Architecture Repository that allows an enterprise to distinguish between different types of architectural assets that exist at different levels of abstraction in the organization. This Architecture Repository is one part of the wider Enterprise IT Repository, which provides the capability to link architectural assets to components of the Detailed Design, Deployment, and Service Management Repositories.

At a high level, six classes of architectural information are expected to be held within an Architecture Repository:

• The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a method for architecture development and a metamodel for architecture content.
• The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository.
• The Architecture Landscape shows an architectural view of the building blocks that are in use within the organization today (e.g., a list of the live applications). The landscape is likely to exist at multiple levels of granularity to suit different architecture objectives.
• The Standards Information Base captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization.
• The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise.
• The Governance Log provides a record of governance activity across the enterprise.

The relationships between these areas of the Architecture Repository are shown in Overview of Architecture Repository .

This section of TOGAF describes the structure and content of the repository areas that hold the output of projects, namely the Architecture Landscape, the Reference Library, the Standards Information Base, and the Governance Log.

This section also discusses requirements to be considered when selecting tools to manage an Architecture Repository.

41.2 Architecture Landscape

The Architecture Landscape holds architectural views of the state of the enterprise at particular points in time. Due to the sheer volume and the diverse stakeholder needs throughout an entire enterprise, the Architecture Landscape is divided into three levels of granularity:

1. Strategic Architectures (see Part I, 3.82 Strategic Architecture) show a long-term summary view of the entire enterprise. Strategic Architectures provide an organizing framework for operational and change activity and allow for direction setting at an executive level.
2. Segment Architectures (see Part I, 3.72 Segment Architecture) provide more detailed operating models for areas within an enterprise. Segment Architectures can be used at the program or portfolio level to organize and operationally align more detailed change activity.
3. Capability Architectures (see Part I, 3.31 Capability Architecture) show in a more detailed fashion how the enterprise can support a particular unit of capability. Capability Architectures are used to provide an overview of current capability, target capability, and capability increments and allow for individual work packages and projects to be grouped within managed portfolios and programs.

41.3 Reference Library

41.3.1 Overview

The Reference Library provides a repository area to hold best practice or template materials that can be used to construct architectures within an enterprise. Reference materials held in the Reference Library may be obtained from a variety of sources, including:

• Standards bodies
• Product and service vendors
• Industry communities or forums
• Corporately defined templates
• Best practice resulting from project implementation

Generally speaking, the source of a reference architecture is likely to have significant bearing on the way that architecture is used to support the execution of projects.

Reference models that originate from within the enterprise and have been tried and tested are likely to have a much better fit to the needs of the organization, because they will already be adapted to meet constraints of the enterprise. Reference models that originate from outside the enterprise are likely to have been tested by many enterprises and will therefore allow the adopting organization to adopt best practice and converge with peer organizations.

In order to segregate different classes of architecture reference model, the Reference Library can use the Architecture Continuum as a method for classification, as shown in Architecture Continuum .

The Reference Library classification scheme illustrates how reference architectures are organized across a range - from Foundation Architectures such as TOGAF's, through Common Systems Architectures, and Industry-Specific Architectures, to an enterprise's own individual architectures.

The enterprise needs and business requirements are addressed in increasing detail from left to right. The architect will typically look to find re-usable architectural elements toward the left of the range. When elements are not found, the requirements for the missing elements are passed to the left of the range for incorporation.

41.4 Standards Information Base

41.4.1 Overview

The Standards Information Base provides a repository area to hold a set of specifications, to which architectures must conform. Establishment of a Standards Information Base provides an unambiguous basis for architectural governance because:

• The standards are easily accessible to projects and therefore the obligations of the project can be understood and planned for
• Standards are stated in a clear and unambiguous manner, so that compliance can be objectively assessed

41.4.2 Types of Standard

Standards typically fall into three classes:

• Legal and Regulatory Obligations: These standards are mandated by law and therefore an enterprise must comply or face serious consequences.
• Industry Standards: These standards are established by industry bodies, such as The Open Group, and are then selected by the enterprise for adoption. Industry Standards offer potential for interoperation and sharing across enterprises, but also fall outside of the control of the enterprise and therefore must be actively monitored.
• Organizational Standards: These standards are set within the organization and are based on business aspiration (e.g., selection of standard applications to support portfolio consolidation). Organizational Standards require processes to allow for exemptions and standards evolution.

41.4.3 Standards Lifecycle

Standards do not generally exist for all time. New standards are identified and managed through a lifecycle process. Typically standards pass through the following stages:

• Trial Standard: A Trial Standard has been identified as a potential standard for the organization, but has not been tried and tested to a level where its value is fully understood. Projects wishing to adopt Trial Standards may do so, but under specific pilot conditions, so that the viability of the standard can be examined in more detail.
• Active Standard: An Active Standard defines a mainstream solution that should generally be used as the approach of choice.
• Deprecated Standard: A Deprecated Standard is approaching the end of its useful lifecycle. Projects that are re-using existing components can generally continue to make use of Deprecated Standards. Deployment of new instances of the Deprecated Standard are generally discouraged.
• Obsolete Standard: An Obsolete Standard is no longer accepted as valid within the landscape. In most cases, remedial action should be taken to remove the Obsolete Standard from the landscape. Change activity on an Obsolete Standard should only be accepted as a part of an overall decommissioning plan.

All standards should be periodically reviewed to ensure that they sit within the right stage of the standards lifecycle. As a part of standards lifecycle management, the impact of changing the lifecycle status should be addressed to understand the landscape impact of a standards change and plan for appropriate action to address it.

41.4.4 Standards Classification within the Standards Information Base

Standards within the Standards Information Base are categorized according to the building blocks within the TOGAF content metamodel. Each metamodel entity can potentially have standards associated with it (e.g., Business Service, Technology Component).

Standards may relate to "approved" building blocks (e.g., a list of standard Technology Components) or may specify appropriate use of a building block (e.g., scenarios where messaging infrastructure is appropriate, application communication standards are defined).

At the top level, standards are classified in line with the TOGAF architecture domains, including the following areas:

• Business Standards:
  • Standard shared business functions
  • Standard role and actor definitions
  • Security and governance standards for business activity
• Data Standards:
  • Standard coding and values for data
  • Standard structures and formats for data
  • Standards for origin and ownership of data
  • Restrictions on replication and access
• Applications Standards:
  • Standard/shared applications supporting specific business functions
  • Standards for application communication and interoperation
  • Standards for access, presentation, and style
• Technology Standards;
  • Standard hardware products
  • Standard software products
  • Standards for software development

41.5 Governance Log

41.5.1 Overview

The Governance Log provides a repository area to hold shared information relating to the ongoing governance of projects. Maintaining a shared repository of governance information is important, because:

• Decisions made during projects (such as standards deviations or the rationale for a particular architectural approach) are important to retain and access on an ongoing basis. For example, if a system is to be replaced, having sight of the key architectural decisions that shaped the initial implementation is highly valuable, as it will highlight constraints that may otherwise be obscured.
• Many stakeholders are interested in the outcome of project governance (e.g., other projects, customers of the project, the Architecture Board, etc.).

41.5.2 Contents of the Governance Log

The Governance Log should contain the following items:

• Decision Log: A log of all architecturally significant decisions that have been made in the organization. This would typically include:
  • Product selections
  • Justification for major architectural features of projects
  • Standards deviations
  • Standards lifecycle changes
  • Change request evaluations and approvals
  • Re-use assessments
• Compliance Assessments: At key checkpoint milestones in the progress of a project, a formal architecture review will be carried out. This review will measure the compliance of the project to the defined architecture standards. For each project, this log should include:
  • Project overview
  • Progress overview (timeline, status, issues, risks, dependencies, etc.)
  • Completed architecture checklists
  • Standards compliance assessment
  • Recommended actions
• Capability Assessments: Depending on their objectives, some projects will carry out assessments of business, IT, or architecture capability. These assessments should be periodically carried out and tracked to ensure that appropriate progress is being made. This log should include:
  • Templates and reference models for executing Capability Assessments
  • Business Capability Assessments
  • IT capability, maturity, and impact assessments
  • Architecture maturity assessments
• Calendar: The Calendar should show a schedule of in-flight projects and formal review sessions to be held against these projects.
• Project Portfolio: The Project Portfolio should hold summary information about all in-flight projects that fall under architectural governance, including:
  • The name and description of the project
  • Architectural scope of the project
  • Architectural roles and responsibilities associated with the project
• Performance Measurement: Based on a charter for the architecture function, a number of performance criteria will typically be defined. The Performance Measurement log should capture metrics relating to project governance and any other performance metrics relating to the architecture charter so that performance can be measured and evaluated on an ongoing basis.

return to top of page