Work Product Descriptor (Artifact): Architectural Decision Repository
The Architectural Decisions Repository stores all versions of enterprise, business domain and other levels of Architectural Decisions. It also stores all the derived data and metadata associated with the files and directories. It is not really a Work Product, in the UMA sense, but a part of the infrastructure supporting UAM.
Purpose

The Decisions Repository stores all architectural decisions (AD) of the enterprise, regardless as to whether they are enterprise level decisions, business domain level decisions or lower level decisions. The repository is an enterprise level resource that is used by all architects, designers, implementers and project managers in the enterprise.

Depending on the size of the organization there could be multiple repositories geographically distributed, however it is used and viewed as a single logical repository. The number of documents in the repository should be relatively low, but they need to be organized and searchable by users.

It is recommended that this repository also be used to store and make available "design decisions" that are made within implementation projects. Similarly, if there are any "business level" decisions (that are not Architectural Decisions) then they should also be stored and tracked.

Relationships
Input ToMandatory: Optional:
  • None
External:
  • None
Main Description

Organization of Decisions

The enterprise that owns the Architectural Decisions will need to decide how they are to be classified and organized for easy search and retrieval by architects, designers and implementation people. Although the creation and storage of Architecture Decisions is currently outside the scope of UAM, one suggestion is that they be organized in a widely available searchable repository on the corporate Intranet. It could also be implemented as a segmented area within the corporate document management facility. This will facilitate their distribution and use by all architects, project managers and implementers within the organization. The repository will promote easy compliance to enterprise and business domain standards, with all the benefits that follow. Having a well defined template and process that is supported through tools will allow for the easy creation, management and use of ADs.

Contents

ADs contain a lot of background and substantiating information. This is very useful if the decision needs to be re-visited in the future, however, most users of this information (i.e., architects, project managers, and implementers) are only interested in the decision itself. Therefore when a set of applicable (to an IT architecture project) ADs is found, a summary report should be provided to the user of the repository that defines each decision, leaving out all of the extraneous supporting information. The specific AD can be examined in total if more information is required.

Integration with architecture development tools and system development and implementation tools would be an asset.

Properties
Optional
Planned
Illustrations
Templates
Tailoring
Representation Options

The AD repository is not a critical part of the enterprise infrastructure and as such can be on any server, however it is an important resource. The data volumes are low as well as the numbers of queries expected. However, the repository must be available to all architects, project managers, analysts and implementers across the enterprise.

The repository, in addition to tracking the ADs as they proceed through the process, provides the ability to get summary reports (e.g. The number of ADs awaiting CIO review, or a summary description report of the all "Approved" ADs, etc.) and to search for ADs. All ADs created are retained in one repository regardless of their point of origin or state. ADs are only deleted when they have been replaced through the creation of new ADs, or the AD is no longer valid because the system or function to which it applies has been retired.

An AD MS Word template (Template: Architectural Decision Template) is used to capture the required information quickly and easily. The template, along with "attributes" for each AD, permits the searching for and reporting on ADs and on metrics for the process.

ADs within the repository will be identified as an "AD" type. The following attributes for ADs are suggested to aid in their tracking:

Priority - The priority of the AD: "High", "Medium" or Low"

Domain - The business domain that originated the AD (i.e. CIO, CORP, or 'Business Domain x')

State - The state of the AD within the process (i.e. RFC, 'Business Domain x', CIO, Review, Escalate, Approved or Rejected)

Type - The type of AD, that is, the architectural area or speciality that the AD is concerned with (This will aid in identifying the kinds of specialists involved with the review of the AD), namely:

  • Software,
  • Hardware,
  • Business Architecture,
  • Application Architecture,
  • Integration Architecture,
  • Storage Architecture,
  • Information Architecture,
  • Security Architecture, and
  • Infrastructure Architecture

Note: The AD repository should maintain author, revision and date information automatically.

More Information
Guidelines
© David W. Enstrom, 2025. All rights reserved.