Decide on the focus of the 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 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. This type of review is done after completion of a perspective (all iterations) and prior to a stakeholder review.

The second type, a stakeholder review, is focused on the content to ensure it captures the business and that it meets the requirements as defined by stakeholders (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 primary objective for a peer review is to ensure the IT architecture is complete, consistent and fits in with the enterprise's environment. A stakeholder review is focused on the solutions, decisions defined, and the meeting of requirements. Also part of this step is to define the list of required participants in the review.

The architect or review manager will gather information about the IT architecture to be reviewed, as indicated in the mandatory and options inputs to this task. For example, for reviewing a technology level architecture, the following information will be of use:

• The Technical Perspective documentation for the IT architecture to be reviewed;
• Project and business plans and objectives;
• Existing network logical and physical design;
• Existing databases and database design;
• Existing server environment (configuration, software versions, planned upgrades);
• Existing standards (network, naming, protocols, and so on).

These documents should be collated and made available to those participating in the review.

Each attendee is given sufficient notice about the review, and what is expected of them in terms of both preparatory work and their involvement in the review process. Make it clear to each attendee what stakeholder they are representing and therefore the type of review critique and feedback expected from them. As general guidance, you should consider the following stakeholders when inviting attendees to participate in the review meetings:

• Direct users of the 'system', and also testing and documentation staff;
• Domain or subject-matter experts for the system; 
• Peers: other IT architects or IT experts with experience in the domain or technology;
• Managers: of the system or technology involved.

Include only those participants who will contribute to achieving the objectives of the review. In general, it is usually more productive to hold several focused review sessions with a smaller number of participants, than to hold one review involving many.