What a Solution Architect Actually Does

The Real Role of a Solution Architect

Let's start with what a Solution Architect actually does, stripped of the corporate language and job-description padding.

A Solution Architect is the person responsible for ensuring that a specific solution — a system, service, or set of integrated components — is fit for purpose, technically sound, deliverable, and aligned with the wider organisational landscape. You are the bridge between what the organisation needs and what technology can realistically deliver.

That sounds simple. It isn't.

In practice, the SA role is one of the most context-dependent roles in technology. What you do on Monday in a discovery phase looks nothing like what you do on Thursday in a live service review. Your day might include:

• Running a workshop with policy colleagues to understand a new regulatory requirement
• Reviewing a development team's proposed API design and pushing back on unnecessary complexity
• Writing an Architecture Decision Record explaining why you chose a managed service over a custom build
• Presenting a solution options paper to a programme board, translating technical trade-offs into business language
• Reviewing a vendor's proposal and identifying the risks they've conveniently omitted
• Sitting in a stand-up with the delivery team, unblocking a technical dependency
• Updating the solution architecture document to reflect a change in scope

The common thread? You're making decisions, enabling decisions, or ensuring decisions are well-informed. Architecture is fundamentally about decisions — which ones to make, when to make them, and how to make them defensible.

In UK government specifically, the SA operates within a unique set of constraints. You're working with public money, which means every decision must be justifiable. You're working within procurement frameworks that limit your choices. You're working alongside policy teams who may not understand technology, and technology teams who may not understand policy. You're expected to follow the Technology Code of Practice, meet the Service Standard, and align with departmental strategies — all while delivering something that actually works for users.

How the SA Role Differs from Other Architecture Disciplines

One of the most common sources of confusion — especially in government — is the overlap between architecture roles. Let's be precise about the differences.

Enterprise Architect (EA): The EA works at the organisational level. They're concerned with the overall technology landscape, strategic direction, standards, and principles. They think in terms of capabilities, roadmaps, and portfolios. An EA might define that the department should adopt a cloud-first approach; the SA figures out what that means for a specific service.

Technical Architect (TA): The TA goes deep on implementation. They're concerned with code quality, framework choices, deployment pipelines, and technical standards. Where the SA decides 'we need an event-driven integration pattern here,' the TA decides which message broker to use and how to configure it.

Business Architect (BA): The BA maps business capabilities, processes, and organisational structures. The SA needs to understand business architecture — you can't design a good solution without understanding the business context — but the BA owns the business model while the SA owns the solution design.

Data Architect: The Data Architect focuses on data models, data flows, data governance, and data quality. In government, where data sharing across departments is both critical and politically sensitive, the Data Architect's work directly shapes what the SA can and cannot do.

The key insight: the Solution Architect is the integrator. You don't need to be the deepest expert in any one area, but you need to be competent across all of them and excellent at synthesising them into a coherent solution.

The SA as Translator, Decision-Maker, Risk-Manager and Quality Guardian

The SA wears four hats, often simultaneously. Understanding these hats helps you prioritise your time and energy.

Translator: You translate between worlds. Policy colleagues speak in outcomes and legislation. Delivery teams speak in sprints and story points. Security teams speak in threats and controls. Your job is to ensure these groups understand each other well enough to make good decisions together.

Decision-Maker: Architecture is decision-making. Every day you're choosing between options, accepting trade-offs, and setting constraints. Good architects make decisions explicit, document them, and revisit them when the context changes.

Risk-Manager: Every architecture decision carries risk. Your job isn't to eliminate risk — that's impossible — but to identify it, quantify it where you can, communicate it honestly, and ensure the right people accept it consciously.

Quality Guardian: You're the last line of defence against poor design. Not in a gatekeeping sense, but in the sense that you hold the standard for what 'good enough' looks like. This requires courage and diplomacy in equal measure.

What 'Good Architecture' Looks Like in Government

Good architecture in government isn't the same as good architecture in a startup or a bank. The context shapes what 'good' means.

In government, good architecture:

• Serves users first. If your architecture doesn't enable a service that meets user needs simply and effectively, it's failed regardless of how elegant the technical design is.
• Is proportionate. Good architecture matches the complexity of the solution to the complexity of the problem.
• Is honest about trade-offs. Every architecture involves compromises. Good architecture makes those compromises explicit.
• Works within constraints. Government has constraints that the private sector doesn't: procurement rules, security classifications, accessibility requirements, Welsh language obligations.
• Is maintainable by the team that inherits it. In government, teams change. Good architecture can be understood, operated, and evolved by people who weren't involved in the original design.
• Aligns with the wider landscape. No government service exists in isolation. Good architecture considers how the solution fits with departmental platforms and cross-government services.

The Technology Code of Practice and Service Standard

Two documents fundamentally shape how Solution Architects work in UK government.

The Technology Code of Practice (TCoP) sets out 12 principles that government technology must follow. Key principles include:

• Define user needs — start with what users need, not what technology can do
• Make things accessible and inclusive — design for everyone
• Be open and use open source — default to open standards and open source
• Make use of cloud — Cloud First policy means you need good reasons not to use cloud
• Make things secure — security is a design concern, not an afterthought
• Integrate and adapt technology — don't build monoliths; design for integration
• Share and reuse technology — look for existing solutions before building new ones

The Service Standard applies to all public-facing digital services. It sets 14 points that services must meet at each assessment stage. As an SA, you're directly responsible for several of these.

The practical implication: when you make an architecture decision, you should be able to explain how it aligns with the TCoP and supports the Service Standard.

What Makes the Difference Between Competent and Excellent

A competent SA can design a solution that works. An excellent SA does something more.

• Excellent SAs anticipate. They see problems before they arrive. They ask 'what happens when this scales?' before the scaling problem hits.
• Excellent SAs simplify. Anyone can design a complex solution. It takes real skill to design a simple one that still meets all the requirements.
• Excellent SAs communicate. They can explain a complex architecture to a minister in two minutes and to a developer in two hours.
• Excellent SAs build trust. They're honest about what they know and don't know. They push back respectfully but firmly when they see a bad decision being made.
• Excellent SAs learn continuously. Technology changes. Government priorities change. The best architects stay curious and learn from every project.
• Excellent SAs care about outcomes, not outputs. They measure success by whether the service works for users, not by the number of documents produced.