What a Solution Architect actually does

The real role of a Solution Architect

Strip away the padding from the job description and the role comes down to one thing. You make sure a specific solution, whether that is a system, a service, or a set of integrated components, is fit for purpose, technically sound, deliverable, and aligned with everything around it. You are the bridge between what the organisation needs and what technology can realistically build. That sounds simple. It is not.

The job shifts with context more than almost any other role in technology. What you do on Monday in a discovery workshop looks nothing like what you do on Thursday in a live service review. A single week might include:

• Running a session with policy colleagues to understand a new regulatory requirement
• Reviewing a proposed API design and pushing back on complexity the team does not need
• 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, turning technical trade offs into business language
• Reading a vendor proposal and spotting the risks they quietly left out
• Sitting in a stand up to unblock a technical dependency
• Updating the solution architecture document after a change in scope

The thread running through all of it is decisions. You are making them, enabling them, or making sure they are well informed. The significant ones, the choices that are expensive or painful to undo later, are yours to own. In UK government that work carries extra weight. You are spending public money, so every choice has to be justifiable. You sit inside procurement frameworks that limit your options, between policy teams who may not follow the technology and delivery teams who may not follow the policy. And you are expected to meet the Technology Code of Practice and the Service Standard while still shipping something that genuinely works for users.

Architecture is about decisions. Which ones to make, when to make them, and how to make them defensible.

How the role differs from other architecture disciplines

Confusion between architecture roles is common, and in government it is worse, because teams are small and one person often wears several of these labels at once. It pays to be precise about who does what.

The enterprise architect works at the level of the whole organisation: strategy, standards, principles, roadmaps. They might decide the department should be cloud first. You work out what that means for one specific service. The technical architect goes deep on implementation. Where you decide an event driven integration pattern is the right approach, they pick the message broker and tune it. In many government teams that line is blurred, and that is fine, as long as someone owns both the strategic and the tactical view.

The business architect maps capabilities, processes, and how the organisation is structured. You need to understand their work, because you cannot design a sound solution without the business context, but they own the business model and you own the solution design. The data architect owns data models, flows, governance, and quality. In government, where data sharing across departments is both vital and politically charged, their decisions shape what you can and cannot do.

Notice the pattern. You are not the deepest specialist in any one of these areas, and you do not need to be. You are the integrator. Your value is seeing how the strategy, the process, the data, the security, and the implementation fit together, and naming the places where they do not.

The four hats you wear

On any given day you are wearing at least one of four hats, often more than one at the same time. Most architects lean naturally towards one or two of them and quietly neglect the rest.

As translator you move between worlds. Policy talks in outcomes and legislation, delivery in sprints and story points, security in threats and controls, commercial in contracts and service levels, leadership in risk and value. Your job is to get these groups understanding each other well enough to decide together, which means finding the right level of abstraction for each one rather than dumbing anything down.

As decision maker you choose between options, accept trade offs, and set constraints. Good architects make those decisions explicit and write them down. Poor architects make them by accident, forget them, and later wonder how the system ended up the way it did.

As risk manager you deal with the fact that every decision carries risk. New technology brings adoption risk, old technology brings obsolescence risk, building brings maintenance risk, buying brings lock in. You will not eliminate any of it, so the work is to name it, size it where you can, and make sure the right people accept it with their eyes open.

As quality guardian you hold the line on what good enough means. Not as a gatekeeper who blocks everything, which only breeds resentment, but as the person who pushes back when a team wants to cut corners on performance, security and resilience, or when a vendor claims their product does everything, or when delivery pressure turns documentation into a someday job. It takes courage and tact in roughly equal measure.

What good architecture looks like in government

Good architecture in government is not the same animal as good architecture in a startup or a bank. A startup can move fast and break things. You cannot, because the things break on citizens. You are handling people's data and building services they rely on to heat their homes, claim what they are owed, or prove who they are.

So the first quality is that it serves users. The Service Standard exists for a reason. However elegant the technical design, if it does not enable a service that meets a real user need, simply and reliably, it has failed.

The second, and the one that most separates experienced government architects from newcomers, is proportionality. Government services run from a single form that collects some data to platforms spanning several departments and moving millions of transactions. Good architecture matches the weight of the solution to the weight of the problem. Building a microservices estate for a service with two hundred users and fifty transactions a day is as much a failure as under building the critical one.

The rest follows from those two. Good government architecture is honest about its trade offs and makes sure the right people have accepted them. It works within real constraints rather than wishing them away, and government has plenty: procurement rules, security classifications, accessibility duties, Welsh language obligations, dependencies on other departments, ministerial priorities. It can be operated and evolved by whoever inherits it, because in government people move, contracts end, and the team in two years will not be the team today. And it fits the wider estate, reusing the cross government building blocks like GOV.UK Notify, GOV.UK Pay and GOV.UK One Login rather than rebuilding them badly.

Good government architecture is proportionate. It matches the weight of the solution to the weight of the problem.

The Technology Code of Practice and Service Standard

Two documents shape how you work more than any others. The Technology Code of Practice sets twelve principles for government technology: start with user needs, make things accessible, default to open, use cloud, build in security, design for integration, treat data as a shared asset, reuse before you build. The Service Standard sets fourteen points that any public facing service has to meet at each assessment.

Treat neither as policy you read once and file away. They are the lens your work gets judged through at assessment. Choose to build custom instead of reusing a government component and you will need to explain why. Propose hosting it in your own data centre and you will need to justify that against Cloud First. The practical test is simple. For every significant decision you make, you should be able to say how it lines up with the Code of Practice. If you cannot, either the decision is wrong or you have not finished thinking it through.

Common misconceptions about the role

A few myths trip up new architects, and they are worth naming plainly.

"The architect is just a senior developer who draws diagrams."

Technical depth helps, but the role lives in decision making, communication, and synthesis. A brilliant coder who cannot explain a choice to a stakeholder from outside the technical team will struggle in the chair.

"The architect designs the solution and hands it over."

Architecture has no end date. The design keeps moving as requirements evolve and as reality intrudes on the plan, and you move with it.

"The architect has the final say on everything technical."

You own the significant, hard to reverse decisions. The day to day technical calls belong to the team. Try to control all of it and you become the bottleneck everyone routes around.

"Architecture is mostly about choosing technologies."

Technology selection is a small slice of it. The larger part is understanding the problem, setting the approach, and managing the trade offs so the whole thing holds together.

"You need to know everything."

You do not. You need to know enough to ask the right questions, recognise a good answer, and tell when it is time to bring in a specialist. Some of the most credible architects are the ones comfortable saying they want the security lead in the room before they commit.

What separates competent from excellent

A competent architect designs a solution that works. An excellent one does a few things beyond that.

They anticipate, asking what happens when this scales before the scaling problem arrives, and what happens when this vendor folds before the contract is signed. They simplify, because anyone can design something complicated and it takes real skill to design something simple that still meets every requirement. They communicate, explaining the same architecture to a minister in two minutes and a developer in two hours, and writing documents people actually read. And they build trust slowly, by being honest about what they know and do not know, admitting when they are wrong, and pushing back firmly but well when they watch a bad decision forming.

Underneath all of it sits one habit. Excellent architects care about outcomes rather than outputs. They do not count the documents they produced or the diagrams they drew. They look at whether the service works for the people using it, whether the team can keep it running, and whether the public got value for the money spent.

Success is whether the service works, whether the team can run it, and whether the public got value for money. The documents and diagrams are only the means.