Architecture Review
Will this survive an audit, an enterprise customer, and the next order of magnitude? Read from the running system, not the diagram.
Architecture documents describe what somebody intended. The review that is worth buying reads the deployed infrastructure, the code and the configuration, and treats every document as a claim to be checked. The gap between the two is almost always where the findings are, and it is never deliberate: it is what happens when a system ships for three years and the diagram does not.
In a regulated company that gap has a second cost, because the claims in your architecture document have usually been repeated in a submission, a questionnaire or a customer contract.
What this covers
The system as deployed
Infrastructure, services, data stores, integration points, and the configuration actually in force. Including the things that accumulated: legacy endpoints, debug interfaces and diagnostic services that nobody remembers adding.
Where it breaks under growth
Which component fails first at ten times the load, which one is expensive rather than impossible to change, and which apparently alarming part is genuinely fine.
Authorization and tenant separation
How the check runs, where it runs, and what happens when it is absent. If more than one customer is in a shared store, how one is prevented from reaching another.
Claims against reality
Every security and compliance assertion in your documents, checked against the implementation. An inaccurate claim is worse than a missing one, because it misrepresents the product to whoever is relying on it.
The change you want to make next
Most reviews are commissioned because something specific is coming. The review is worth more when it is pointed at that thing rather than at architecture in the abstract.
Sequencing
Findings ordered by what unblocks the most downstream work, not by severity theater. The most useful output is usually a short list of things to do first.
A rewrite is the most expensive available answer and it is usually the wrong one. If I recommend one it will be because a specific constraint makes incremental change genuinely impossible, and I will show you the constraint.
What usually brings people here
An audit, a submission or an enterprise security review is coming and nobody has read the architecture against the system recently.
The team says the next feature is hard and cannot fully explain why.
You are about to commit to a significant build and want it pressure-tested first.
A rewrite is being proposed and you would like a second opinion on whether it is necessary.
How the engagement runs
Fixed-price with a defined scope and an end date. The output is a written assessment with sequenced findings, an explicit read on whether the architecture supports the compliance claims you are making, and a plan your own team can execute.
If what the review finds is that nobody owns the architecture on an ongoing basis, that is a fractional CTO conversation rather than a second project.
This sits inside the fractional CTO side of the practice. If what you need is ongoing ownership rather than a defined piece of work, start there instead.
Questions I get asked first
What do you actually look at?
The running system. The deployed infrastructure, the code, the data model, the integration points, the identity and authorization design, and the cloud configuration. Architecture documents are read as claims to be checked rather than as descriptions to be trusted, because the gap between the two is usually the finding.
How is this different from a penetration test?
A penetration test asks whether an attacker can get in today. An architecture review asks whether the shape of the system will hold up to growth, to an auditor reading it, and to the next three things you want to build. Different questions, and a clean test result is entirely compatible with an architecture that will not survive the year.
Is this a prelude to a rewrite recommendation?
Almost never. A rewrite is the most expensive answer and it is usually the wrong one. The useful output is which parts have to change, in what order, and which parts are fine despite looking alarming.
What do we get?
A written assessment with findings sequenced by what unblocks the most downstream work, an explicit read on whether the architecture supports the compliance claims you are making, and a plan you can hand to your own team.
Written on this
Start with a conversation
Tell me what’s going on. If this is the right piece of work I will scope it. If it is not, I will say what is.
Bring your architecture problem, stalled project, cloud bill, or diligence deadline.
Not ready for a call? Send a message instead.
For companies looking to engage BATO. Vendors, please email.