What is solution architecture?
A short, practical answer to a question that gets asked a lot, and answered badly just as often.
The short version
Solution architecture is the discipline of working out how the pieces of a system, software, data, infrastructure and process, should fit together so a business idea actually works end to end, not just as a diagram or a pitch deck. It sits between the commercial problem a business has and the technical build that is meant to solve it, and its job is to translate faithfully between the two.
That sounds simple. In practice, most of what goes wrong in complex digital projects happens exactly at that translation step, not in the coding, and not in the strategy either.
Where it sits, and where it does not
Solution architecture is often confused with two neighbouring disciplines it overlaps but is not the same as. Enterprise architecture looks across an entire organisation's systems and standards over a long horizon, and is concerned with governance and consistency at scale. Software architecture concerns itself with a single system's internal structure: its services, its data model, its code.
Solution architecture sits between the two, and closer to a specific project: given this business problem, this timeline and this budget, how should the relevant systems, teams and processes connect so the thing actually works once it is live, not just once it is built. It borrows judgement from both the commercial side and the technical side, and belongs fully to neither.
What a solution architect actually does
Day to day, the work is less about diagrams than about decisions, and about who is accountable for the parts nobody wants to own. That usually means translating a business requirement that has not been fully articulated, often because it sits across several departments and incentives at once, into a specification a technical team can actually build against. It means mapping how new and existing systems need to exchange data, and where that exchange is fragile. It means choosing between technical approaches on cost, risk and maintainability grounds rather than novelty, and sequencing delivery so early decisions do not quietly foreclose options the business will need later.
It also means being explicit, early, about where a project needs specialist legal, security, compliance or clinical input, rather than proceeding on assumption. None of that is glamorous. Most of it is the difference between a project that survives contact with real usage and one that needs a second, more expensive rebuild eighteen months later.
A case for why it matters
My own background is in the Lloyd's and London insurance market, which is a good illustration of why this discipline earns its keep. Insurance products are distributed through layers of brokers, underwriters and delegated authorities, each with their own systems, regulatory obligations and appetite for risk. A digital platform built for that world without proper solution architecture tends to work perfectly in a demo and then fail quietly in production, because nobody mapped how a policy actually moves through six different parties before someone paid for it.
The same pattern shows up in less regulated industries too, just with lower stakes and more forgiving failure modes. Any business with more than one system, more than one team and a genuine deadline benefits from someone whose job is specifically to see how the parts connect, rather than assuming they will connect themselves because each part, on its own, is well built.
What good solution architecture looks like
It is boring, in the way that well run infrastructure is boring. Nobody notices it working; they notice its absence, usually about eighteen months in, as an unplanned rebuild.
It accounts for who owns each part of a system after launch, not just who builds it. It treats total cost of ownership as a real design constraint, not an afterthought priced in once the invoices start arriving. It documents the decisions that were made and, just as importantly, the ones that were deliberately deferred, so a team six months from now is not left guessing which gaps were intentional. And it survives contact with real usage, because it was built around how people and systems actually behave rather than how a requirements document assumed they would.
When a business actually needs one
A few reliable signals: several systems have been connected with workarounds rather than design, and everyone privately knows it. A rebuild keeps stalling because nobody can agree on scope, which is usually a sign nobody has properly mapped what the system needs to do. Technical debt is compounding faster than the team can pay it down. Or a business is trying to scale a process that was never designed to handle its current volume, let alone its next one.
None of those signals require enterprise scale to matter. They show up just as often in a ten-person specialist firm as in a global one; the specialist firm just has less slack to absorb the cost of getting it wrong.
The point of doing it properly
Solution architecture is not a layer of process added to slow a project down. Done well, it is what lets a complex idea move fast without quietly accumulating the kind of debt that shows up as a crisis later. That is the version of the discipline I practise: understand the business problem properly first, then design the technology to fit it, not the other way round.