What is an Architectural Decision?

An Architectural Decision (AD) documents important decisions with architectural significance. By architectural significance we mean decisions having influence on the selection of hardware, software, the structure of components and integration of components. A "build vs. buy" decision is also architecturally significant. All decisions that have an architectural significance will be agreed and documented via the Task: Define an Architectural Decision, and managed by following the Architectural Decision governance process suggested here.

When to do an Architectural Decision?

When a decision affecting the fundamental structure of a system is taken an Architectural Decision should be created. It is important to be able to understand the difference between a design decision and an architectural decision. The design decisions don't have to be documented using the Architectural Decision process. The following table gives examples and compares architectural decisions and design decisions to help in understanding the difference between them.

When a decision affecting the fundamental structure of a system is taken an Architectural Decision should be created. It is important to be able to understand the difference between a design decision and an architectural decision. The design decisions don't have to be documented using the Architectural Decision process. The following table gives examples and compares architectural decisions and design decisions to help in understanding the difference between them.

Note: Exceptions or variants to defined and agreed (enterprise) architecture patterns or standards should also be documented in Architectural Decisions!

AD Process

Anyone in can initiate an Architectural Decision. Several review forums are required to be in place, and the AD once created (in the RFC state), is forwarded to the appropriate review and approval body (based upon the business domain in which the AD was created and also based upon the scope of the AD). For example, an ADs originated within a business line are sent to the defined architectural review body for the business line. THe process defined below is a suggestion; it needs to be adapted and integrated into existing enterprise IT management processes, as directed and supported by the CIO and other IT managers.

Figure 1 - Architectural Decision Process

The flow of the AD is as follows:

1. The AD is created in an appropriate tool using the provided Architectural Decision Template. The decision and supporting information is detailed within the AD document.
2. The AD is saved in a suitable document management repository (to make them searchable) and notifications are sent to all architects informing them of the new AD (a reference into the repository is provided). Its state is "RFC" at this point.
3. The responsible architect (i.e. in a business line or to the CIO review body, depending upon where the AD was originated and its scope) reviews the AD to determine its scope. The scope may be defined as being at the "project", "business line" or "enterprise" level. Project level ADs do not need to be sent to the business line architecture review body; however these decisions are recorded within the AD repository. If the scope is deemed to be at the "enterprise" level, then the AD is forwarded to the CIO level organization for review and approval.
4. There are at least two review bodies, the CIO-level body for enterprise level ADs, and one in each business line. The state of the AD is changed to indicate the domain reviewing the AD, namely "CIO", "Business line X", or "CORP". If no agreement on the AD is reached, or if the AD is deemed to concern an enterprise-wide issue, it is forwarded to the CIO group for action. Its state is changed to "CIO".
5. The CIO may approve the AD, reject the AD, or send it back to the domain review body (i.e. if it is decided by the CIO that it is not an enterprise level AD) along with some direction to assist in its review.
6. The business line or domain review body (e.g. "Corporate") may send it back to the originator for update (i.e. if there is insufficient information to make a decision, insufficient coverage of options and issues or for other reasons). After being revised, the AD is again sent to the domain review body.
7. The domain review body, or the CIO, may accept or reject the AD, with the state of the AD being set appropriately. All ADs are recorded in the AD repository, making them available for future reference or revision.
8. If an AD is deemed to have a large impact on the organization (i.e. Due to resource implications, skills implications, support implications etc.) it will be forwarded to a management review body (i.e. IT Directors or an IT Steering Committee) and its state set to "Escalate". This review may result in approval of the AD or it may be sent back to the originating review body for revision.

Decision Repository for AD Process

All ADs created and reviewed must use a central and searchable repository, to enable the storage, searching and management of the ADs.

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.

Managing Architectural Decisions

Advice regarding the creation, review and management of ADs:

• Make sure the right people are in the room. Choose representatives from the IT side and from the business that are empowered to make decisions.
• Track all decisions carefully:  who was present, discussion points and dates, final decision and dates, attach research and background material, the final record of decision (containing description of the problem, options analysis, recommendation, sign-off).
• Remind representatives of decisions taken at the previous meeting and obtain sign-off.
• As already noted, record decisions in a database that is indexed, can be searched easily by subject, keyword, date etc. This is needed down the road when newcomers to the subject matter or existing members of a project are trying to understand why certain decisions were made. On large projects there are so many decisions taken that it is easy to lose sight of the decisions taken.
• Discourage decision makers from changing their minds all the time.  The occasional change in opinion is typical but if decisions aren’t stable a project cannot move forward - many decisions build on other fundamental decisions.  The senior team members will want to reassess decision and, therefore, it is important to have the decision carefully recorded.