How architecture thinking differs from technical thinking

The single biggest transition a technologist makes when becoming a Solution Architect is the move from technical thinking to architecture thinking. They're not the same, and confusing them is the root cause of most architecture failures in government.

The difference between technical problems and architecture decisions

How to recognise when you've crossed the line from a technical problem into an architecture decision.

Most architecture failures don't start as bad architecture decisions. They start as technical decisions that should have been architecture decisions, made by people who didn't realise the difference. A senior developer picks a database engine in a sprint planning meeting; two years later, it's the reason a service can't scale. The choice wasn't wrong because of the technology - it was wrong because nobody asked who else would be affected, how reversible it was, or what trade-offs they were accepting. In government the blast radius makes this worse: an architecture decision can ripple across procurement, operations, security, skills and potentially multiple departments. The discipline is to slow down, notice when a question is crossing that line, and treat the moment with the weight it deserves.

Treat architecture decisions like technical problems and you'll keep looking for the 'right' answer. The job is to understand the trade-offs and make a defensible choice.

Systems thinking: seeing the whole, not just the parts

Why architecture lives in the interactions between parts, not just the parts themselves.

Technical thinking is reductionist for good reason - you can't write code without breaking the problem into pieces small enough to hold in your head. That habit is brilliant for building and dangerous for architecting. A government service isn't just software; it's a socio-technical system of users, caseworkers, operations teams, policy intent, legacy integrations and live operational practice. A technically perfect solution that doesn't fit how the operations team actually works will fail in service. A beautifully decomposed architecture that ignores a data-sharing agreement with another department will fail at legal review. The practical discipline is to zoom out before you zoom in: understand the whole system, see the connections, then dive into the detail with that context in mind.

A system's behaviour emerges from the interactions between its parts, not just from the parts themselves.

Context awareness: the architect's superpower

The organisational, political, commercial and delivery context that shapes every real architecture decision.

A developer can write excellent code without knowing who the minister is. An architect cannot design an excellent solution without understanding the environment around the work. In government this isn't optional colouring-in - it's the thing that determines whether your design ever sees daylight. A ministerial announcement at a conference can create an immovable deadline. An existing G-Cloud contract can rule out half your technology shortlist before you've written a line. A team's lack of Kubernetes experience can turn a clever design into an operational risk. Architects who ignore context produce solutions that are technically elegant but organisationally impossible. Architects who read the environment first produce solutions that actually get approved, funded, built and used.

Context awareness turns technically good ideas into solutions that can actually be delivered.

Architectural judgement: choosing the right trade-offs

Good architecture isn't about perfect choices; it's about balancing benefits, risks, constraints and outcomes.

Technical thinking searches for optimal solutions. Architecture thinking accepts that there isn't one - only trade-offs. Simplicity costs flexibility. Speed costs quality. Resilience costs money. Stronger security degrades usability. Custom builds give you control but eat time; off-the-shelf gives you speed but limits your options. Every architecture decision improves some things and constrains others, and the job is to make those trade-offs consciously, explicitly, and with the right people in the room. In government the consequences of poor trade-offs are borne by the public - trade away accessibility for speed and real people can't use the service; trade away security for cost and real people's data is at risk. A useful test: for every significant decision, write down what you're gaining and what you're giving up. If you can't articulate the trade-off, you don't understand the decision well enough to make it.

Good architects don't chase perfect solutions. They make the best decisions for the context they're in.

Abstraction: knowing what level of detail matters when

Moving deliberately between strategic, solution and component levels - and knowing which one each conversation needs.

Technical people love detail. Specific frameworks, exact configurations, precise versions - the more specificity the better. That instinct is valuable on a development team and counterproductive in a programme board. A deputy director doesn't need to know you've chosen PostgreSQL; they need to know the data is stored securely, the service is resilient and the costs are predictable. A developer doesn't need to know about ministerial priority; they need the API contract and the deployment pipeline. The mistake new architects make is jumping to the component level too early - talking about Kubernetes before anyone's agreed what the service even does. It's like choosing the paint colour before deciding how many rooms the house needs. The discipline is to match your level of abstraction to your audience and the decision being made, and go deeper only when the decision genuinely requires it.

The mistake isn't using detail. It's using the wrong level of detail at the wrong time.

Time horizon: designing for now, next and later

Balancing immediate delivery pressure with medium-term adaptability and long-term strategic direction.

Political cycles create pressure to deliver Now. But government services often run for decades - the tax system, the benefits system, the immigration system. An architecture decision made under delivery pressure today will be lived with for years, by teams who weren't in the room when you made it. The challenge is balancing three horizons at once: deliver enough for Now (0–6 months), design enough flexibility for Next (6–18 months), and keep enough options open for Later (18+ months). Design only for Now and you'll build something that works today but can't evolve. Design only for Later and you'll over-engineer something that never gets delivered. The practical approach is to design for the current phase's requirements but make your decisions reversible where possible - use interfaces and abstractions that let you swap components later, and document the assumptions that underpin today's design so future architects know what might need to change.

Good architects don't design only for today. They deliver for Now, design for Next and keep options open for Later.

Constraint awareness: working within real boundaries

The budget, skills, legacy, policy, procurement and time constraints that make government architecture real.

Technical thinking starts with 'what's possible?' Architecture thinking starts with 'what's possible within these constraints?' In government the constraints are real and largely non-negotiable. Budgets are fixed and often annual. The team you have is the team you have. Legacy systems can't be wished away. Policy obligations like data residency, accessibility and Welsh language are legal requirements, not preferences. Procurement frameworks determine what you can buy and how quickly. Delivery timelines are often politically driven and immovable. The architect who ignores these constraints designs fantasy architectures that are beautiful on paper and impossible in practice. The architect who embraces them designs solutions that actually get built. Constraints aren't the enemy of good architecture - if there were no constraints, you wouldn't need an architect.

Constraints are the context that makes architecture necessary.

Pattern recognition and the danger of technology-first thinking

Why experienced architects start with the problem, not with their favourite technology.

Experienced architects develop pattern recognition - the ability to spot a recurring problem and match it to a proven approach. It's valuable, and it's also the thing most likely to lead you astray. The trap is technology-first thinking: starting with a technology or pattern you like and finding a problem to apply it to. 'We should use microservices' is technology-first. 'We have a large team that needs to deploy components independently, so a decomposed architecture makes sense' is architecture thinking. The first sentence sounds productive but isn't. The second is harder to arrive at, and it's the one that produces good systems. A useful test: can you justify your decision without naming a specific product? If you can say 'we need an asynchronous integration pattern because the upstream system has unpredictable response times,' you're thinking architecturally. If all you can say is 'we should use Kafka,' you're not. In government this discipline ties directly to the Technology Code of Practice - share and reuse before you build new - and to the simple fact that public money pays for every line of unnecessary complexity.

Good architects don't start with their favourite technology. They start with the problem and choose the simplest pattern that fits.