Software Architecture Review FAQ

What is a software architecture review?

An architecture review is a focused investigation into whether your software architecture is helping or holding back your business. We look at the system, the way work flows through it, the organisational context around it, how it supports your business and the constraints that make change difficult.

The goal is not to produce a long theoretical report. The goal is to give you a clear diagnosis of what is slowing you down and a practical recommendation for what to do next.

When should we consider an architecture review?

You should consider an architecture review when your software is becoming hard to change, delivery is slowing down, or technical discussions keep circling without clear decisions.

Typical signs include small changes causing unexpected side effects, teams avoiding to make changes to parts of the system, long lead times, repeated production issues, unclear ownership, or a growing gap between what the business needs and what the software can support.

Whom is the architecture review for?

The review is for companies where software has become business-critical and where architecture may now be limiting speed, quality, scalability, or strategic options.

It is especially useful for scale-ups, product organisations, and companies with complicated systems that need to understand where to invest next.

You decide the questions, we will do our utmost to answer them.

How long does the review take?

The standard architecture review is designed to take two calendar weeks. During that time we gather context, analyse the system, validate findings, and present a clear diagnosis with recommended next steps.

The format is intentionally time-boxed so that you get useful insight quickly, without starting a large open-ended consulting engagement.

The time-box also has value in itself. What becomes visible quickly is often a strong signal of where attention is needed most.

How much do we need to prepare?

Not much. Come as you are. We need your help getting access to key people and to the codebase, but you do not need to prepare presentations, clean up documentation, or tidy the code. Seeing the system as it is helps us understand the real situation faster.

What do you look at during the review?

We look at the architecture as a sociotechnical system: the software, the teams, the workflows, and the business context around it. That means we do not only inspect the code. We talk to the people who work with the system every day, because they usually know where the real constraints, risks, and trade-offs are better than any tool can tell us.

We typically explore areas such as team structure, ownership, dependencies, change patterns, build and deployment pipelines, test strategy, documentation, and how the architecture supports the business goals. We use the codebase selectively to validate what we learn, not to scan every line.

We also take targeted samples from the codebase, using an approach we have refined over many years. Based on what we find, we may build small tools or scripts to investigate the questions that emerge.

This is why the review can usually be completed in two weeks. We combine conversations, existing knowledge, and targeted technical investigation to follow the strongest evidence quickly, instead of trying to analyse the whole system from scratch.

Is the review about finding who made bad decisions?

No. We are not there to point fingers. Software systems are shaped by real-world constraints: deadlines, budgets, customer needs, organisational changes, shifting strategies, and the information people had available at the time. In our experience, there are usually good reasons why something looks the way it does.

Because we have seen many architectures, teams, and organisations, we can bring an outside perspective without assuming that “different” automatically means “better” or "worse". We look for the patterns that matter, help separate symptoms from causes, and suggest changes that move the system in the direction the customer actually wants to go.

Our goal is to enable the teams, not replace their judgement. The people working with the system know it best, and any future architecture must be something they can understand, influence, and own. We adapt to what the team knows and feels comfortable with.

Do you need access to our source code?

Yes. To make a useful architectural diagnosis we normally need access to the codebase and surrounding development environment. That said, the review is not only a code review. Code tells part of the story, but so do tickets, workflows, deployment habits, team boundaries, and business constraints.

We may also ask to look at selected data, such as business metrics or observability data, to better understand how the system behaves in practice. We know this can be sensitive, so we only do this to the extent needed and preferably together with someone from your organisation.

We work under NDA and follow the access restrictions that make sense for your organisation.

Is this the same as a code review?

No. A code review usually focuses on code quality in a specific area. An architecture review looks at the broader system: how the software is structured, how it changes over time, how teams work with it, and whether the architecture supports the business direction.

We will inspect some code samples in detail (after all the proof is in the pudding), in order to understand what the code reveals about the larger architecture, delivery flow, risks, and constraints.

What do we get at the end?

You get a concise, actionable presentation of our findings. It includes the main bottleneck hypotheses, supporting evidence, prioritised risks and opportunities, and recommended next steps.

The purpose is to help leadership and technical teams align around what matters most, what to do first, and what not to spend energy on right now.

Will you tell us exactly what technology to use?

Only if that is genuinely the most important decision. Most architectural problems are not solved by simply choosing a new framework, cloud service, or programming language.

We start from the business problem and the constraints in the current system. Sometimes the recommendation is technical. Sometimes it is organisational. Often it is a combination of both.

Will the review disrupt our teams?

We try to keep disruption as low as possible. The review typically involves a workshop, a questionnaire or interviews with key people, access to relevant systems, and occasional follow-up questions.

We know your teams have real work to do, so we aim to learn quickly and use existing material wherever possible.

Who should be involved from our side?

The best results usually come when we can speak with people who understand the business goals, the product direction, the architecture, and the day-to-day delivery challenges.

That often means a mix of leadership, product people, architects, developers, and people close to operations or support. You do not need a large group throughout the whole review, but we do need access to the people who can explain how the system really works.

Is the review only for legacy systems?

No. Legacy systems are a common reason to do an architecture review, but they are not the only one. A review can also be useful when a growing product is starting to slow down its value creation. For example, when a scale-up is preparing for the next stage, when teams disagree about architectural direction, or when a technical investment needs to be justified with clearer evidence.

We use “legacy system” in a broad sense: a system that has become hard to change safely and predictably. It may still be business-critical, valuable, and actively used. In fact, many legacy systems are exactly that: systems that make money, but are difficult to evolve.

Can the review tell us if we are ready to benefit from generative AI?

Yes. Generative AI and agentic coding can act as accelerators: they can amplify what already works well, but they can also amplify existing weaknesses. An architecture review helps identify the conditions that make AI-assisted development more useful, such as clear boundaries, understandable code, fast feedback loops, and reliable tests.

Can the review help us decide whether to rewrite or modernise?

Yes. A common reason to do an architecture review is to understand whether a rewrite, gradual modernisation, extraction, team restructuring, or some smaller targeted intervention is the right next move.

We are very cautious about large rewrites unless the evidence clearly supports them. Often, the highest-leverage path is more focused than people expect. Even when a rewrite is needed, it should usually be surgical and incremental, not a full restart where everything is deleted and rebuilt from scratch.

Can a review be used as technical due diligence?

Yes. We have done many software architecture reviews where technical due diligence was part of the purpose. We have worked both with organisations considering an acquisition and with organisations preparing to be acquired.

For a company preparing for sale, an early review can reveal issues worth addressing before they become part of a buyer’s discount discussion. That can create value immediately, not only during the transaction itself.

What happens after the review?

That depends on what we find. Some clients use the review as input for internal planning. Others ask us to help with architecture modernisation, technical coaching, delivery improvement, or more detailed discovery in a specific area.

However, there is no obligation to continue with us afterwards. The review is designed to be valuable on its own.

How do we get started?

The first step is a conversation. You tell us what is happening, what worries you, and what decisions you need to make. From there we can decide whether an architecture review is the right format or whether another approach would be more useful.