Software architecture
Solution architect
A solution architect is the engineer who designs how applications, data and infrastructure combine to solve one business problem and guides its delivery.
Organizations hire solution architects when a business need spans several systems, teams and vendors, and nobody owns the whole picture. The architect is the person accountable for the solution architecture: that the parts fit together, that they meet the need and that they get built the way they were designed.
What does a solution architect do?
- Turns a business need into a technical design. Takes goals, budget and constraints from stakeholders and produces a design that meets them, with the trade-offs made explicit.
- Decides what to reuse, buy or build. Evaluates vendors and platforms, writes the comparison and makes the recommendation.
- Designs the integrations. Defines how the systems in the solution talk, who owns each interface and what happens when one fails.
- Records the decisions. Writes an architecture decision record for each significant choice so the reasoning outlives the meeting.
- Guides delivery. Reviews designs and code at the risky points, answers the questions the design did not anticipate and tracks the technical debt the program takes on deliberately.
- Hands over to operations. Makes sure the solution arrives with runbooks, service levels and monitoring, not just features.
What does a solution architect own?
The diagram at the top of this page maps the role. The architect sits in the middle because the job is to connect things that would otherwise not connect.
Inputs come from the top and left. Business stakeholders supply goals, budget and constraints. Security and compliance supply the policies the design must satisfy. Enterprise architecture supplies standards and reference designs that limit the choices. Requirements, functional and non-functional, arrive from analysts and product owners.
Outputs go to the right and bottom. Vendors and platforms get evaluations and requests for proposal. Architecture decisions get written down. Operations get runbooks and service level objectives. Delivery teams get design documents, architecture diagrams and reviews. The architect owns everything on the output side and is accountable for turning the inputs into them.
What skills does a solution architect need?
- Breadth across the stack. Enough depth in applications, data, networking, security and cloud infrastructure to design across all of them and to know when to bring in a specialist.
- Integration design. APIs, messaging, event-driven patterns, batch transfers and the failure modes of each. Most of the hard problems in a solution live here.
- Knowledge of the patterns. The standard architecture patterns and when each one fits, so the design draws on known shapes rather than inventing new ones.
- Estimation and costing. Sizing infrastructure, pricing cloud services and licenses and explaining the result to someone who owns a budget.
- Writing and diagramming. The design only exists in the documents and diagrams that other people read. Clear ones are the main tool of the role.
- Negotiation. Reconciling what stakeholders want, what the standards allow and what the teams can build in the time available.
How does a solution architect differ from other roles?
| Role | Scope | Horizon | Main output |
|---|---|---|---|
| Enterprise architect | The whole organization’s capabilities, platforms and standards | Years | Target architectures, standards, roadmaps |
| Solution architect | One business problem and the systems that solve it | A program, often 6 to 18 months | A solution architecture and its decisions |
| Software architect | One system or product and its internal structure | The life of the product | A system architecture and its patterns |
| Technical lead | One team and its codebase | Sprint to sprint | Working software, code reviews, technical direction for the team |
The enterprise architect sets the rules the solution architect designs within. The software architect and technical lead do the system design of the individual systems the solution architect combines. On a small program one person may hold two of these roles. On a large one they are separate people who talk every day.
What does a day in the role look like?
A representative day on a claims processing program. In the morning the architect reviews the API contract the portal team drafted for the claims management system, pushes back on a field that would duplicate policy data and agrees on a change. Mid-morning is a vendor call to settle how the fraud scoring service will receive claim events, followed by updating the integration diagram and the open questions list.
After lunch, a design review for the adjuster workbench, where the architect’s job is to check the design against the solution’s data ownership rules rather than to design it. Then an hour writing an architecture decision record on why the event bus was chosen over direct calls, which has already been asked about twice. The day ends with a stakeholder update: what changed, what it costs, what decisions are needed from them.
What is the career path for a solution architect?
Most solution architects start as software engineers, move into a technical lead or senior engineer role where they design systems and own integrations, then step up to solution architecture when they start working across teams. From there, the common next steps are enterprise architect (breadth across the organization instead of depth on one program), head of architecture (managing other architects) or principal engineer (deep technical work with organization-wide influence). Some move into product or engineering management, since the role already involves much of the stakeholder work.
What tools does a solution architect use?
- Document and wiki tools. The design, the decisions and the open questions live in documents that the whole program can read and comment on.
- Diagram-as-code tools. Keeping diagrams as text alongside the design document means they are reviewed and versioned with it. See diagram as code.
- AI diagramming tools. Tools like Eraser turn a written design into an architecture diagram you can keep editing, which suits a role that redraws the same solution for several audiences, often at the C4 model levels, as the program moves.
For more on this kind of diagram, see architecture diagrams.
Frequently asked questions
-
Is a solution architect a technical role?
Yes. A solution architect has to read code, judge a vendor's API, size a database and spot a flawed integration, and most come from senior engineering roles. The job adds business and communication work on top of that technical base. It does not replace it.
-
Does a solution architect write code?
Usually not as a main duty, but the best ones keep their hands in. Prototyping an integration, reviewing pull requests on the riskiest component or writing a proof of concept for a vendor evaluation keeps the architect honest about what the design costs to build.
-
What certifications do solution architects have?
The common ones are the cloud providers' architect certifications and TOGAF for enterprise architecture methods. They help with hiring filters and with vendor conversations. They matter less than a track record of solutions that shipped on time and ran well in production.
-
How many solutions does a solution architect work on at once?
Typically one large program or two or three smaller ones. The role only works if the architect is close enough to delivery to notice when the design and the code diverge, and that stops being possible beyond a few concurrent programs.
