The architecture diagram on the wall is eighteen months old. Somebody drew it for a board deck, it was accurate for roughly six weeks, and it has been quietly wrong ever since. Nobody updates it because nobody uses it, and nobody uses it because everybody knows it’s wrong.
That diagram is usually the first finding, and it’s never the worst one. The worst one is whatever the team has stopped mentioning because they have all silently agreed to work around it. Every engineering organisation has one. Ask three developers what they would fix if they had a free month and you will get the same answer from all three, phrased differently, and none of them have ever put it in writing.
So this article doesn’t explain how an architecture review is conducted. Every other page on this subject already does, in numbered phases. What follows instead is the output: eight findings that appear in codebase after codebase, what each one looks like from the outside, what it’s costing you in units you can put in a budget, and how long the repair actually takes. Read it as a checklist against your own system. Several of these will feel uncomfortably specific.
What a Software Architecture Review Is, and Why This Is a List of Findings
A software architecture review is an independent evaluation of a system’s structural decisions, its components, boundaries, data flows, dependencies and failure modes, measured against the scalability, reliability and maintainability the business actually needs. Empyreal Infotech delivers it as a written report that ranks every finding by risk, repair cost and business impact.
The distinction that matters most is the one between a code audit and an architecture review, because clients frequently buy the wrong one. A code audit inspects implementation: test coverage, duplication, vulnerabilities, style. An architecture review inspects decisions: where the boundaries sit, what talks to what, and what happens when one piece of it stops responding. Immaculate code inside a broken structure still produces four-week releases and 3am pages. You can’t refactor your way out of a boundary problem.
The financial backdrop isn’t subtle. CISQ put the accumulated software technical debt in the United States at roughly $1.52 trillion in its 2022 report, a figure it reports alongside rather than inside a total annual cost of poor software quality of at least $2.41 trillion. Those numbers are too large to act on. The point of a review is to convert your slice of them into eight or nine specific line items with names, owners and repair estimates.
One more thing before the findings. None of what follows is exotic. There are no clever architectural crimes in this list, because clever crimes are rare and boring ones are universal. What makes these findings expensive isn’t their sophistication. It’s that they’re invisible from the outside, so nobody escalates them until they are structural.
Finding One: The Distributed Monolith
A distributed monolith is a system split into separate services that still have to be deployed together, because they share a database schema or call each other synchronously in a fixed order. It’s the most common serious finding in a software architecture review. You pay the full operating cost of microservices and keep the full release risk of a monolith.
You will recognise it by the release ritual. Deploys happen on a fixed day, they involve a checklist, and the order matters. Someone in the channel says wait for payments to go out first. If a single service can never be released on its own without something else breaking, the split was administrative rather than architectural. The services were carved out of the codebase but the coupling was never removed, so it moved from function calls into the network, where it’s harder to see and much harder to test.
What it costs shows up as release cadence. In the audits behind this list, teams in this state ship weekly at best and often fortnightly, where the same team on a genuine monolith would ship daily. Every release drags in changes from four teams, so every rollback drags them back out. Incident blast radius is the second bill: a bad deploy in one service takes down three, because nothing between them tolerates failure.
The repair isn’t a rewrite and it isn’t a merge back into one codebase. It is boundary work: pick the one service with the most cross-service reads, give it its own tables, replace the synchronous calls into it with events or an explicit versioned interface, and get it deploying independently. One service, done properly, takes four to eight weeks. Doing all of them at once takes a year and usually gets cancelled in month five.
Finding Two: One Database, Six Owners
A shared write-database with multiple owning teams is the finding that makes every other repair slower. When six services read and write the same tables, no schema change is safe, no migration is local, and no team can move without a coordination meeting. It’s usually the root cause behind three or four other findings in the same report.
The tell is a migration policy that exists only in people’s heads. Somebody knows that column cannot be renamed because reporting reads it. Somebody else knows the nightly job breaks if that table is locked for more than thirty seconds. None of it is written down, and all of it is load-bearing. Ask who owns a given table and watch the pause before anyone answers.
Price it in blocked work rather than in outages. A schema change that should take an afternoon takes three weeks because four teams have to agree, test and release in sequence. Multiply that by the number of times a quarter a product decision needs a new field. McKinsey reported in 2020 that CIOs put 10 to 20% of the technology budget dedicated to new products as diverted into resolving tech debt, and shared-database coordination is one of the purest examples of where that share goes.
Repair sequence: stop the bleeding first by making every new table single-owner, which costs nothing and takes a policy decision. Then split the two or three hottest shared tables behind an owning service, exposing reads through an interface and moving the other consumers onto it one at a time. Expect six to twelve weeks for the first table and considerably less for each one after, because by then the team has done it once.
Finding Three: The Call Chain With No Circuit Breaker
Synchronous call chains without timeouts, retries or circuit breakers turn one slow dependency into a total outage. A request enters, waits on a service that is waiting on another service that is waiting on a third-party API having a bad afternoon, and every connection in the pool is held open until the whole system stops answering. Nothing crashed. Everything is just waiting.
This finding is easy to confirm and almost nobody checks for it. Search the codebase for the HTTP client configuration and look for an explicit timeout. In a large proportion of systems there isn’t one, which means the default applies, and several popular clients default to waiting indefinitely. The same search usually reveals retries with no backoff, which converts a struggling downstream service into a downstream service under attack from its own callers.
The cost is measured in incident hours and in the shape of your outages. Systems with this finding do not degrade, they fall over, and they fall over completely, which means every incident is a severity one and every incident involves everybody. Teams describe it as the site going down when in fact one non-critical feature went slow and took the checkout with it.
This is the cheapest serious repair on the list. Start with the checkout path rather than the whole estate. Explicit timeouts on every call site in it, jittered backoff on every retry, a circuit breaker in front of each third-party dependency, and fail-soft on the non-essential ones so a recommendations widget cannot take down a payment flow. Two engineers, two to three weeks for the first path, then repeat it per path. The outage profile changes permanently after the first one. If you fix one thing in this article, fix this one.
Finding Four: The Component Nobody Will Touch
Every mature system contains one load-bearing component that is undocumented, barely tested, and understood by exactly one person. In a review this shows up within the first two days of interviews, because everybody names the same file and then changes the subject. It’s a staffing risk disguised as a technical one.
The behaviour around it is more diagnostic than the code itself. Tickets touching that area get quietly reassigned. Estimates for work near it run visibly higher than for comparable work elsewhere, and nobody questions the inflation. New engineers are told during onboarding not to go in there without asking. The classic version of it is a pricing engine written over a weekend by a contractor who no longer replies to email.
Cost it in two units. First, the option value you have lost: any product change that would require touching it simply doesn’t get proposed, so your roadmap is being edited by fear rather than by strategy. Second, the concentration risk. Stack Overflow’s 2024 survey found technical debt to be the single most-cited frustration among professional developers at 62.4%, well clear of the next item, and components like this one are where that frustration concentrates and where resignations start.
Do not rewrite it. Characterise it. Put a test harness around its current behaviour, including the behaviour that’s technically wrong but that downstream systems now depend on. Then document what it does in prose, not comments, and have a second engineer make one small change under supervision. Three to five weeks, and the bus factor moves from one to two, which is where most of the value is.
Finding Five: Logs Everywhere, Traces Nowhere
Most teams have plenty of logs and no way to follow a single request across services. Without correlation IDs and distributed traces, mean time to resolution is dominated by finding the fault rather than fixing it. Engineers reconstruct the path by hand, comparing timestamps across four dashboards, while the incident channel fills up with people asking for updates.
The giveaway question in an interview is simple: when something breaks, how do you find out where. If the answer involves a person rather than a system, the finding is confirmed. The second giveaway is the absence of service level objectives. Teams with no measured service level indicators can’t tell you whether last Tuesday was unusual, and teams with no objectives set on top of them can’t tell you whether it mattered, which means they can’t tell whether a change made things better or worse, which means every architectural decision after that point is made on vibes.
The cost is a straight multiplier on every incident you will ever have. It also silently taxes the repairs in this article, because you can’t safely split a service you can’t observe. That is why observability usually gets sequenced first in a fix list even though it’s nobody’s idea of an exciting quarter.
Repair is well-trodden. Propagate a correlation ID from the edge through every service, adopt one tracing standard rather than three, instrument the five most important user journeys rather than everything, and define two or three SLOs that somebody actually watches. Three to six weeks for a mid-sized system. The signal it sends internally is worth almost as much as the tooling: it tells engineers that reliability is now measured, not asserted. For teams running Kubernetes and platform engineering at any scale, this is table stakes rather than a nice-to-have.
Finding Six: The Org Chart Leaking Into the Architecture
When service boundaries do not match team boundaries, velocity collapses for organisational reasons that look technical from the inside. If a routine feature needs code from four teams, the problem isn’t the code. It’s that the system was decomposed along one set of lines and the company was organised along another, and the two have been diverging ever since.
This is the finding clients argue with most, because it implicates people rather than software. The evidence is boring and hard to dispute: take the last twenty completed tickets and count how many teams had to ship code for each. If most of them needed more than one, the boundaries are worth arguing about. Reviews that only read code never surface this, which is why interviews aren’t optional and why a two-day desk review is worth very little.
The cost lands as an unexplained slowdown that survives every attempted fix. Leadership hires more engineers and delivery gets slower, which is the classic signature. Every additional team adds coordination surface without adding throughput, and the planning meeting grows until it consumes the morning.
The repair is organisational and it is not the review team’s to make. What the review can do is put the map on the table: here are the services, here are the teams, here are the six features that crossed four boundaries last quarter, and here are two alternative cuts. Producing that map and the two alternative cuts takes about a day inside the audit week. What follows is the company’s own timeline, usually a quarter. Some companies move the teams. Others move the services. Both work. Doing neither, and hiring instead, does not.
Finding Seven: AI Features With No Cost Ceiling
The newest finding on this list. It doesn’t come from the same frequency count as the other seven, because it barely existed when most of those audits were run. An AI feature has been added to the product with no per-request cost ceiling, no rate limiting per tenant, no evaluation suite, and the model call sitting directly in a synchronous request path. It is a non-deterministic component with an unbounded cost line, wired in as though it were a database lookup.
Three specific things turn up together. Prompt text lives inside application code, so changing behaviour requires a deploy and there is no record of what the prompt said last month. There is no eval set, so nobody can answer whether last week’s model change made output better or worse. And the cost per request is unmodelled, which means a single enterprise customer with an integration loop can produce a bill nobody forecast.
The cost is unusual because it’s genuinely unbounded rather than merely large. Every other finding on this list costs a predictable amount. This one has a tail. The second cost is trust: a feature that silently degrades when a model is updated will lose customer confidence before anybody internally notices, because nothing is watching output quality.
Fix the boundary before the prompt. Move model calls out of the synchronous path where the user experience allows it, add per-tenant rate limits and a hard ceiling on input and output tokens per request, pull prompts into versioned configuration, and build an eval set of fifty real cases you can run against any model change. Two to four weeks, and it converts an open-ended liability into a line item you can forecast.
Finding Eight: The Cloud Bill That Scales With Headcount
The finding that most often pays for the review itself. Infrastructure grows by accretion: environments created for a project that ended, instances sized for a launch that never came, always-on staging clusters idling through every weekend. The bill correlates with how many engineers you’ve hired rather than with how many customers you serve.
The structural tell is the absence of ownership. Ask which team owns a given resource and the answer is a shrug, because the person who created it has moved on and nothing is tagged. Untagged infrastructure isn’t a finance problem. It’s an architecture finding, because it means no service has a cost, which means no design decision has ever been evaluated on what it costs to run.
Savings here are usually immediate and frequently large, which makes this the finding worth doing first for political reasons even when it is not the most dangerous one on the list. A repair that returns money buys goodwill for the repairs that only return safety.
Tag what you can attribute, and give everything you cannot a single unclaimed owner with a deletion date against it. Put a cost figure next to each service somewhere engineers see weekly, schedule non-production environments to sleep outside working hours, and right-size against measured usage rather than launch-day guesses. Two to three weeks to tag, then a quarter of attrition on the unclaimed pile. Then, and only then, look at reserved capacity, because committing to a three-year discount on infrastructure you haven’t yet right-sized is an expensive way to lock in a mistake.
The Findings You Should Not Fix
A credible architecture review tells you what to leave alone. A meaningful share of what a thorough audit surfaces should be documented, accepted and deliberately ignored, because the repair costs more than the defect. A report where every finding is urgent is a sales document, and the fastest way to check a consultant’s honesty is to ask which findings they are recommending against fixing.
The test is simple and it’s not about severity. Multiply how often the problem actually bites by what it costs each time, and compare that against the repair estimate and the risk of the repair itself. Plenty of genuinely ugly code fails this test comfortably, because ugly and expensive are different properties and reviewers who conflate them generate enormous invoices and very little value.
Three Findings We Regularly Tell Clients to Leave Alone
These come up in most audits and rarely justify the work:
- The ugly module that never changes: badly written, well isolated, touched twice in three years. Cost of leaving it: nearly zero. Document it and move on.
- An outdated framework version with no live vulnerability: upgrading is real work with real regression risk. Schedule it with a feature that already touches that surface, rather than as its own project.
- Duplicated code across two services: the shared library that removes it also recouples the services you paid to separate. Some duplication is the price of independence.
What all three need is not a repair but a written decision, so that the next engineer who finds them knows somebody already looked and chose. Accepted risk that is recorded is architecture. Accepted risk that is forgotten is just debt with a longer fuse.
What a Software Architecture Review Costs, and What You Actually Receive
An Empyreal Infotech software architecture review runs five working days and costs £8,000. Read-only access on Monday, written brief in your inbox by Friday. It’s been run 47 times since 2019, which is where the eight findings above come from: they’re not a taxonomy, they’re a frequency count.
Five days is deliberate rather than economical. Reviews scoped shorter turn into checklist exercises that surface only what a checklist can predict, which by definition excludes everything specific to your system. Reviews scoped much longer tend to produce documents nobody finishes reading. The constraint is what forces prioritisation: with five days, a reviewer has to decide what matters instead of cataloguing everything that exists.
What Lands in Your Inbox on Friday
The deliverables are fixed, so you know before you start what you’re buying. Four of them do most of the work:
- A 30-page written brief: every finding with its symptom, its cost, and either a repair estimate in days, weeks or quarters, or a written reason we recommend against repair.
- A one-page architecture diagram: the system as it actually is today, not as the board deck describes it.
- Six architecture decision records minimum: drafted in markdown and ready to commit, so the reasoning survives the people. Your team reviews them and owns the words.
- A prioritised fix list: ordered by blast radius against repair cost, including what we recommend you do not fix.
Where the review is preparation for a funding round or an acquisition, those ADRs matter more than the brief. A diligence engineer wants evidence that decisions were made deliberately, and six well-written records demonstrating you understood the trade-offs will do more for you than a clean codebase with no explanation attached. Full details sit on the software architecture services page, including what happens after the report if you want help executing the list.
Recognised three of these in your own system? That’s usually enough signal to book the audit. Send us the shape of your stack and we will tell you whether five days is the right scope or whether you need something smaller.
Frequently Asked Questions About Software Architecture Reviews
What is a software architecture review?
A software architecture review is a structured evaluation of how a system is designed: its service boundaries, data model, dependencies and failure points, measured against the quality attributes the business needs. Empyreal Infotech delivers it as a written report ranking every finding by risk, repair cost and business impact.
How long does a software architecture review take?
Five working days for a focused audit, which is the format Empyreal Infotech runs: read-only access on Monday, written brief by Friday. Larger multi-tenant platforms sometimes need a second week. Anything advertised as a two-day review will find only what a generic checklist predicts, which is rarely what’s actually wrong.
What is the difference between a code audit and an architecture review?
A code audit inspects implementation quality: coverage, duplication, vulnerabilities, style. A software architecture review inspects structural decisions: boundaries, data flow, coupling and failure modes. Clean code inside a broken structure still produces slow releases and wide outages, and no amount of refactoring fixes a boundary that was drawn in the wrong place.
When should you get an architecture review?
When releases keep slipping, when one bug reliably breaks three unrelated features, when cloud spend outpaces customer growth, or when a funding round means someone external is about to read your codebase. The most valuable timing is before a rewrite decision rather than after the rewrite has started.
Do we need an architecture review or a fractional CTO?
A review answers what is wrong and what it costs. It’s a one-off diagnostic. If the harder problem is that nobody senior owns the technical direction week to week, you need a fractional CTO to own the roadmap instead. Many teams start with the review and use its fix list as the first quarter of that engagement.
What to Do on the Monday After
You don’t need to commission anything to use this article. Take the eight findings, walk them with two engineers who have been at the company longest, and mark each one present, absent or unsure. The unsure column is the interesting one, because it tells you where nobody currently has visibility, and that is where architecture reviews earn their fee.
Then pick the one finding your team has already worked around twice this quarter and cost it properly: hours lost, releases delayed, incidents caused. Put a real number next to it and take that number to whoever holds the budget. A finding with a price attached gets fixed. A finding described as technical debt gets deferred, every time, in every company, for as long as anyone has been keeping track.
If the system in question is SaaS platform architecture carrying real tenants and real revenue, do this sooner rather than at the point where a diligence call forces it. The findings don’t get cheaper while you wait. They compound, quietly, in the direction of the one component nobody will touch.
If you would rather have the eight walked against your own repository than against your memory of it, book the five-day audit and you will know by Friday which of them you have. Read-only access, fixed price, and a report you keep whether or not we ever work together again.
The diagram on your wall is wrong. Everything else in this article follows from being willing to say so out loud.