This task defines how to conduct the review of an IT architecture defined at a specific level and with a defined context and scope. There are two types of review: Peer and Stakeholder.
An architectural review has one of two objectives. The two types of review are:
Peer Review - ensuring that the IT architecture is complete and consistent (usually done
first, prior to a stakeholder review);
Stakeholder Review - the IT architecture is reviewed to ensure it accurately models the system
(i.e. experts and other stakeholder review).
The first type of review is focused on ensuring the models are clear, and complete. The participants are technical and
typically peers of the IT architect that created the IT architecture under review. See: Task: Assess the Architecture.
The second type of review, defined here, is focused on the content to ensure it captures the business and that it
meets the requirements as defined by stakeholder (both business and technical), therefore there are various experts
involved (i.e. business, but more technical experts at the Logical and Technical levels) along with the other
stakeholders for the IT architecture.
The newly created architecture is reviewed from these and other perspectives:
To uncover any unknown or perceived risks in the architecture;
To detect any architectural design flaws;
To detect a potential mismatch between the requirements and the architecture: over-design, unrealistic
requirements, or missing requirements. In particular aspects in the areas of operation, administration and
maintenance are often neglected;
To evaluate one or more specific architectural qualities: performance, reliability, flexibility, security, safety;
To identify reuse opportunities.
Once this stakeholder review is completed, the perspective is completed and the next level may be defined if desired.
The completed perspective is also now ready for inclusion in the normal enterprise IT management processes that
use the architecture deliverables, which is generically outlined in: Delivery Process: UAM in the Enterprise.
Steps
General Recomendations
Seen from 20,000 feet there is not much that distinguishes an IT architecture review from any other assessment or
review. However, one important characteristic of IT architecture is the lack of specific measurements for many
architectural quality attributes—only a few architectural qualities can be objectively measured. Performance is an
example where measurement is possible. Other qualities are more qualitative or subjective: conceptual integrity for
example. Moreover, it is often hard to decide what a metric means in absence of other data or reference for comparison.
If a reference architecture is available and understood by the target audience, it is often convenient to express some
of the results of the review relative to this reference system. This may happen in a context where the system
under design can be compared to an earlier design.
When in the life-cycle this review takes place also affects its purpose or usefulness. Architectural reviews are
normally done at the completion of an architectural development iteration, such as when a first iteration of the
business level view of the architecture has been completed. Catching problems early has many benefits, and therefore
performing an assessment after each iteration is beneficial. These review points are defined with the UAM processes.
Leadership, maturity, pragmatism, and result-orientation are important to to a good IT architecture review—a reviewer
may uncover architectural defects that are likely to be unpopular if they threaten the schedule of a project. Still,
it's better to raise critical issues early, when they can be resolved, rather than blindly following a schedule that
leads the project team down the wrong path. The architecture reviewer needs to balance risks against costs, remaining
sensitive to the broader issues of enterprise or business domain success. The architecture reviewer also needs to be a
persuasive communicator who can raise and discuss sensitive issues.
Peer Reviews
Peer Reviews involve higher (or peer) level authorities, for example a domain architecture would be reviewed by the
enterprise's Enterprise Architect. Enterprise level architectures would be reviewed by a set of
Business Line or Domain Architect. IT architectures are also reviewed by strict
peers: Project IT Architects or Business Domain architects reviewing each other's work for example.
A peer review focuses on the following aspects of the IT architecture:
Match between the scope, context, and IT architecture Project Plan, with the resulting IT architecture;
Overall structure of the defined architecture;
Completeness of the architecture and individual models;
Conformance of the architecture with enterprise standards (ADs etc.), objectives, plans and strategies.
The objective is to ensure the IT architecture definition meets enterprise standards in terms of quality,
structure and completeness, independent of the details defined within the architecture.
Stakeholder Review
Stakeholder reviews delve deep into the content of the IT architecture with all stakeholders participating, namely
technical stakeholder (IT experts and technical managers) and business stakeholders (i.e. business experts and business
managers). This is the traditional view of an architecture (or design) review, where stakeholders provide feedback on
the models.
Therefore a stakeholder review focuses on the following aspects of the IT architecture:
Accuracy, in terms of capturing the business processes, technical solutions, and other elements;
Structure and relationships within the architecture in both business terms and technical terms;
Practicalities in terms of operational considerations, skills, etc. (i.e., business level practicalities);
Practicalities in terms of implementability, migration, technologies, etc. (i.e., technical practicalities);
Other considerations such as IT security.
Review Meetings
General
The following general approach is used to do the review:
Entities and Locations - review the architectural representation of the system and question its
structure, components and definitions. It may also be compared to similar and existing structures and
architectures. Peers also bring their knowledge and experience to the review, which is often invaluable. Step
through two of the four aspects to start: Entity Models and Location Models;
Scenarios - walk through busy scenarios (Process Models and Roles Models) to ensure that the
architecture addresses the business needs, and to also identify possible non-functional problem areas.
Previous steps produced a representation of the architecture (i.e. the Business or Logical Perspectives), therefore
question and reason based on this representation
Entities and Locations
Starting with these aspects will ease participants into the architecture definition. A basic understanding of these
elements helps in bringing all participants onto the same level in terms of definitions, and also in terms of the scope
of the IT architecture. Relatively simple models and definitions are reviewed, to ensure accuracy and
conformance.
Scenarios
This is the systematic review of process scenarios described by the architecture (at any of the three levels: Business,
Logical or Technical). The models must support all required business activity. Non-functional aspects (e.g. the loading
on a server) may arise and be discussed. These should be noted and explored with peers and stakeholders, and solutions
agreed, or the issued noted for further action.
The advantage of such an approach is that it puts the task in a very concrete perspective, understandable by all
parties. It also allows for probing into omissions or flaws into the requirements, especially when the
requirements are informal or unwritten or very general and terse. In other words, important scenarios are used to
test the defined architecture, keeping in mind all the important aspects to be reviewed (i.e. completeness,
consistency, etc.). Also part of this review are the how Entities are involved and how Actors and Roles
participate in the processes.
Identifying Issues
Uncovering potential issues is mostly done by human judgment based upon knowledge and experience. This knowledge and
experience includes such things as:
Common failure patterns repeated from project to project;
Heuristics used to uncover problem areas;
Business or technical knowledge;
Check-lists can be useful;
Results from previous reviews.
Capture potential issues as they appear, describing them in a neutral tone. Ensure these descriptions are agreed by all
and recorded in the Review Record, and if needed prioritize them. After the meetings, refine the definitions of
their scope and impact. If there are many, tackle them in priority order.
It may be possible to identify possible solutions to issues at the review meetings. If so record these results in the
Artifact: Architecture Review Record as well.
Assign Responsibilities
After the review, allocate responsibility for each issues identified in the Review Record. "Responsibility" in this
case may not be to fix the issue, but to coordinate additional investigation of alternatives, or to coordinate the
resolution of the issue if it is far-reaching or broad in scope.
