Software architecture reviews
I help teams understand the structure of their software before making decisions that are difficult to reverse. An architecture review connects system boundaries and dependencies with product goals, team constraints and delivery risk. The result is a clearer basis for deciding what to keep, change or investigate.
01 / The starting point
When this helps
Consider a review when a product is becoming harder to extend, dependencies make changes unpredictable, or the team is weighing a significant technical decision. It is also useful before a new build when the proposed structure needs an independent challenge and the alternatives are not yet clear.
I examine the parts relevant to the decision: how responsibilities are divided, where components depend on each other and which assumptions shape the design. The review combines the current system with the way the team actually develops and operates it.
We compare possible changes through their consequences for complexity, ownership and future delivery. Recommendations are tied to the constraints we can establish, with uncertainties made explicit. The handoff can include an architecture map, a dependency review and a sequence of decisions or corrections.
Possible deliverables
- architecture map
- dependency review
- tradeoff framing
- handoff-ready direction
Share the decision you need to make, a description of the system and the problems the team encounters. Diagrams, repository context and examples of difficult changes are helpful. Existing documentation does not need to be complete: discrepancies between the diagram and the working system are useful evidence.
04 / Useful questions
Before choosing a route
Does an architecture review mean a rewrite?
No. The purpose is to understand the system and compare the available choices. Keeping the current structure, correcting a boundary or sequencing smaller changes can all be reasonable outcomes. A larger change needs a reason grounded in the product and delivery constraints.
How is this different from a technical audit?
Architecture work concentrates on structure, dependencies and design decisions. A technical audit can look more broadly at code, process, ownership and delivery. If the problem is not yet well defined, the initial discussion helps choose the more useful starting point.
Connected work
Related services
The next step is a conversation
Start with your context.
Share the goal, the obstacle, and what needs to move forward.