Large corporations, like ours, conduct architecture reviews of major technology initiatives to determine they're fit for the organization's operating practices. Exactly what comes out of a review should depend on when the review is preformed and the state of the project. By our analysis, there are seven kinds of reviews, each with a different purpose, outcome, and timing.
Reviews performed before the business has a specific project in mind are useful for setting strategic direction, possibly capitalizing on entrenched or emerging solutions. These projects have the benefit of having nearly perfect architectures and can demonstrate that EA is a proactive element of a total business strategy. Reviews performed in this scenario are known as Architecture Planning.
Once a business unit or team has a decent set of requirements, but before anyone has technical specifications, it is a good time for Architecture Alternatives to be discussed. These can be high level or fairly detailed, and have benefit of being the most useful of all reviews.
If an architecture team is asked to review a project where the business and technical designs are proposed, but final funding approval is still pending, then the review is actually an Architecture Approval. It's still early enough that changes can be made without affecting budgets, but expectations are usually already set.
Once project funding has been approved, the options for changing the architecture of a proposed solution gets narrower. It can (and should!) still be done, but after funding, reviews result in Architecture Recommendations (albeit strong ones if necessary), more so than architecture mandates. Whenever possible, try to get the reviews done before funding is approved.
Being asked to review the architecture of a solution after project execution (typically this means the coding has started) is a lot like being asked what you think of your manager's spouse. You better hope nothing bad comes out. Architects still and always have the responsibility to be honest, but the opportunities for suggesting change are more painful and expensive now. These reviews are really requests for Architecture Validation.
On a few occasions we've been asked to weigh in on a project just before the application was to be deployed. What can you say, these Pre-deployment Reviews are more about getting everybody aligned as to what is about to occur. If an architecture change is made now, the costs and timelines of the project are all but impossible to hit.
Generally, the later an architecture review takes place the worse it is for everybody. However, a Post-mortem Review is a good idea, and should be performed frequently to review lessons learned and prepare for the next Architecture Alternatives conversation.