• Architecture Support
• Enterprise Architect

• Manage Analysis Follow-up

• Analyze Business Models
• Review Objectives (Business)
• Review Objectives (Logical)
• Review Objectives (Technical)

• None

• Analyze Business Models
• Analyze Logical Models
• Analyze Technical Models
• Manage Analysis Follow-up
• Review Objectives (Business)
• Review Objectives (Logical)
• Review Objectives (Technical)

An Architectural Review Record is a work product specialized for capturing the results of architectural review activities. This involves the review of IT architecture models, and also the review of proposed solutions or other types of artifact reviews.

It is very important to do architectural reviews (of all types) and to capture the results of these reviews. Often errors and omissions are discovered, and these need to be captured in a way that permits them to be properly described and action assigned to address them. This review typically is also the predecessor to further work: the continuation of work on the architecture, or the continuation of work on maintaining or updating the IT architecture.

The Review Record document is composed of six parts, plus a glossary. The outline of the document is:  

1. Executive Summary

An executive summary of the review — required if the review is large or significant.

2. Goals and Objectives

List the artifacts that will be the subject of the review and the coverage (all, business level, network aspect, technology, etc.), and describe the objectives of the review.

3. Scope & Level

Identify the high-level context of the review and the review level (see: Guideline: Review Options for Artifacts).

4. Review Participants

List the individuals who participated in the review and their roles during the meeting; for example, moderator, note-taker, reviewer, author.

5. Architecture 

Identify the IT architecture in more detail, ensuring that the context and scope of the review is clear; or that the problem or issue or opportunity discussed is clear.

6. Summary of Results

Define the over-all conclusions under various categories such as application, information, structure, security, integration and interfaces, technology, etc.

List these key findings identified during the review. Reviewers may identify:

• Strengths - describe the positive findings of the assessment, rank them from most significant to least;
• Issues - describe issue identified;
• Recommendations -  The review team may make recommendations on problem resolution;
• Action Plan - define actions coming out of the review;
• Issues for Escalation - Certain problems or anomalies may be discovered for which a course of action cannot be agreed on by the review team, and which needs to be escalated for resolution;
• Follow-up -Describes the review team's recommendations for follow-up (for example, whether another review is necessary) and what, if any, additional information or data is needed.

7. Architectural Glossary

The Glossary defines important terms used in the architecture or project (likely defined in a separate document for practical reasons).

• Architecture Review Record Template

While all architecture projects should use this work product, the level of formality will differ from project to project based on factors such as how formal the relationship is between customer and developer, the level of the IT architecture (i.e. EA, Business Lines, etc.), or how formal the developer's own organization is with regard to process compliance. 

This work product is primarily used to capture the results of a review, but it can also be used as a control document to manage the execution of the review. When used for this purpose it is issued to the participants in the review prior to the review meeting to initiate the review activity and guide the discussion.

• Review Record

• Manage Follow-up