Software architecture
Solution architecture
Solution architecture is the design of how applications, integrations, data and infrastructure fit together to solve one specific business problem.
Organizations produce a solution architecture when a business need cannot be met by one team changing one system. It is the plan that says which applications are involved, how they connect, where the data lives and what it runs on, so that several teams and vendors can build their parts and have them fit.
Why does solution architecture matter?
- It ties technology to a business outcome. Every element in the design traces back to a stated need, such as settling a claim within 48 hours, so scope is easier to defend and easier to cut.
- It makes integration explicit. Most delivery failures happen between systems, not inside them. Naming each integration up front puts those risks on the table.
- It coordinates teams. When four teams and two vendors share one picture, interfaces get agreed before code is written.
- It keeps the solution inside the standards. The design shows where it reuses enterprise platforms and where it needs an exception.
What are the layers of a solution architecture?
The diagram at the top of this page is a solution architecture for insurance claims processing, drawn as five bands. Read it from the top down.
- Business need. The outcomes the solution exists for. Here, settle an auto claim within 48 hours and cut manual review by 40 percent. Everything below has to serve one of these.
- Applications. The systems people use: a claims portal for customers, a workbench for adjusters, the claims management system that holds the process and a fraud scoring service. Some will be built and some bought.
- Integrations. How the applications talk: an API gateway in front of the portal and workbench, an adapter to the existing policy system and an event bus that carries claim events to fraud scoring and analytics.
- Data. What each application owns and where it lives: a claims database, a document store for photos and forms and an analytics warehouse fed from the event bus.
- Infrastructure. What it runs on: a managed PostgreSQL service, object storage, a warehouse service and a Kubernetes cluster, all in one cloud region across two availability zones.
The arrows between bands show direct dependencies. Each one is a contract between two teams, which is why the solution architect has to get them agreed.
How does it fit between enterprise and software architecture?
| Level | Scope | Horizon | Main question |
|---|---|---|---|
| Enterprise architecture | The whole organization | Three to five years | Which capabilities and platforms should we have? |
| Solution architecture | One business problem | One program, often 6 to 18 months | How do these systems fit together to solve it? |
| Software architecture | One system or service | Release to release | How is this system built inside? |
The enterprise architecture sets the constraints: approved platforms, data standards, security policies. The solution architecture works within them and hands each system a scope. The system architecture of each application is then designed by its own team through system design, often using named architecture patterns.
What are the deliverables of solution architecture?
- A solution overview. One or two pages on the business need, the scope and the approach.
- Architecture diagrams. A layered view like the one above, plus an architecture diagram per application where the detail matters. Many teams draw these with the C4 model, using a context diagram for the solution and a container diagram per system, and keep them as diagram as code.
- Integration specifications. For each arrow, the protocol, the payload, who owns it and what happens when it fails.
- Data ownership map. Which system is the source of truth for each kind of data.
- Non-functional requirements. Availability, latency, data residency, recovery targets and cost limits.
- Decision records. An architecture decision record for each significant choice, such as buy versus build or event bus versus direct calls.
How do you create a solution architecture?
- Start from the business need. Write the outcomes and how they will be measured. If a stakeholder cannot say what success looks like, stop here.
- Map the current state. List the systems already involved, what they own and how they connect today.
- Decide what changes. For each capability, choose to reuse, extend, buy or build, and note the reason.
- Design the integrations. Draw every connection between systems and settle the protocol and the owner for each.
- Assign the data. Give each kind of data one owning system, and show how copies get there.
- Choose the infrastructure. Map each component to where it runs, within the platforms the enterprise architecture allows.
- Review and record. Take the design through a design review, write the decisions down and keep the diagrams with the program documents.
What are common solution architecture mistakes?
- Starting from the technology. A solution built around a product the organization already licenses tends to solve the wrong problem well.
- Vague integrations. An arrow labeled “integrates with” hides the hardest work in the program.
- Two sources of truth. When two systems both own customer data, every later feature pays for it.
- Ignoring the current state. Designs that pretend the legacy systems are not there get rewritten at the first migration, and the gap becomes technical debt.
- Diagrams at one level of detail. A single picture that shows cloud instances next to business capabilities helps nobody. Draw the layers separately or use levels.
What does a solution architect do?
The solution architect owns the design end to end: gathering the requirements, making the design decisions, evaluating vendors, writing the deliverables above and staying with the program through delivery so the design survives contact with reality. The role sits between business stakeholders, enterprise architects and the delivery teams.
What tools help with solution architecture?
- Enterprise architecture repositories. Tools that model capabilities, applications and their relationships across the organization. Thorough, but heavy for one solution.
- Drag-and-drop diagramming tools. Fine for the first layered diagram, though each view is a separate drawing that drifts as the program changes.
- AI diagramming tools. Tools like Eraser turn a written solution design into an architecture diagram that you can keep editing as text, so the solution view and each system’s diagram stay consistent as the program moves.
For more on this kind of diagram, see architecture diagrams.
Frequently asked questions
-
What is the difference between solution architecture and enterprise architecture?
Enterprise architecture covers the whole organization: its capabilities, platforms and standards over several years. Solution architecture covers one business problem and the set of systems that solve it, usually over the life of one program. The enterprise architect sets the constraints, and the solution architect designs within them.
-
What is the difference between solution architecture and software architecture?
Software architecture is the internal structure of one system: its modules, services and data. Solution architecture is one level up, where several systems, some built and some bought, are combined to meet a business need. A solution architecture usually contains several software architectures and the integrations between them.
-
What does a solution architecture document include?
The business need and its success measures, the applications involved, the integrations between them, the data each one owns, the infrastructure they run on, the non-functional requirements and the main decisions with their trade-offs. Most of that fits on a few diagrams and a short document.
-
Who creates a solution architecture?
A solution architect, usually working with a business analyst for the requirements, the technical leads of the delivery teams for the detail and an enterprise architect for the standards. In smaller organizations a senior engineer or a technical lead takes the role without the title.
