From a high-level, there is not much that distinguishes an architecture analysis from any other IT architecture assessments or reviews.

An architectural assessment is a peer review, and an architectural review includes both a peer review and a stakeholder review:

• 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 captures the business (i.e. experts and other stakeholder review).

The first type of review is focused on ensuring the models are clear, and complete—participant are technical and typically peers of the IT architect that created the IT architecture under review. The second type of review 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. These are base reviews focused more on ensuring conformance with requirements and constraints.

Now the complete IT architectural perspective is analyzed to:

• Refine and optimize the models;
• Refine and optimize the business and its processes;
• Agree and refine the proposed logical or technical solutions (perspectives);
• Identify and document the implications of these solutions;
• Identify opportunities presented by proposed new approaches or technologies;  
• Aid in defining or refining short and long term strategies (both business and technical). 

General

The following general approach is used to do the architectural analysis:

• Processes - examine the defined processes to see if optimizations are possible. Also consider the structure and approach from a technical perspective;
• Locations - review the defined locations to see if optimizations or augmentations (from a business and technical perspective) are possible;
• Actors / Roles - it is important to analyze the Actors and Roles involved to ensure that their experience with the system is optimized and effective.

Previous steps produced a representation of the architecture (i.e. the Business or Logical Perspectives), therefore question and reason based on the analyses done on these representations as well.

Identifying Issues

Uncovering potential optimization (or 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 analyses.

Capture potential issues as they appear, describing them in a neutral tone and ensure these descriptions are agreed by all. Add them to 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 optimizations or solutions to issues at the review meetings. If so record these results in the Artifact: Architecture Review Record as well.

After the review, allocate responsibility for each issue 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.