The CTO of a B2B e-commerce platform is looking at three numbers. The time from ticket to production for an average change has roughly doubled in a year. The cloud bill is growing faster than order volume. And in two quarters the board wants to enter the German market with a new pricing model that touches the basket, billing, the ERP integration and the warehouse. The team has three ideas: split billing into a separate service, rewrite everything as microservices, or “clean up” the monolith and leave the structure alone. Each idea has its champions, and each costs something different.
The CTO knows the argument will not be settled in a meeting. The team is too close to the system, everyone has a favourite answer, and some of the decisions that hurt today were made by people sitting at the same table. What is needed is someone from outside who can read the system quickly, talk to the people and say what in the architecture is a genuine risk, what is merely inconvenient, and which of the three paths makes sense for the given budget and deadline.
This article is for the CTO or technical lead considering such an audit. We explain how an architecture audit differs from a code audit and from an internal review, what its scope covers, how it runs, what the report should contain, what drives the price and what to put in the contract. If your question is about code written with AI assistants, we have a separate article on that; here we focus on the structure of the system regardless of who built it or how.
How does an architecture audit differ from a code audit and an internal review?
A code audit and an architecture audit look at the same system from two altitudes. A code audit checks the quality of the implementation: readability, duplication, test coverage, error handling, dependency security. An architecture audit checks the structure: how the system is divided into components, how those components depend on each other, how data flows, what the integrations and infrastructure look like, and what all of that means for scalability, reliability, security and the cost of change. Good code in a bad architecture is like well-finished rooms in a building without a staircase. Bad architecture with good code usually gives itself away when every change has to touch many places at once.
In practice the two perspectives overlap. You cannot assess architecture reliably without reading code on the critical paths, because diagrams often describe the system that was meant to be built rather than the one that runs. That is why ARDURA Consulting’s Code Health Audit combines a code review with an architecture assessment. If you want to see how such an audit looks from the code side, especially when the code was written with AI assistants, we described it in AI code audit in two weeks. Here we look higher up: at structural decisions and their cost.
The second distinction is between an external audit and an internal architecture review. An internal review is run by your own team, regularly, against a list of upcoming changes and quality criteria. It is good practice, and we covered the evaluation criteria in our software architecture review checklist. An external audit has a different purpose: it gives an independent assessment when the team is a party to the dispute, when the decision is expensive, when it has to be justified to the board or an investor, or simply when nobody on the team has experience with a system at this scale. The two complement each other: a good audit ends with a recommendation on how to run regular internal reviews.
When should a CTO commission an external architecture audit?
An architecture audit pays off when a decision with real money behind it depends on the structure of the system. There are several such situations, and it helps to recognise them because each sets a slightly different scope.
Before a major rebuild. The team proposes migrating to microservices, rewriting a module or changing the database. These are decisions worth hundreds of thousands of euros and months of work. The audit answers whether the problem the rebuild is meant to solve actually lies in the architecture, and whether the proposed change would solve it.
Before a jump in scale. A new market, a large customer, a campaign expected to multiply traffic. The question is what breaks first and what it costs to prepare. Scalability, performance and infrastructure are central here.
After taking over a system. A new CTO, a new vendor or an acquisition. You need to know what you have inherited before you commit to a roadmap.
When costs rise without explanation. The cloud bill grows faster than traffic, lead time for changes lengthens, incidents become more frequent. These symptoms often have a structural cause that is invisible at the level of individual tickets.
Before an investment or transaction. An investor or acquirer wants to know whether the technology can support the business plan. That scope is close to technical due diligence, with more emphasis on the team, the process and risks to deal value.
When is an audit wasted money? When the decision has already been made and nobody intends to revisit it; the audit then becomes an expensive confirmation. When the system is a prototype that will be rewritten anyway. And when nobody will act on the findings. Before ordering, write down the decision the audit should support and the person who will own the action plan. If you cannot, you are not ready for an audit yet.
What does an architecture audit cover?
The scope should follow from the question the audit has to answer, but most audits touch the same areas. Established quality models are a useful reference. ISO/IEC 25010:2023 defines a product quality model with nine characteristics, including reliability, security, maintainability and performance efficiency. The AWS Well-Architected Framework describes six pillars: operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability (AWS). Neither model is a checklist to tick off, but both help ensure the audit misses nothing important.
In practice the scope usually covers seven areas.
Structure and dependencies. How the system is divided into modules, services or layers, the direction of dependencies, ownership boundaries, and places where a change in one component forces changes in many others. This is where the cause of growing lead times most often lies.
Data. The data model, data ownership between components, consistency, migrations, backups and whether they can be restored. Multiple sources of truth for the same data are among the most expensive problems to fix later.
Integrations. Interfaces with external and internal systems, error handling and retries, dependence on partners’ availability, API versioning.
Scalability and performance. Where the bottlenecks are, what happens at several times the traffic, which parts scale horizontally and which do not. Access to monitoring and, where possible, performance profiling help here.
Reliability and operations. Single points of failure, monitoring and alerting, deployment approach, recovery time after a failure, business continuity.
Security architecture. Trust boundaries, authentication and authorisation between components, secrets management, network segmentation, a security review of dependencies. This is not a penetration test of the live system, but an assessment of whether the structure supports security.
Cost of change and technical debt. What it costs today to add a typical feature, where the debt sits, what it costs in day-to-day work and what paying it down would take. This area translates the others into the board’s language.
For investor questions or a large jump in scale, the scope adds the team and delivery process, broader infrastructure and open-source licence compliance. That is technical due diligence territory. Our glossary entry on software architecture sets out the general concepts.
What will an architecture audit not do?
The boundaries of the scope matter as much as its content, because they shape the board’s expectations. An architecture audit does not replace four other pieces of work it is sometimes confused with.
It is not a penetration test. It assesses whether the structure supports security and reviews code and dependency security, but it does not attack the running system from outside. If you need confirmation that a vulnerability cannot be exploited, order a pentest separately, ideally after the audit, when you know where to look.
It is not a load test. It can identify bottlenecks from code, configuration and monitoring data, but it does not measure at what traffic level the system actually stops. If the decision depends on that number, plan performance testing as the next step.
It is not a target architecture design. The audit tells you what is a risk, what must change and in what order, and compares options when the direction is disputed. A detailed target design with interface contracts and a data migration plan is separate work, better commissioned after the decision than before it.
It is not an assessment of individuals. The audit describes decisions and their consequences, not the competence of particular people. In technical due diligence it assesses the team and process as a whole, but the goal is not to find someone to blame. A team told at the start that the audit is looking for culprits will stop telling the truth, and without that the report is worth less.
Which methods does an architecture audit use?
A sound audit combines several methods, because each sees something different. Ask a vendor which ones they use and in what proportions.
Documentation review and model reconstruction. The auditor gathers existing diagrams, descriptions and decisions, and where they are missing, reconstructs the model from code and configuration. A popular notation is Simon Brown’s C4 model, which describes a system at four levels: context, containers, components and code (c4model.com). The reconstructed model is often one of the most valuable outputs of the audit, because the team sees the whole system for the first time.
Static and dependency analysis. Tools reveal the dependency structure between modules, cycles, high-complexity hotspots and frequently changed files. On their own they produce a lot of noise, so their output is a starting point for manual review, not a conclusion.
Manual review of critical paths. Experienced engineers read code and configuration where the business is decided: payments, billing, authorisation, the main integrations. This is where real risk is separated from theoretical risk.
Quality attribute scenarios. Instead of asking in general whether the system is scalable, the audit writes concrete scenarios: “traffic grows fivefold within an hour”, “a partner changes its API format”, “we need to add a new currency”. For each one it assesses how the architecture behaves and what adapting it would cost. The approach derives from ATAM, the Architecture Tradeoff Analysis Method developed at the Software Engineering Institute at Carnegie Mellon University, which evaluates an architecture against quality attribute goals and exposes the trade-offs between them. According to the SEI, a full ATAM evaluation typically takes three to four days and involves a broad group of stakeholders (SEI); commercial audits often use a lighter version.
Conversations with the team. Short conversations with the architect, team leads and whoever runs operations explain why the system looks the way it does and which constraints were real at the time. Without them, the auditor judges decisions without context and the report turns into a list of accusations.
Operational data. Monitoring metrics, incident history, cloud bills, deployment data. Google Cloud’s DORA research programme describes five software delivery performance metrics, including change lead time, deployment frequency and change fail rate (DORA). If you measure them, the audit can link structural problems to numbers the board understands.
How does an architecture audit run, week by week?
The flow depends on system size and package, but it has a repeatable structure. Here is an example of a two-week audit of a system with several services and integrations.
Before the start: NDA, scope, access. Sign the NDA, agree the questions the audit must answer and the scope boundaries. Grant read-only access to repositories, documentation and, if needed, infrastructure configuration and monitoring. Schedule the team conversations.
Days 1–3: model and scans. Reconstruct the system model from documentation, code and configuration. Run static and dependency analysis across the codebase. Produce a first list of hypotheses about where structural problems may lie.
Days 4–7: manual review and conversations. Read the critical paths, test the hypotheses, talk to the team. Review operational data and infrastructure costs. Work through quality attribute scenarios for the key questions, such as a traffic spike or a new feature that touches many components.
Days 8–9: synthesis. A risk map rated by business impact, a technical debt estimate, priorities and an action plan. If the audit has to settle a dispute about direction, such as a rebuild, this is where the comparison of options with costs and risks is produced.
Day 10: report and read-out. A written report and a session with your decision makers, with time for questions before action is taken.
In the three-week variant typical of technical due diligence, the audit adds an assessment of the team and delivery process, a broader review of infrastructure and scalability, and open-source licence compliance, and the report is written so that investors and board members without a technical background can read it.
What should an architecture audit report contain?
The report is the product you are paying for, so it is worth knowing in advance what it should look like. A good architecture audit report has five parts.
Executive summary. One or two pages: the answer to the question you asked at the start, the main risks and the recommendation. If your CEO cannot understand this part unaided, the report was written for the auditor, not for you.
System model. A current picture of the architecture, usually at two or three levels of detail. Often the first up-to-date diagram the system has ever had.
Risk map. Findings grouped by area (structure, data, integrations, scalability, reliability, security, cost of change) and rated by business impact and likelihood. Each finding refers to a specific component, file or configuration rather than a generality.
Technical debt estimate. Where it sits, what it costs in day-to-day work and what paying it down would take, expressed as ranges, not a single number.
Priorities and action plan. A clear split between what must be fixed now, what can wait until next quarter and what you can consciously accept. Concrete steps in the right order, so that your team, a new vendor or an external team can start a week after the read-out. If the audit was meant to choose a direction, the report compares the options with their costs, risks and the conditions under which each makes sense.
Beware of reports made up mainly of tool charts and hundreds of unprioritised warnings. They are easy to produce and useless for decisions. Before signing, ask for an anonymised sample or at least a table of contents.
How much does an architecture audit cost, and what drives the price?
There is no credible public market price list for architecture audits that could honestly be quoted. So we give two things: our own prices, which can be checked, and the factors that move the price with any vendor.
At ARDURA Consulting, architecture assessment is not a separate product but part of two fixed-scope packages described on our technical due diligence and code audit page:
- Code Health Audit: from €4,500, one to two weeks. Scope: code review and static analysis, architecture assessment, performance profiling, security review of code and dependencies, technical debt estimate. Deliverable: a written report with a risk map and a prioritised remediation plan.
- Technical Due Diligence: from €8,500, two to three weeks. Scope: everything in the Code Health Audit plus the team and delivery process, scalability and infrastructure, open-source licence compliance, and risks that matter to an investor or acquirer. Deliverable: an investor-ready report and a read-out session with your decision makers.
The final price depends on the size of the system and is fixed before work begins, so it does not grow during the audit. If your question is mainly about structure, debt and the cost of change, the first package is usually enough. If it is about scalability, infrastructure and the team, or there is an investor behind it, the second is the right fit.
With any vendor, the same factors move the price. The table below helps match the scope to your question.
| Your question | Areas that must be in scope | ARDURA package | Typical duration | What pushes the price up |
|---|---|---|---|---|
| Why are changes taking longer, and what does it cost us? | Structure and dependencies, technical debt, critical paths | Code Health Audit | 1–2 weeks | Number of repositories and languages, size of the monolith |
| Does a rebuild (e.g. splitting out services) make sense? | Structure, data, integrations, change scenarios, option comparison | Code Health Audit, sometimes extended | 2 weeks | Number of options compared, how scattered the data is |
| Will the system handle a multiple increase in traffic? | Scalability, performance, infrastructure, reliability | Technical Due Diligence | 2–3 weeks | Infrastructure complexity, missing monitoring, need for load tests |
| What are we inheriting from the outgoing vendor? | Structure, documentation, debt, security, process | Code Health Audit or Technical Due Diligence | 1–3 weeks | Missing documentation, no access to the people who built it |
| Can the technology support the investor’s plan? | All of the above plus team, process and open-source licences | Technical Due Diligence | 2–3 weeks | Number of products, regulatory requirements, transaction deadline |
| Why is the cloud bill growing faster than traffic? | Infrastructure, structure, performance, operational data | Technical Due Diligence | 2–3 weeks | Number of accounts and environments, no cost tagging |
Two things bring the price down. The first is preparation: gathered documentation and booked time with the right people shorten an audit more than any discount. The second is a precise question. An audit of “the whole system, just in case” costs more and delivers less than one that has to answer a single specific question.
How do you set the scope so the audit does not grow to fill the budget?
An architecture audit is bounded work, but only if the scope is written down precisely. Four rules help keep it that way.
Start from the decision, not the system. Write in one sentence which decision the audit supports. “Do we split billing into a separate service before entering the new market?” gives a completely different scope from “assess our architecture”.
Name the boundaries. Which components, repositories and environments are in scope and which are not. If the system has a module nobody plans to touch for two years, do not pay for a detailed review of it.
Agree the level of detail of the conclusions. Do you need a recommended direction with estimates in ranges, or a target architecture design? The second is separate work, usually after the audit rather than part of it.
State what happens if the audit finds something out of scope. For example, a critical security gap in an excluded module. Good practice: the auditor reports it immediately without analysing it in depth, and you decide whether to extend the scope.
For example, a well-written scope for the platform in the introduction might read: “The audit must determine whether, before entering the new market, to split the billing module into a separate service or restructure it within the current monolith. In scope: the main application repository, the basket, billing and pricing modules, the ERP and warehouse integration, infrastructure configuration and six months of cloud cost data. Out of scope: the admin panel and the mobile app. Output: a risk map, a comparison of the two options with cost and risk, a recommendation and a plan for the first steps.” A description like that can be priced, delivered on time and accepted against.
If you are not yet sure how to frame the question, our free technical debt checklist can help: 42 yes/no questions across seven areas of a system. The answers often show where the problem lies and let you narrow the audit scope.
What does the auditor need from your team?
An audit is only fast if the auditor is not waiting for access or people. Prepare four things.
Read-only access. Code repositories, documentation, infrastructure-as-code configuration if it exists, monitoring and logs. Access to test or production environments is optional but helps with performance findings. Write access is never needed.
Documentation, whatever its state. Diagrams, even outdated ones, architecture decision records, integration descriptions, incident history, onboarding notes. “We have no documentation” is a finding too, but anything you have saves time.
Time with the right people. Three or four conversations of half an hour to an hour: with the architect or most senior engineer, with team leads, with whoever runs operations and deployments, sometimes with the product owner.
Operational and cost data. Monitoring metrics, deployment data, recent cloud bills. Without them, conclusions about performance and cost rest on guesswork.
What should go into the contract with the auditor?
An audit contract is short, but a few clauses protect you from the usual problems.
NDA before access. Confidentiality signed before any access to code, documentation or systems is granted.
Fixed scope, timeline and price. The questions the audit answers, scope boundaries, duration and price agreed in writing before the start. If a vendor cannot fix them, the audit will expand to fill the budget.
List of deliverables. The report with its named sections, the system model, the read-out session. Ideally with a sample or table of contents attached.
Ownership of the report. The report and action plan belong to you, with the right to share them with your board, investors and other vendors.
Independence. A clause stating that the audit does not commit you to further work with the auditor. If the auditor also offers to implement the plan, that is fine, but the decision on who carries it out is yours.
Read-only access and data handling. The scope of permissions, how audit data is stored, and deletion of copies once the work is complete, consistent with your GDPR obligations if personal data is visible in the systems.
What are the red flags when choosing an audit vendor?
Ask a few questions before signing, whoever you choose.
Who reads the code and configuration? Tools are a given. Ask what share of the work is manual review by experienced engineers and how they choose what to read. A vendor that sells tool output with a logo on the cover is selling you hundreds of unprioritised warnings.
Does the vendor have an answer before the audit? If at the first meeting you hear that “you need to move to microservices” or “everything should go to cloud X”, the audit will confirm the thesis rather than test it.
What does the report look like? Ask for a sample. Look for an executive summary, ratings by business impact, a prioritised plan and specific references to components.
Are scope and price fixed? An audit is bounded work. Open-ended hourly billing is a sign the vendor does not know what it will do.
What happens if they find something you cannot fix yourself? A good vendor sets out options, including working with someone else. A vendor whose audit always concludes that you need its team for a year is selling a sales funnel, not an audit.
What should you do with the audit findings?
The report changes nothing by itself. The value of an audit is created in the weeks after the read-out, and the first steps are worth planning before it ends.
Assign owners for the first actions at the read-out. The top three items in the plan should have an owner and a deadline before everyone leaves the room.
Turn recommendations into decisions recorded as ADRs. Every recommendation you accept or reject should go into an architecture decision record: context, decision, status, consequences. A year from now everyone will know why the system looks the way it does.
Put the debt into planning. Agree what share of team capacity goes to paying down the debt identified in the audit, and track progress. Otherwise the debt will lose to every new feature.
Set up regular internal reviews. An external audit is a snapshot. Internal reviews, using criteria like those in our architecture review checklist, maintain quality between audits.
Decide who executes the plan. Your team, another vendor or ARDURA. If the audit shows the system needs stabilising or a vendor transition, we can continue through Software Rescue, starting from the priorities set in the audit. The symptoms that usually lead there are described in seven signs a vibe-coded app needs rescue. More on building and evolving systems is collected in our software development hub.
When should you repeat the audit?
An external audit does not need to be an annual ritual. Sensible moments for another one are: the completion of a major rebuild the audit recommended, to check whether it delivered; the next decision of similar scale, such as another market or a new product line; a change of vendor or of key people on the team; and a point where the indicators the audit helped establish stop improving. A second audit is usually shorter and cheaper than the first, because the system model, decision log and risk list already exist.
What should you remember before ordering an architecture audit?
An architecture audit is not a performance review of your team or a contest for the prettiest diagram. It answers a narrower and more practical question: what in the structure of the system is a real business risk, what it costs, and what to do first. It works best when a specific decision stands behind it and worst when it is ordered “just in case”.
Remember five things. First, write down the decision the audit should support and the person who owns the action plan. Second, match the scope to the question: structure and debt usually mean a Code Health Audit; scalability, infrastructure and the team mean technical due diligence. Third, insist on methods that combine tools with manual review, conversations and quality attribute scenarios. Fourth, fix scope, timeline and price in writing before the start; at ARDURA the Code Health Audit starts from €4,500 and Technical Due Diligence from €8,500. Fifth, plan what you will do with the findings before the report lands on your desk.
If you are facing a decision about a rebuild, a jump in scale or taking over a system, review the Code Health Audit and Technical Due Diligence packages or book a scoping call. In half an hour we will tell you which package fits your question, what it will cost and whether you need an audit at all.