Architecture Review
An independent assessment of a system or estate, delivered as a written finding set with severity, evidence and a recommendation you can act on or reject.
An architecture review is worth having when a decision is about to be expensive: a migration, a rebuild, a scaling problem, or an estate nobody fully understands any more.
It is worth nothing when it produces a diagram of what already exists and a list of best practices that could have been written without looking.
What we review#
| Area | The question |
|---|---|
| Structure | Does the shape match what the system is actually asked to do? |
| Coupling | What cannot be changed without changing something else, and was that intended? |
| Data | Where it lives, who owns it, what happens when two sources disagree |
| Failure modes | What breaks first under load, and what breaks silently |
| Cost | Where the money goes, and whether the architecture is the reason |
| Operability | Whether the people running it can see what it is doing |
| Exit | What it would take to move off each significant dependency |
The last row is the one most often missing and the most valuable in an estate with heavy vendor commitments, Oracle estates included.
What you receive#
A written finding set. Each finding carries:
- What we observed, with the evidence
- Why it matters, in consequence rather than in principle
- Severity, and what it blocks
- A recommendation, with what it would cost
- What we would do if you did nothing, which is a legitimate option and sometimes the right one
No slide deck unless you ask. A finding set can be argued with; a deck usually cannot.
How we work#
We read the code, the configuration and the incident history, and we talk to the people who operate it. Incident history is the most honest architecture documentation any organisation has, because it records what actually happened rather than what was intended.
We will tell you when the answer is that nothing needs to change. That happens, and a review that never reaches that conclusion is a review shaped by what the reviewer sells.
What we will not do#
- Recommend a rebuild because the current design is unfashionable. Rebuilds are the most expensive recommendation available and the least often justified.
- Produce findings we cannot evidence.
- Grade against a maturity model instead of against your actual constraints.
- Take the implementation work as a condition of the review. If we do it, that is a separate decision made afterwards.
How we work, in public#
Our own engineering charter and enterprise infrastructure material are published, including the architecture decision record template we use, whose most important row is what was rejected and why.
Get in touch with the decision you are about to make.