Understanding the problem before designing the solution

The danger of premature solutioning

Why architects jump to design before they understand the problem, and what disciplined thinking looks like instead.

Premature solutioning is the occupational hazard of technically capable people. You hear a problem and your brain immediately starts designing. It feels productive. It feels like expertise. But it's often the moment where the most expensive mistakes get locked in. In government, the consequences are amplified: a solution designed for the wrong problem doesn't just waste a sprint, it wastes months of procurement, governance approvals, and delivery effort. The pattern is predictable. Someone describes a symptom. The architect hears a technology. Within minutes there's a whiteboard sketch of a system that solves something nobody actually asked for. The discipline is to notice that impulse, pause, and ask: do I actually understand what's going wrong here, or am I just pattern-matching to something I already know how to build?

The most valuable thing you bring as an architect is the discipline to hold the space for problem understanding when everyone around you wants to start building.

Problem framing techniques that actually work

Repeatable methods for clarifying the real need before any solution is chosen.

Problem framing is the practice of defining what you're actually trying to solve before you let yourself think about how to solve it. It sounds obvious, but in practice it's the step most often skipped. A good problem frame answers three questions: who is affected, what is going wrong for them, and what would better look like? It deliberately excludes technology. The techniques that work in government are simple and repeatable. Problem statements force you to articulate the issue in one or two sentences without mentioning a solution. "How might we" questions open the solution space rather than narrowing it prematurely. Context maps show you who else is involved and what constraints exist. The value isn't in the artefact you produce; it's in the thinking the technique forces you to do. A well-framed problem makes the architecture work easier because you know what success looks like before you start designing.

A good problem statement shifts the conversation from 'build us this' to 'help us achieve this'. The solution space gets wider, and that's exactly what you want.

Discovery in government: what it is and why architects must engage

What discovery looks like in practice, and how the architect contributes without designing too soon.

Discovery is the phase where you learn about the problem space before committing to a solution. In government, it's a formal part of the service design process, but architects often treat it as something that happens before they get involved. That's a mistake. Discovery is where you learn the things that will constrain and shape your architecture: who the users are, what the existing landscape looks like, what policy obligations apply, what's been tried before and why it failed. The architect's role in discovery isn't to design. It's to listen, ask questions, map the technical landscape, identify constraints, and start forming a mental model of the problem that will eventually inform the architecture. If you skip discovery, or join only at the end, you'll design based on assumptions rather than evidence. And assumptions in government architecture tend to be expensive when they turn out to be wrong.

Discovery is where you earn the right to design well. Skip it, and you'll pay for it later in rework and regret.

Understanding policy intent: the hidden driver

How policy purpose shapes architecture decisions, and how architects translate between policy and technical worlds.

Every government service exists to deliver a policy outcome. The policy intent is the reason the service exists, and it shapes architecture decisions in ways that aren't always visible. A policy that requires discretionary decision-making needs different architecture from one that applies fixed rules. A policy that's likely to change annually needs a system that can be reconfigured without rebuilding. A policy with strict eligibility criteria needs robust data validation; one with flexible criteria needs human judgement supported by good information. The architect who understands policy intent can design systems that serve it well and adapt as it evolves. The architect who ignores it builds systems that work technically but fight the policy at every turn. The practical skill is translation: understanding what the policy is trying to achieve, and working out what that means for data, workflow, integration, and user experience. You don't need to become a policy expert, but you do need to ask the right questions and listen carefully to the answers.

Architecture that fits today's policy but can't survive tomorrow's is architecture you'll be replacing before it's paid for itself.

The real problem vs the stated problem

Why the stated request is rarely the real issue, and how good architects find what actually needs fixing.

The problem you're asked to solve is almost never the actual problem. A team says they need a new database; the real problem is that reporting takes three days because data is scattered across five systems. A programme board says they need a platform migration; the real problem is that the support contract expires in six months and nobody renewed it. A product owner says they need an API; the real problem is that two teams can't share data because of an organisational boundary. The stated problem is usually a symptom, or a solution someone has already decided on. The architect's job is to keep asking "why" until you reach the thing that actually needs fixing. This isn't about being difficult or contrarian. It's about making sure the organisation spends its money and effort on the right thing. The technique is simple: when someone tells you what they want built, ask what problem it solves. Then ask what causes that problem. Keep going until you find something that, if fixed, would make the original request unnecessary.

The best architects save their organisation from expensive solutions to cheap problems. Nobody thanks you for it, but it's the work.

Structured approaches to problem analysis

Four thinking frameworks that help you analyse problems systematically without producing bureaucratic documents.

Structured problem analysis doesn't mean producing heavyweight documents. It means thinking systematically rather than jumping to the first idea that feels right. Four approaches work well in practice. Root cause analysis helps you trace symptoms back to their source, so you solve the cause rather than treating the effect. Stakeholder impact mapping shows you who is affected and how, so your solution addresses the right needs. Constraint identification surfaces the boundaries you'll have to work within, before you design something that ignores them. And assumption testing forces you to name the things you're taking for granted, so you can validate them before they become expensive mistakes. None of these need to produce formal deliverables. They're thinking tools, not documentation exercises. Use them in a conversation, on a whiteboard, or in your own notes. The value is in the rigour of thought, not the polish of the output.

Use these to structure your thinking and challenge your assumptions, not to produce impressive looking documents.

When discovery goes wrong: patterns of failure

The traps that distort discovery, and how mature architects spot them and reset course early.

Discovery fails in predictable ways. Confirmation bias is the most common: the team enters discovery having already decided what they want to build, and unconsciously filters evidence to support that conclusion. Scope creep is another: discovery expands endlessly because nobody defined what "enough understanding" looks like. Authority bias distorts findings when a senior stakeholder's opinion carries more weight than user research. And theatre discovery produces the right artefacts without doing the real thinking, ticking boxes for governance without generating genuine insight. The architect's role is to notice these patterns and name them. You don't need to run discovery yourself, but you do need to be honest about whether the discovery that's been done is actually good enough to design from. If the problem statement is vague, if the user needs are assumed rather than researched, if the constraints haven't been tested, then you're not ready to design, regardless of what the project plan says.

Every architect falls into these traps occasionally. The good ones notice quickly and reset.

From problem understanding to architecture readiness

The bridge between discovery and design, and the questions that tell you when you're ready to start designing.

There's a moment between understanding the problem and starting to design where you need to make a judgement call: do I know enough? The answer is never "everything," but it needs to be "enough." Enough means you can articulate the problem clearly without referencing a solution. You know who the users are and what they need. You understand the policy intent and how it might change. You've mapped the existing landscape and know what you're integrating with. You've identified the hard constraints and validated your key assumptions. You know what success looks like and how it will be measured. If you can answer these questions with confidence, you're ready to design. If you can't, you need more discovery, not more architecture. The bridge between problem understanding and design isn't a formal gate or a sign-off meeting. It's a professional judgement that you, as the architect, are responsible for making honestly.

Good architecture doesn't start when all uncertainty disappears. It starts when uncertainty has been reduced enough to make reasonable decisions, and to adapt as you learn more.