- Reviews should answer specific decisions, not produce a generic maturity score.
- Every risk needs evidence, an owner and a next action.
- A roadmap without sequencing constraints is a wish list.
Frame the decisions
Before interviewing teams, we define the decisions the review must support: whether to replatform, how to split a monolith, where to place AI inference, whether a vendor can meet security requirements, or how to reduce cloud cost without harming reliability. A review without decisions becomes a tour of diagrams.
We gather evidence from code, infrastructure, incident history, contracts and the people who operate the system. Claims about scale, recovery and security are tested where possible. The output separates verified facts from assumptions.
- Decision register with owners
- Evidence from code, infrastructure and operations
- Constraint and assumption log
- Explicit scope and non-goals
Assess risk in business terms
A single points-of-failure list is not prioritisation. We map technical risk to business impact: revenue exposure, regulatory obligation, recovery time, customer trust and delivery capacity. Likelihood and detectability are considered alongside severity.
Findings are written so an executive and an engineer can both act. Each has observed evidence, the failure scenario, the affected capability, a recommended response and the cost of deferral. Architectural preferences are labelled as preferences, not facts.
- Impact, likelihood and detectability
- Observed evidence for each finding
- Owner and recommended response
- Cost of deferral and dependencies
Sequence the roadmap
The roadmap is ordered by risk reduction and dependency, not by what is easiest to demo. Quick safety work may come first, followed by foundational identity or network changes, then migration slices. Each phase has an exit criterion and a measurable signal.
We also define what not to do. A credible review will say that a proposed rewrite is unnecessary, a vendor does not fit the constraint, or a team should fix operations before adopting a new platform. That is the value of independent analysis.
- Risk-and-dependency sequencing
- Phase exit criteria and success signals
- Decisions that are explicitly deferred
- Recommendations the team can execute
Questions we hear in the room
How long does a review take?
It depends on scope and access. A focused review can be completed in days; a multi-team programme needs a phased assessment with defined checkpoints.
Do you sign NDAs?
Yes. We work under NDA and restrict access to the minimum evidence needed for the review.
