Architecture Review Engagement
An independent assessment delivered as a written finding set with severity, evidence and a recommendation you can act on or reject.
| How it is bought | Fixed fee |
| Duration | 3 weeks |
| Written for | Infrastructure leaders facing a migration, a repatriation, a renewal or a cost problem |
Cloud decisions are made on modelled savings that rarely survive contact with the invoice, and on resilience nobody has tested by removing something.
What you receive
Named artifacts, not activities. If one of these is not delivered, the engagement is not complete.
- A workload-by-workload placement recommendation, with the reason per workload rather than a blanket direction
- A cost model based on your actual usage, including egress and the run cost most business cases omit
- A resilience position: what breaks when a zone, a region, the database or the front door is lost
- A licence exposure summary across the estate, because migration changes the counting rules
- A ranked remediation list with effort against impact
How it runs
- Week 1: inventory and current spend, read from the bill rather than from the architecture diagram.
- Week 2: placement analysis, resilience review, licence position.
- Week 3: the model, the ranked list and the readout.
What this deliberately does not include
Published with the same prominence as the deliverables. A scope with no stated exclusions is a scope that will be argued about later, and the argument always happens at the worst possible moment.
- Executing the migration. This produces the decision and the plan.
- A vendor negotiation, though the output is exactly what you want in front of you during one.
- Application refactoring design beyond what placement requires.
How you know it is finished
You can defend each placement decision to a CFO, and you know what breaks and what it costs to fix.
What you need ready
Twelve months of cloud billing data, an inventory if one exists, and access to whoever knows what the undocumented dependencies are.
Every engagement starts with a written scope confirmation before any invoice is raised. Nothing here is a click-to-buy: we confirm what you need, agree the scope in writing, then invoice. If the scoping conversation shows that a smaller engagement, or none at all, is the right answer, we say so before anything is signed.
Request this engagement Talk it through first Break an architecture in the Cloud Lab
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.
What else is coming for Cloud Assessment
The engagement Ready
What it produces and how it runs.