What a Solution Architect actually does

The real role of a Solution Architect

What the role actually involves: decisions, translation, and making things work within constraints.

The common thread across everything you do is decisions. You're making them, enabling them, or ensuring they're well-informed. On Monday you might be in a workshop with policy colleagues unpicking a regulatory requirement. By Thursday you're reviewing a vendor proposal and identifying the risks they've conveniently left out. The role is context-dependent in a way that few other technology roles are. In government specifically, every decision must be justifiable because you're spending public money, working within procurement frameworks, and expected to follow the Technology Code of Practice while delivering something that actually works for users.

Architecture is fundamentally about decisions — which ones to make, when to make them, and how to make them defensible.

How the role differs from other architecture disciplines

Where the Solution Architect sits relative to other architecture roles.

The Enterprise Architect defines that the department should adopt cloud-first; you figure out what that means for a specific service. The Technical Architect decides which message broker to use; you decided an event-driven pattern was needed in the first place. The confusion between these roles is real, especially in government where teams are small and one person often covers multiple. The key insight is that the Solution Architect is the integrator. You don't need to be the deepest expert in any single area, but you need to be competent across all of them and excellent at synthesising them into something coherent that actually gets delivered.

You're the person who sees how the enterprise strategy, the business process, the data model, the security requirements, and the technical implementation all connect — or fail to connect.

The four hats: translator, decision-maker, risk-manager, quality guardian

A mental model for how you split your time and attention across the role's four core responsibilities.

Most architects lean naturally towards one or two of these hats and neglect the others. The technically-minded architect makes good decisions but forgets to translate them for the programme board. The communicative architect translates brilliantly but avoids the hard risk conversations. The quality-focused architect holds high standards but creates bottlenecks by trying to review everything. Knowing which hat you're wearing at any given moment — and which one you're neglecting — is the difference between being effective and being busy.

Your job isn't to eliminate risk. It's to identify it, communicate it honestly, and ensure the right people accept it consciously.

What good architecture looks like in government

The six qualities that define good architecture in a public service context.

Good architecture in government is not the same as good architecture in a startup. A startup can afford to move fast and break things. You can't — you're handling citizens' data, spending taxpayers' money, and building services that people depend on for things like heating their homes or claiming benefits. The most common failure mode is over-engineering: building a microservices architecture for a service that has 200 users and processes 50 transactions a day. Proportionality is the quality that separates experienced government architects from those who've only worked in the private sector.

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

The Technology Code of Practice and Service Standard

The two documents that fundamentally shape how you work as an architect in UK government.

These aren't abstract policy documents you read once and forget. They're the lens through which your work will be judged at service assessments. When you choose to build custom rather than reuse an existing government component, you need to explain why. When you propose on-premises hosting, you need to justify it against Cloud First. The practical implication is simple: for every significant architecture decision, you should be able to articulate how it aligns with the TCoP. If you can't, either the decision is wrong or you haven't thought it through properly.

Common misconceptions about the role

The myths that trip up new architects and the reality behind each one.

The most damaging misconception is that architecture is a phase that ends when development starts. In reality, architecture is a continuous activity. The design changes as requirements evolve, as user research reveals new needs, as integration testing exposes assumptions that were wrong. An architect who hands over a document and walks away has done half the job. The other half is staying involved, adapting the design, and ensuring the thing that gets built actually resembles the thing that was designed — or is better, because you learned something along the way.

Architecture isn't a phase. It's a continuous activity that runs from discovery through to live operation.