An architecture review is the most common way to start with a consultancy, and the easiest engagement to do badly. Done well it saves months. Done badly it produces a document that confirms what you suspected, priced as though it told you something.
Here is what to expect if you are buying one.
It should tell you what to do first
The most common failure is a review that lists forty findings without ranking them. Everything is a risk, nothing is prioritised, and the reader is left doing the hard part themselves.
A useful review is opinionated. It says which three things matter, in what order, and why the others can wait. That ordering is the expertise you are paying for. Anyone can produce a list of everything that differs from best practice; a scanner does it for free.
It should be costed in effort, not adjectives
Findings marked high, medium and low tell you about severity but nothing about tractability. You need both, because a high-severity finding that takes six months competes for attention with a medium one that takes a week.
A recommendation without an effort estimate is a wish.
Estimates will be rough and that is fine. A range is enough to decide the order of work, which is the decision you are actually trying to make.
It should be actionable without the author
A review that only makes sense with the consultant present is a sales document. You should be able to hand it to your own engineers and have them start.
That means naming specific systems rather than describing categories, referencing your actual configuration, and explaining why a recommendation applies to you and not merely in general. If the findings would read identically for any company in your sector, they were not derived from looking at your estate.
It should say what is fine
Reviews that find only problems are not credible, and they waste your attention. Something in your estate is working and should be left alone, and knowing which parts those are is genuinely useful.
It also tells you something about the reviewer. Someone who can only produce criticism either did not look carefully or has an incentive to find work.
How long it should take
For most mid-sized estates, one to two weeks. Under a week is usually a tooling report with commentary. Beyond three weeks and the cost starts approaching the cost of just doing some of the work, which is often the better purchase.
Access is the main variable. A review where the consultant can read your infrastructure code and your monitoring goes faster and finds more than one conducted entirely through interviews.
Warning signs in the proposal
- No named deliverable, or a deliverable described only as a report.
- The scope covers everything. Everything means nothing was prioritised before starting.
- The output feeds directly into a proposal for a large delivery phase, with no version where you act on it yourself.
- No mention of talking to your engineers. The people running the system know where the problems are, and a review that skips them is reading configuration in a vacuum.
What you should have at the end
A ranked list of what to fix, with effort estimates, in language your team can act on, plus a clear statement of what is fine as it is. If you can start work on Monday without another meeting, it was a good review.
