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 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 Repository, which provides the capability to link architectural assets to components of the Detailed Design, Deployment, and Service Management Repositories.
At a high level, the following classes of architectural information are expected to be held within an Architecture Repository:
The relationships between these areas of the Architecture Repository are shown in Figure 37-1 .
The following sections describe the structure and content of the repository areas.
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:
The Reference Library provides a repository to hold reference materials that should be used to develop architectures. Reference materials held may be obtained from a variety of sources, including:
The Reference Library should contain:
In order to segregate different classes of architecture reference materials, the Reference Library can use the Architecture Continuum as a method for classification.
The Architecture Continuum, as shown in Figure 37-2 , can be viewed as a Reference Library classification scheme. As such it illustrates how reference architectures can be organized across a range - from Foundation Architectures, and Industry-Specific Architectures, to an Organization-Specific Architecture.
The enterprise needs and business requirements are addressed in decreasing abstraction from left to right. The architect will typically find more 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.
Through this exercise it is important to keep in mind the concepts of levels and partitions. At different levels of granularity there may exist reference materials appropriate to the level, and partitions within the Architecture Landscape can be expected to use different reference material (see 36. Architecture Partitioning and Part III, 19. Applying the ADM Across the Architecture Landscape).
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 Architecture Governance because:
Standards typically fall into three classes:
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 require processes to allow for exemptions and standards evolution.
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:
Projects wishing to adopt Provisional Standards may do so, but under specific pilot conditions, so that the viability of the standard can be examined in more detail.
Projects that are re-using existing components can generally continue to make use of Phasing-Out Standards. Deployment of new instances of the Phasing-Out Standard is generally discouraged.
In most cases, remedial action should be taken to remove the Retired Standard from the landscape. Change activity on a Retired 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.
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:
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:
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.
The Governance Log should contain the following items:
This would typically include:
This review will measure the compliance of the project to the defined architecture standards. For each project, this log should include:
These assessments should be periodically carried out and tracked to ensure that appropriate progress is being made. This log should include:
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.
The Architecture Requirements Repository is used by all phases of the Architecture Development Method (ADM) to record and manage all information relevant to the architecture requirements. The requirements address the many types of architecture requirements; i.e., strategic, segment, and capability requirements which are the major drivers for the Enterprise Architecture.
Requirements can be gathered at every stage of the architecture development lifecycle and need to be approved through the various phases and governance processes.
The Requirements Management phase is responsible for the management of the contents of the Architecture Requirements Repository and ensuring the integrity of all requirements and their availability for access by all phases.
The Architecture Requirements Repository holds architectural requirements of the required state of the enterprise at particular points in time. Due to the sheer volume and the diverse stakeholder needs throughout the Enterprise Architecture lifecycle, the Architecture Requirements are divided into three levels of granularity:
Strategic Architecture Requirements identify operational and change requirements for direction setting at an executive level.
Segment Architecture Requirements may identify requirements at the program or portfolio level to identify and align more detailed change activity.
Capability Architecture Requirements identify requirements for individual work packages and projects to be grouped within managed portfolios and programs.
The business outcomes for architecture requirements will be reflected in the Solutions Landscape over time. When this occurs, the architecture requirements are met and archived for audit purposes.
The Solutions Landscape holds the Solution Building Blocks (SBBs) which support the Architecture Building Blocks (ABBs) specified, developed, and deployed. The building blocks may be products or services which may be categorized according to the Enterprise Continuum categorization and/or the ABB specifications as Strategic, Segment, or Capability SBBs.
SBBs may also include tools, systems, services, and information which describe the actual solutions that may be selected and their operation. For example, vendor-specific reference models or vendor-specific levels 4 and 5 of the IT4IT Reference Architecture would be defined here.
However, the Solutions Landscape will not include the information and data content produced by the solutions selected; that is the responsibility of the solutions themselves.
While the Architecture Repository holds information concerning the Enterprise Architecture and associated specifications and artifacts, there are a considerable number of enterprise repositories that support the architecture both inside and outside of the enterprise.
These can include development repositories, specific operating environments, instructions, and configuration management repositories.
There are many industry reference models available which may assist in understanding the role of and developing the Reference Architectures.
These relate to industry, best practice, or formal defined standards used by leading organizations. Examples include ISO, IEEE, and Government standards.
Decisions made by the Architecture Board which affect the Enterprise Architecture are often recorded in the minutes of meetings.
These minutes are often held in documentation archives which are excluded from the Architecture Repository for legal or regulatory
return to top of page