Task: Assess the Architecture
UAM Home Page
This task defines how to assess the newly developed IT architecture, a peer review, and how to address review findings.
Purpose

An architectural assessment has one basic purpose:

  • Peer Review - to review the architecture for completeness, consistency and correctness, and decide if more work is required.

This is the first level of review done on a newly defined architecture. The objective is to decide on whether more iterations and modeling is required, or if the IT architecture is complete enough to move to the next step: a stakeholder review.

The other type of review, defined in Task: Review an Architecture, includes some peer review aspects, but focuses on a stakeholder review, which is the final review and approval step for an architecture.

Relationships
Main Description

The architectural assessment done in this context involves ensuring that the architecture addresses the business need and fits in with the enterprise direction in the long-term. Scenarios may be used to test the architecture. If there is a problem in the direction taken by the architecture in terms of the enterprise long-term objectives or strategies then management will need to be made aware of and bless this deviation in direction.

The IT architecture is assessed from these and other perspectives:

  • To check it for completeness;
  • To check it for consistency in everything from naming conventions to concepts and structure;
  • To detect any architectural design flaws. Architectural flaws are known to be the hardest to fix, the most damaging in the long run;
  • To detect a potential mismatch between the requirements and the architecture: over-design, unrealistic requirements, or missing requirements. In particular the assessment may examine some aspects often neglected in the areas of operation, administration and maintenance;
  • To evaluate one or more specific architectural qualities: performance, reliability, modifiability, security, safety;
  • To identify reuse opportunities;
  • Ensure conformance with enterprise and business domain standards.
Steps
General Recomendations

An architectural assessment is a peer review. 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.

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.

Properties
More Information