An independent read on a system before you commit to it
How this is usually engaged
Usually two to four weeks for a single system, with a working session at the midpoint so nothing in the final report is a surprise. We are frequently engaged jointly by a client and their existing supplier; that works well when both parties agree upfront that the findings go to everyone.
A structured assessment of an existing or proposed system — its structure, data model, failure modes and operational cost — written as findings you can act on rather than a score out of ten.
Architecture problems announce themselves late and expensively. A design decision made in week three becomes the reason a release takes a fortnight in year two. Teams close to a system stop being able to see it, and teams that inherited one cannot tell which parts are deliberate and which are accidents that hardened. Meanwhile a supplier proposal arrives with a diagram that looks credible and nobody internally is well placed to challenge it.
Where responsibilities sit, which components know too much about each other, and which changes will always require touching five places. Illustrated with the actual change history, not just the diagram.
Whether the schema can represent what the business actually does, where constraints are enforced, and where the database is permitting states the application assumes are impossible.
What happens when a dependency is slow rather than down, what retries do under load, where a single failure becomes total, and whether recovery has ever been rehearsed.
Where the system stops behaving linearly, and what the infrastructure bill does at two, five and ten times current volume. Growth is often a cost problem before it is a performance problem.
Deployment, rollback, monitoring, alerting and on-call load. A system nobody can safely deploy on a Friday afternoon has an architecture problem, whatever the diagram says.
Independent assessment of a supplier's proposed architecture before you sign — including the questions worth asking about lock-in, exit and the parts of the estimate that look optimistic.
Features that used to take days take weeks, and each release breaks something unrelated. The cause is usually structural rather than a matter of effort.
The original team has gone and you need an honest read on what you have taken on before committing to a roadmap against it.
A significant build has been proposed and you want someone technical, without a stake in the outcome, to challenge the design and the estimate.
We read the code and the infrastructure definitions, not only the diagrams, and we talk to the people who operate the system at three in the morning. The assessment covers structure and coupling, the data model and its integrity constraints, failure behaviour, deployment and rollback, observability, access control, and the running cost. Findings are separated into what is genuinely dangerous, what is expensive, and what is merely not how we would have done it — the last category is called out as such, because taste is not a defect.
The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.
Which system, which boundaries, which questions the review must answer, and what access we will need. Agreed in writing before we start.
The repository, the infrastructure definitions, the deployment pipeline and the change history. The change history is often the most honest document available.
Engineers, operators and whoever answers the phone when it breaks. People who carry a pager give the most accurate account of a system.
Preliminary findings put to your team so factual errors are corrected and context we lack is supplied before anything is written up.
Final findings, severity agreed, and a remediation sequence discussed with the people who will carry it out.
Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.
These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.
Review access is scoped and time-limited, ideally read-only against a non-production environment with production data excluded or masked. Where we must look at production configuration, we agree the accounts, the window and the logging beforehand. Security findings are written in a separate annexe with restricted circulation, so a document intended for a wide internal audience does not become a map of your weaknesses.
We write findings about systems, not about people, and most serious findings trace back to a reasonable decision made under different constraints. We will say so where that is the case. If the engagement is being commissioned specifically to build a case against an internal team or an incumbent supplier, we would rather not take it.
Rarely. Source code, infrastructure definitions and read access to monitoring cover most of it, and we prefer a non-production environment with masked data. Where a specific question can only be answered in production, we agree the account, the window and what gets logged beforehand.
That is a legitimate and reasonably common outcome, and you get a report saying so with the evidence behind it. It has value — it turns a suspicion into a documented position you can take to a board. We do not manufacture findings to justify the fee.
We can, but there is an obvious conflict in recommending work to ourselves, and you should weigh the review accordingly. Many clients take the report to their existing team or supplier, which is a perfectly good outcome and one the report is written to support. If you do want us to help, we suggest agreeing that separately after you have had time with the findings.
The project brief takes about five minutes and gives us enough to have a useful first conversation about Architecture Review rather than a generic one. If you would rather just ask a question, the short form is there for that.
We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.