I did some architecture reviews in the past. Most of them internal but also for my company's clients. At the end of the day this always has been and probably always will be a thankless job. For many reasons. This post was thought of as an incomplete list of things to keep in mind while doing this kind of reviews and should give you some advice.
If you have your own experiences on this, I would love to read about them in the comments.
You the reviewer?
The bottom line for all kinds of reviews is, that you take a deep look the thoughts of other people and rate the implementation based on them (documentation or code). It is normal, that you are external to the project team. You probably do not even know them before and they don't know you. This is the main reason, you should make your approach and overall goals transparent to them before looking into the details. Point out, that you are not there to blaim anybody (you are not!). If you are working on internal projects you could also point out, that your work helps the team members getting better for the next projects. The sensitivities raise with the project size and your distance from the project team. Work professional; have your opinions in place; rest in yourself. And most important: never work alone! You always do any kind of review with a peer.
Why doing the review?
There are a couple of reasons, you should do reviews on projects. The simplest case could be some kind of pre production check. For this you have to proof, that the software complies to the company's specifications. Mostly you also have to pass some kind of gateways in the used software development process where reviews are mandatory. You could try learning from failure and review failed projects. Or do checks on behalf of your customer.
In general you always have to check some implementation or documentation for compliance against standards or best practices. In general it is best to always follow these steps in your review process. It's called DRIVE and it is an approach to problem solving and analysis. I also like to use it for rewiews.
Define: the scope of the problem(s), the criteria to check.
Review: the current situation, understand the background, identify and collect information.
Identify: analyze the review results.
Verify: rate the review results. Together with a peer.
Execute: improvements or solutions from the results. Draw conclusions.
Compliance review
Checking for compliance is "easy". This is done against any kind of software development process or any other standard. If you are using for example OpenUP or TOGAF, you have checklists at hand (see ressources). They should guide you through all relevant parts. In other cases, you even have predefined gateway checklists you could work on. Anyway: Before starting, remember that it should always be an option to adjust them to you needs. You have a defined project order and you should focus on that. The bigger the checklist(s) grow, the more you have to evaluate.
Metrics review
In some cases you could also think about using tools for your reviews. We are not talking about source code reviews here, so this is not obvious at the first sight. But there are tools out there, helping you to judge on the implementation of a special architectural approach. Think of JDepend or the Dependometer. Both perform static analysis of physical dependencies within a software system. Any kind of metric analysis should be already setup with the project. So you probably only have to check the generated metrics.
Interviews
If you are doing interviews with the team, you should try to keep the sessions as short as possible. Whatever system/project you are looking at, try to find one interview partner per "tier" or "layer". Which view/methodology or concept you use here is unimportant. This approach helps you to schedule the interviews and assists you in a basic coverage of all relevant parts.
You should try to keep discussion to a minimum. Go with the checklists and work through your questions. Even if you are willing to share your knowledge. Try not to do this during the interview. There is room for it later on in your report.
Don't forget to do a transcipt of the conversation.
Result communication
This highly depends on the requirements. Could be any kind of presentation and/or document. Most important: stick to the truth. Refer to the place of discovery of the problems. Don't communicate a problem without a solution. If you discover one, also briefly think about the solution.
Online resources:
TOGAF -- The Open Group Architecture Framework
OpenUP
Google for Architecture+Review+Checklist
Short abstract about DRIVE (PDF)
