Advisory review

Architecture review: having your technical design assessed

A technical design is on the table. A supplier or your own developer explains how it will be built, and it sounds well considered. What you cannot judge is whether it suits an organisation of your size, what it will mean in three years, and whether you could still change course by then. Holding your own in that discussion is out of reach, and signing it off is a big step.

An architecture review is not an inspection and not a grade. It is an assessment of the design decisions against your real constraints: the budget, the people who will have to run it, the data that is coming, and how far you are willing to commit. Not against whatever the trade press is enthusiastic about this year. A design that is technically elegant but does not fit your organisation is not, for you, a good design.

When to have a technical design assessed

A review is worth most while the decision is still reversible.

A proposal arrives with an architecture diagram and a technical annex, and you want to know what you are agreeing to.
Your developer or team puts forward an approach you cannot argue against on the substance.
Two camps inside your organisation disagree and the discussion has stalled on technical points.
The design looks heavier than your size justifies, or too light for what you intend to do with it.
You want to know up front how tied you become to this supplier, and what getting loose later would cost.
The build is half done, an earlier decision is biting, and you want to know whether carrying on is defensible.

What I look at

Not whether the design is modern. Whether it holds up for you.

The question underneath the design: which business problem does this solve. A design that answers the wrong question well is exposed here.
Dependency: what commits you to a single supplier or platform, and what it would cost to step out later.
Scale: what happens at ten times the data or users. Where the first ceiling sits, and whether anyone can point to it.
Failure behaviour: what happens when an interface drops. Does anyone notice, or does it quietly stop without a signal.
Supportability: who maintains this in two years, with what knowledge, and whether that knowledge exists beyond this one person.
Wrong versus unfamiliar: a decision that collides with your constraints is not the same as one you simply have not seen before.
Whole-life cost: licences, consumption and support hours. The build cost is only part of the picture.

What you get

A note and a conversation. The note is written so that a director without a technical background can take a decision on it: per finding, what it is, why it affects you, and what it costs to change now rather than later.

A concise note of a few pages in plain language, with no jargon you have to look up.
The findings in three groups: what genuinely has to change, what may stand as a deliberate choice provided you know its price, and what is simply fine.
For each point, the question you can put to the supplier yourself, plus what a good answer amounts to.
An hour-long debrief, with you alone or with the designer present.
On request, a version written for the designer to read. I write it to stand up to that.

What it is not

Not an audit and not a certification. You get a reasoned judgement, not a statement of conformity against a standard.
Not a redesign. I assess what is in front of me; working out an alternative is a separate engagement.
Not a security assessment or penetration test. Security comes up where it follows from the design decisions.
Not a judgement on people. It concerns decisions and their consequences, not who made them.
Not the run-up to a build engagement with me. If the review points towards work I could do myself, I say so, and if you ask I will name other parties too.

Common questions

What does an architecture review cost, and how long does it take?

Scale decides it: how much material there is, and whether I look only at the design or also at what has been built. One bounded design fits a short engagement of a few days. For something larger I work on a time-and-materials basis with an agreed ceiling, or at a fixed price when the question is sharp enough. I name a rate in the first conversation.

What do you need from me?

The design or architecture diagram, the annex or quotation that goes with it, and half an hour of whoever produced it. If something has already been built, access to the code or a demo environment helps. I do not ask for access to production systems. If the design exists nowhere on paper and lives in two people's heads, that is a finding in itself.

And if the design is simply sound?

Then that is what it says, with the reasoning attached. That is a full outcome: you sign with more confidence and you know which points will need watching later. A review that has to find something in order to justify itself is worth nothing.

When is a design decision wrong, and when is it merely unfamiliar?

Wrong means it collides with a constraint you cannot give up: it does not fit the budget, it cannot be run by the people you have, or it ties you to a party in a way you do not want. Unfamiliar means it departs from what you are used to but is otherwise sound. The second is no objection at all, as long as someone can explain why it was done that way and what it buys you. That is why I keep the two apart.

My supplier will not like this.

That depends on how it is written. I write about decisions and consequences, and state the assumption my judgement rests on, so the designer can point out where that assumption is wrong. A good designer answers a question about dependency, scale or failure behaviour without difficulty. If the answer does not come, you would rather know now than after go-live.

I have no technical background. Is this any use to me?

That is the point of it. A finding you cannot retell to your management team is useless to you, however technically correct it may be. Every finding is translated into what it means for money, time, risk or dependency, and into the decision that goes with it. The technical detail itself sits in an annex.

More within this service

A design on the table you have to say yes or no to?

An introductory conversation is without obligation. Sketch what is in front of you; I will say honestly whether a review helps you, or whether one conversation is already enough.

Book an intro call Send a message