Architectural Review

A friend of mine asked me to do an Architectural Review for him, and since I have had my eye on some home theater recliners I agreed to help.  This is something I've done several times in the past in an ad hoc fashion: in conversations with developers, stakeholders, infrastructure experts, and users, the areas that require more rigid review than other areas make themselves known quickly.  This client had the audacity to want to know ahead of time what is usualy contained in an Architectural Review, which forced me to sit down and think about things that I haven't been at for a while, such as different viewpoints as to what exactly is entailed in the idea of software architecture and what people are really after when they bring someone in to review the architecture and implementation of a software system.

The latter question is often overlooked but is of paramount importance.  What are they after, bringing in an outsider who does not know their business and their politics to critique what is often the collective work of an entire department and a fair amount of involvement from other departments as well.  I have a friend who despite being a world class software architect is regularly subjected to reviews by people who were not out of diapers when he began working with the high level structure of integrated systems.  What are they after?  In some cases (though this does not seem to be the norm) there are clear problems with a system's ability to scale or with the difficulty in making changes to a system and the architect is brougt in to show the way forward. I will propose some answers with a few articles I am working on, culminating with my humble offer for a blueprint of what is involved in an "Architectural Review."