The Moat Was Never the Wall

In March 1314, Edinburgh Castle was still in English hands, sitting on top of a volcanic rock that made it one of the most defensible fortresses in Scotland. Robert the Bruce’s nephew, Thomas Randolph, Earl of Moray, had it under siege. The walls held. The garrison knew exactly where an attack would come from, because there was only one place an attack could come from: the main approach, the one route up the rock any sane commander would use.

Randolph didn’t take that route. A man named William Francis, whose father had once kept the castle, knew a path up the sheer north face of the rock, the one nobody defended because nobody believed anyone would try it. At night, Randolph and thirty men climbed it, took the garrison by surprise, and Edinburgh Castle fell without the wall ever being breached.

The wall was never the problem. The defenders had built their entire defence around the assumption that the terrain itself would do part of the job for them, that the rock face was a moat nobody needed to guard. It was. Right up until someone with the right information found the one place it wasn’t.

Vendors still describe their moats the same way they did twenty years ago: switching costs, data depth, integration lock-in, install base. The language is unchanged. What’s changed is the ground those moats were built on.

A moat was never really the wall itself. It was three underlying mechanisms doing the actual defending: the cost for a competitor to replicate what you’d built, the time it would take them to close the gap even if they tried, and the information asymmetry you held that they didn’t. Strip those three away and the wall is just decoration. Nothing is actually stopping anyone.

Those three mechanisms depended on one condition holding true: the system around them moved slowly. Replication took years because engineering took years. Cycle time was long because product development was long. Information asymmetry persisted because knowledge diffusion was slow and expensive. A vendor could dig a moat once and rely on it for a decade. The environment simply wasn’t going to change fast enough to make the moat irrelevant in the meantime.

AI doesn’t attack the wall. It collapses the terrain the wall was built on. All three mechanisms that made moats defensible are falling at once, not because attackers got stronger, but because the underlying cost structure changed for everyone simultaneously.

Replication cost falls every cycle. The tools available to build and rebuild category defining product have become radically cheaper across the board. A workflow, an integration layer, a support knowledge base: the things that used to take a competitor a two year build now take months, because the engineering effort that used to be the moat’s raw material is itself AI assisted.

Cycle time compresses for the same reason. AI assisted development shortens the distance between a competitor deciding to enter and having something credible in front of a customer. The eighteen months a vendor used to count on to reach parity is no longer a safe planning assumption.

Information asymmetry erodes hardest of all. The knowledge that used to be locked inside an incumbent’s product, its support tickets, its implementation playbooks, its years of edge cases, was genuinely hard to reconstruct without living through it. That knowledge is now extractable and synthesisable from public documentation, customer conversations, and the incumbent’s own published material. What used to take a decade of scar tissue to learn can now be approximated in a fraction of the time.

None of this means every moat is gone. Genuine network effects, hard regulatory barriers, and data advantages that are structurally difficult to extract still hold real weight, and it would overstate the case to say otherwise. But for the broad category of moats built on replication cost, cycle time, and information asymmetry alone, the ground has shifted more in the last few years than in the prior few decades. That’s the claim worth testing against your own category, not taking on faith.

Here’s the part most vendors miss entirely, because they’re still measuring the wrong thing. A vendor can have genuine switching costs, real data depth, real lock-in, and still be finished, if the category the moat was built to defend is itself being replaced by a different governing question.

This is the Workday pattern. Workday’s moat, on paper, looks credible: painful migration, years of transaction data, ecosystem integration. Stress test it and it still holds, on its own terms. But the terms are the problem. The moat defends HCM, and HCM’s governing question is essentially administrative: who is employed, at what grade, under what process, with what history. That question doesn’t disappear, but it stops being the question the organisation is actually trying to answer.

Strategic Workforce Planning asks a different question entirely: not who is employed today, but what capability the organisation needs against what future demand, and whether that capability should come from a human employee, a contractor, an AI agent, or some blend that doesn’t map to a headcount record at all. That data doesn’t live in an HCM system, because HCM was never built to model capability, only to administer people. A platform answering the SWP question can be genuinely superior on the question that matters and still look thin on the switching cost, data depth comparison, because it isn’t competing on Workday’s terms at all.

Workday can win every single battle to defend HCM, keep every customer it currently has, and still lose the war, because the war moved to ground the moat was never designed to cover. That’s the trap: a vendor checks its moat, finds it intact, and concludes it’s safe. But an intact moat around a category the market is quietly re-asking is not protection. It’s a very well-defended position nobody needs to attack, because the market has already gone around it.

Two separate questions, and vendors keep collapsing them into one.

1. Can a competitor replicate what I’ve built, on my terms, inside my category? This is the classical moat question. It’s the one getting easier to answer yes to every cycle.
2. Is the category itself still the one the market is organising around? This is the question moats were never built to answer. It’s the one that actually determines survival.

A vendor can pass the first test and still fail catastrophically on the second. Blockbuster had real defensibility against another video rental chain. It had none against the category itself becoming irrelevant. Kodak had genuine patent and manufacturing moats around film. None of it mattered once the category people were organising around stopped being film.

Stop asking how deep the moat is. Start asking whether the moat defends a category the market still needs, or a category the market is quietly walking away from. The first question flatters the vendor. The second one is the only one that predicts what happens next.

A moat you can’t breach is worth nothing if nobody’s trying to breach it anymore, because they’ve already gone around it. Some vendor category leaders are already in that condition without knowing it, because they’re measuring wall height while the ground moves underneath them.

The vendors still standing in five years won’t be the ones with the deepest moat. They’ll be the ones who noticed the ground moving before they finished measuring the wall.

Randolph’s men didn’t storm Edinburgh Castle. They went around it, up the one face nobody thought to guard, because nobody believed the rock itself needed defending. The wall was intact when the castle fell.

If you want to know which condition you’re actually in, test both. Test the classical moat: the switching costs, the data, the lock-in. And test the battlements of the category itself: is the governing question your product answers still the one the market is organising around, or has the war already moved.

That’s the conversation Bloor runs with vendors who would rather find out now than discover it when a competitor has already walked past the walls.