Why the hardest problem in enterprise architecture isn’t technical at all
There’s a quiet truth most enterprise architects learn the hard way, usually a few years into a transformation programme that should have worked but didn’t. The technology was sound. The diagrams were clean. The platform choices were defensible. And yet the value never arrived.
When that happens, we reach for the familiar explanations. The integration was harder than expected. The data wasn’t ready. The cloud migration slipped. These are comfortable answers because they keep the problem inside the domain we understand: systems, interfaces, code. They let us stay engineers.
But after enough of these programmes, you start to notice that the systems were rarely the thing that broke. People were. Or more precisely: the decisions people made under pressure were. The most expensive architectural failures I’ve seen weren’t failures of technology. They were failures of human behaviour that quietly hardened into the architecture and stayed there for a decade.
This is the part of the job almost nobody writes about. So let me. And let me start by being honest about something: when people first talk about the human side of architecture, they usually mean fear resistance to change, anxiety about risk. Fear is real, and I’ll spend time on it. But it’s only one of the forces, and treating it as the whole story is its own kind of blindness. Human behaviour in an enterprise is shaped by at least four distinct forces, and each one leaves a different fingerprint on the architecture: fear, incentives, politics, and ego. They are not the same thing, they don’t respond to the same intervention, and an architect who can only see one of them will keep being ambushed by the other three.
The technology is not the problem
Let me start with the claim that frames everything else: in most large organisations, the limiting factor in transformation is not the technology stack. It’s the behaviour around it.
I don’t say this to be provocative for its own sake. I say it because it matches what the evidence keeps showing, across bodies of research that rarely agree on much else. McKinsey’s long-running work on digital transformation has for years put the success rate uncomfortably low by their accounting, only a minority of transformations deliver and sustain the value they set out to capture. BCG’s transformation studies land in similar territory, with roughly three-quarters of programmes falling short of their ambitions. The precise figure shifts depending on who is counting and how they define success, but the order of magnitude is consistent and sobering.
The striking part, though, is not the failure rate itself. It’s the recurring finding underneath it. When these programmes are dissected and the change-management literature is the place to look here, particularly Prosci’s benchmarking work and Gartner’s research on why transformations stall the dominant causes of failure cluster around organisational and human factors. Leadership misalignment. Employee resistance. Unclear ownership. Misaligned incentives. Politics. Prosci’s people-side findings are especially blunt on this point: effective change management of the human transition is one of the strongest predictors of whether a programme meets its objectives at all. The technical components, by comparison, are rarely where the autopsy ends.
I want to be careful here, because the clean version of this argument is also the dishonest one. Technology still matters, and it matters a great deal. A poor integration strategy, a confused data architecture, a weak security posture, the wrong SaaS product at the centre of a process any of these can genuinely be the root cause of a failed transformation, and I’ve seen each of them do exactly that. Architecture is not innocent. Bad architectural choices destroy programmes on their own merits, no human drama required. But in my experience the ledger is lopsided: human behaviour destroys far more good architectures than bad technology ever does. The strongest design in the world still has to survive contact with people who are frightened, misaligned, competing, and protecting things you can’t see. That is the harder problem, and it is the one we are least equipped to talk about.
Rational people make irrational decisions
Here’s something that took me an embarrassingly long time to accept: the people making bad architectural decisions are not stupid, and they are not acting in bad faith. They are usually intelligent, experienced, and well-intentioned. And they still produce outcomes that, viewed from the outside, look indefensible.
This is not a contradiction. It’s the central fact of the work.
Smart people make irrational decisions all the time, because the rationality that governs a decision is rarely the rationality of the system. It’s the rationality of the person’s situation. A decision that looks irrational on the architecture diagram is often perfectly rational once you understand what the decision-maker is actually optimising for and crucially, what they’re optimising for is almost never the same thing the architecture is optimising for.
Consider how an architect and a stakeholder each experience the same proposal. The architect sees: we should decommission the legacy platform; it’s a source of risk and cost. The stakeholder hears: you want me to remove the thing that, if it fails during the transition, will have my name on it. Both are reasoning correctly. They are simply reasoning about different things. The architect is reasoning about the system. The stakeholder is reasoning about their own exposure.
If you treat that stakeholder as irrational as an obstacle to be out-argued with a better diagram you will lose, and you will deserve to. The diagram was never the disagreement. Understanding what someone is actually optimising for is not a soft skill bolted onto architecture. It is architecture. The decision is the deliverable, and the decision is human.
So the real work is diagnostic: when an architecture comes out misshapen, which of the four forces bent it? Let me take them one at a time, because the fix is different for each.
Force one: fear
A great deal of bad architecture is not a design failure. It’s fear that has solidified into structure.
Listen to how architectural compromises get justified in the room and the vocabulary of fear is unmistakable. “Let’s not switch off the old system yet.” “Let’s keep one more integration, just in case.” “Let’s just do it temporarily.” None of these is a technical position. Each is a human being managing anxiety in a moment of uncertainty and each leaves a permanent mark on the system.
That last phrase is the most dangerous one in enterprise architecture, because temporary is how permanent things get built. The temporary bridge, the temporary exception to the standard they’re rarely temporary. They’re the moments where someone chose to defer a hard decision, and the deferral became the architecture. Nobody decided to keep them. Nobody decided anything. They simply never got switched off, and a year later they were load-bearing.
Let me make this concrete, because I’ve watched it happen. I once worked with an organisation that ran two CRM systems in parallel for eight years. Everyone from the engineers to the executives agreed that one of them had to go. There was no technical dispute. The data model overlaps were understood; the migration path had been scoped more than once. What there wasn’t, ever, was a person willing to own the risk of being the one who turned the old system off and signed their name to whatever broke that quarter. So the decision was never made. It was deferred, every year, by people each acting rationally to protect themselves. The “temporary coexistence” quietly became the architecture: two sources of truth, two integration surfaces, two licences, eight years of reconciliation logic all of it the residue of a single decision no one was brave enough to make. By the time I saw it, nobody even framed it as a problem anymore. It was just how things were.
This is the mechanism by which architecture debt accumulates and it’s worth being precise, because this is different from technical debt. Technical debt is a known shortcut in the code, taken deliberately, that you intend to repay. Architecture debt is the structural residue of decisions that were never really made at all. Technical debt is something you took on. Architecture debt is something that happened to you while no one was looking.
The intervention for fear is safety. You give the frightened stakeholder a way to say yes that doesn’t expose them personally: a staged cutover, a rollback plan, a shared sign-off so no single name carries the risk. Fear-driven architecture loosens the moment the fear is named and the exposure is shared.
Force two: incentives
Fear is the force people are most comfortable discussing, because it casts everyone as basically well-meaning and a little anxious. Incentives are less comfortable, because incentive-driven damage is done by people behaving exactly as designed. Nobody is frightened. Nobody is malicious. Everyone is doing precisely what their role rewards them for and the architecture is the casualty.
Look around a typical steering committee. The CIO is measured on cost, so they push to consolidate and cut. The Product Owner is measured on time-to-market, so they push to ship now and integrate later. Security is measured on risk reduction, so they push to lock down and slow down. The Team Lead is measured on delivery and retention, so they push to keep their team busy on the systems their team already knows. Every one of these people is rational. Everyone is doing their job well. And the sum of four locally optimal behaviours is very often a globally incoherent architecture: consolidated where it shouldn’t be, fragmented where it shouldn’t be, hardened in the wrong places and rushed in others.
Here’s a concrete one. On a platform programme I worked on, the target architecture called for a single shared integration layer one place where systems talked to each other. Clean, obvious, agreed in principle by everyone. It never got built. Not because anyone opposed it, but because no team’s incentives rewarded building shared infrastructure. The shared layer would have cost one team a quarter of delivery time to build something that mostly benefited other teams’ roadmaps. Each Product Owner, optimising correctly for their own deadlines, built a point-to-point integration instead faster for them, individually rational, each one defensible in isolation. Three years later there were dozens of point-to-point connections and no shared layer, and the cost of untangling them dwarfed what the shared layer would ever have cost. No villain. No fear. Just incentives doing exactly what incentives do.
This is why incentives are more dangerous than fear: there’s no anxiety to soothe and no one to reassure. The behaviour is working as intended. The intervention is not safety, it’s alignment making the desired architectural outcome something that someone is actually rewarded for, or at least not punished for. If shared infrastructure benefits everyone and is funded by no one, it will not get built, and no amount of architectural elegance in the diagram will change that. The architect’s job here is to notice the incentive gap before it sets, and to make it visible to the people who can fund or reward the thing the architecture needs.
Force three: politics
Sometimes an architecture looks the way it does not because anyone is afraid, and not because incentives quietly diverged, but because of something colder: people are competing for influence, and the system is the battlefield.
This is the force we most want to pretend isn’t there, because it’s unflattering to everyone involved, including us. But it is real, and it is often the single most powerful shaper of large enterprise architectures. Two directors are competing for the same future remit. Neither wants to cede a system, a platform, or a team to the other, because whoever owns the most surface area wins the next reorg. Budgets are split along organisational lines that have nothing to do with how the systems actually need to fit together. And this is the part that took me longest to see ownership is sometimes left deliberately vague, not by accident but as a strategy, because ambiguous ownership is easier to expand into later than clear ownership is to take from someone.
I once spent months trying to understand why a perfectly sensible consolidation kept stalling. The technical case was airtight. The incentive case, I thought, was fine. What I’d missed was that the two systems we wanted to merge belonged to two leaders who were, quietly, candidates for the same expanded role. Merging the systems meant one of them would lose their platform and with it, their claim. The architecture wasn’t being shaped by what was good for the company. It was being shaped by a succession contest that no one would say out loud. The diagram was a proxy war.
You cannot fix politics with a better diagram, and you usually can’t fix it with alignment of formal incentives either, because the real incentive (influence, standing, the next role) isn’t on any scorecard. What you can do is name the dynamic accurately to yourself so you stop wasting energy on technical arguments that were never going to land, and escalate the decision to a level where someone has the authority and the distance to make it on the merits. Politics is the force where the architect’s power is most limited and where clear-eyed honesty about that limit matters most. Pretending a political problem is a technical one is how architects burn out.
Force four: ego
The last force is the most human and the most quietly persistent. A surprising number of systems are alive today for one of two reasons: “I built it,” or “we’ve always done it this way.”
Ego attaches to architecture because architecture is creative work, and people are proud of what they make. That pride is not a flaw it’s often what produced something good in the first place. But it curdles when a system becomes part of someone’s identity, because then retiring the system feels like retiring a piece of the person. I’ve watched a genuinely obsolete platform survive three transformation attempts purely because its original architect was still in the building, still senior, and still without ever saying so treating any proposal to replace it as a verdict on him. Every replacement plan died in committee for reasons that sounded technical and were not.
The “we’ve always done it this way” version is subtler because it has no single owner. It’s the ego of an organisation rather than a person a collective attachment to a way of working that no one chose recently and no one defends explicitly, but that quietly vetoes alternatives. The architecture encodes a habit, and the habit feels like nature.
The intervention for ego is the most delicate of the four, because you cannot argue someone out of an identity. What sometimes works is separating the person from the artefact honouring the judgement that built the system while making the case that the same judgement, applied today, would build something different. Give the original architect a role in the system’s succession rather than making them defend its execution. Ego defended is immovable; ego enrolled can become an ally. But this requires the architect to set aside their own ego too to stop needing to be the smartest person in the room who proved the old thing wrong.
The architect works with people more than with technology
If you accept all of this, an uncomfortable conclusion follows. The architect’s primary medium is not technology. It’s human behaviour all four forces of it.
I resisted this for a long time, because I came into the discipline through the technical door, and the technical work is the part I find genuinely satisfying. But the longer I do this, the clearer it becomes that the technology is the easy part. The patterns are well understood. The reference architectures exist. The hard part the part that decides whether the value lands is reading which force is bending a given decision, and responding to that rather than to the technical surface of the argument.
Because the forces don’t respond to the same thing. Fear needs safety. Incentives need alignment. Politics needs honest escalation. Ego needs enrolment. Apply the wrong remedy and you make it worse: reassure someone whose problem is incentives and you look naive; try to align incentives for someone whose problem is ego and you insult them; build a better business case for a problem that is purely political and you simply tire yourself out. The diagnosis is the job. The intervention is downstream of it.
What this means in practice
I’m wary of ending on abstraction, because abstraction is the recurring failure mode of writing like this circling the same words (governance, alignment, ownership) without anything you can act on. So let me be concrete about what changes when you take human behaviour seriously as an architectural concern.
First, you start treating decisions as artefacts. Not the systems the decisions produce the decisions themselves. Who decided to keep the second integration, and which force drove it? Was it fear of the cutover, an incentive to ship faster, a political reluctance to cede ownership, or attachment to something someone built? When a “temporary” exception goes in, it gets a name, an owner, a date, and this is the part we never record an honest note on why, so the real force behind it is visible rather than buried in the topology.
Second, you read resistance diagnostically rather than adversarially. When a stakeholder pushes back on a sound proposal, the pushback is information about which force is in play. The right response is not a better argument; it’s a better question. What would have to be true for you to feel safe saying yes? surfaces fear. Who pays for this and who benefits? surfaces incentives. Whose remit does this touch? surfaces politics. Who built the thing we’re replacing? surfaces ego. The answers are usually the actual requirements, and they’re usually ones nobody wrote down.
Third, you stop measuring your success by the elegance of the design and start measuring it by the quality of the decisions you helped people make. An elegant architecture that no one adopts is a failure. A merely-adequate architecture that the organisation genuinely commits to, owns, and executes is a success. Decision-making discipline beats technical elegance, every time, and it isn’t close.
The thing nobody puts on the diagram
The strange part of all this is how invisible it stays. We document the systems exhaustively. We map every interface and dependency. And the forces that actually shaped the whole thing: the fear, the incentives, the politics, the ego appear nowhere. They’re the hidden layer beneath every architecture, and we act as though they don’t exist because they don’t fit in the modelling tool.
But they’re there whether we model them or not. They’re there in every system we couldn’t switch off, every point-to-point integration that should have been shared, every consolidation that stalled on a turf line, every obsolete platform kept alive by pride. Read any sufficiently old enterprise architecture closely and you’re not just reading a record of technical choices. You’re reading a record of what people were afraid of, what they were rewarded for, what they were fighting over, and what they couldn’t bear to let go of.
So if you take one thing from this: the next time a transformation is faltering and everyone in the room is debating the technology, ask a different question. Not what’s wrong with the system? but which force is bending this decision ( fear, incentive, politics, or ego) and what does that particular force actually need?
That question won’t appear in any framework. It’s not about diagrams or reference models. But it’s closer to the real work than anything that will, because in the end, we don’t architect systems. We architect the decisions people are willing to live with. The technology just inherits the result.