The biggest mistake new architects make is treating every decision as a technical one. It's understandable — most of us came from technical roles where the right answer was determined by benchmarks, specifications, and best practices. But architecture doesn't work that way.
Most architecture decisions are actually about people, politics, and priorities. The technical dimension is often the simplest part.
The Decision That Looks Technical But Isn't
Here's a scenario I've seen play out dozens of times. A team needs to choose between building a custom integration and buying a commercial product. The architect produces a thorough technical comparison — features, performance, scalability, security posture, maintenance burden. The analysis clearly favours the custom build.
But the decision goes the other way. The commercial product wins.
Why? Because the decision was never really about technical merit. It was about:
- Risk appetite: The programme board would rather pay more for a product with a vendor behind it than accept the risk of maintaining custom code with a team that might change
- Timeline: The minister needs something demonstrable in three months, and the custom build would take six
- Skills: The operational team doesn't have the capability to maintain a custom integration long-term
- Commercial relationships: The department already has a contract with the vendor, and extending it is simpler than a new procurement
None of these factors appear in a technical comparison. But they're all legitimate considerations that shape the decision. The architect who only presents the technical analysis has done half the job.
What Architecture Decisions Are Really About
Architecture decisions sit at the intersection of multiple concerns:
- Technical feasibility: Can we build it? Will it work? Will it scale?
- Organisational capability: Can our team build and maintain it? Do we have the skills?
- Political context: Does this align with departmental strategy? Will it survive a change of minister?
- Financial reality: Can we afford it? Not just to build, but to run for five years?
- Time constraints: Can we deliver within the timeline that matters?
- Risk tolerance: How much uncertainty can the organisation accept?
A good architecture decision balances all of these. A purely technical decision ignores most of them.
The Architect's Real Job
This doesn't mean technical analysis doesn't matter — it absolutely does. But the architect's job isn't to find the technically optimal solution. It's to find the solution that best serves the organisation's needs given all the constraints.
Sometimes that means recommending a technically inferior option because it's more maintainable, more affordable, or more politically viable. And that's not a compromise — it's good architecture.
The key is honesty. When you recommend an option that isn't technically optimal, say so explicitly:
"Option B is not the strongest technical choice — Option A would give us better performance and more flexibility. But Option B can be delivered within our timeline, maintained by our current team, and doesn't require a new procurement. Given our constraints, I recommend Option B with a plan to revisit in 18 months."
That's an architecture decision. It's honest about trade-offs, grounded in context, and defensible to anyone who asks why.
How to Make Better Architecture Decisions
If you want to make better architecture decisions, stop thinking of yourself as a technical decision-maker and start thinking of yourself as a decision facilitator. Your job is to:
- Understand the full context — not just the technical requirements, but the organisational, political, and financial landscape
- Present options honestly — with trade-offs across all dimensions, not just technical ones
- Make your recommendation clear — and explain why, in terms your audience cares about
- Accept that the decision might go differently — and that's okay, as long as the decision-makers understood the trade-offs
- Document the decision and its context — so future teams understand not just what was decided, but why
The Uncomfortable Truth
The uncomfortable truth is that the best technical solution often isn't the right solution. And the architect who insists on technical purity at the expense of delivery, affordability, or organisational capability isn't being rigorous — they're being naive.
Architecture is the art of making good-enough decisions with incomplete information under real-world constraints. The sooner you accept that, the more effective you'll be.
The technical skills that made you a good developer are necessary but not sufficient for architecture. The additional skills — political awareness, stakeholder management, communication, pragmatism — are what make the difference between a competent architect and an excellent one.
And those skills? They're not taught in any certification programme. You learn them by doing the work, making mistakes, and paying attention to what actually drives decisions in your organisation.