Why IT Capability maps fail

I have watched a lot of good enterprise architects try to map their organisation's IT Capabilities. Smart people, real effort, months of workshops. Most of the maps ended the same way: a large diagram nobody trusted, last updated by someone who has since left.

I used to put that down to effort. This week I mapped the IT of my own small company, and I think I finally understand what goes wrong. There are three problems, and they reinforce each other.

Problem one: volume

There are a lot of IT Capabilities. My first draft had 40 of them, for a company of one. Scale that to a real enterprise and you get hundreds, each with owners, requirements and links. Nobody can hold that in their head, and nobody keeps it current by hand.

But here is the thing I didn't expect: a quarter of my 40 weren't capabilities at all. "Admin workstation" was a device. "Network segmentation" was a constraint. "Address assignment" was a protocol. Once I had rules to test them against, 31 were left. A lot of the volume in a typical capability map is entries that should never have been there.

Problem two: the shape

We keep trying to store capabilities as a list, a hierarchy or a spreadsheet. None of those fit, because every IT Capability sits in three structures at the same time:

A dependency graph. Resolve names needs Access the internet to run, and Run a platform workload needs Resolve names.
A cross-cut by viewpoints. Security, Disaster recovery, Compliance and the other viewpoints each set requirements on every capability. They are not capabilities themselves; they are the lenses you look through.
A many-to-many mapping to implementations. One capability can be met by several products, each serving different consumers, and one product can serve several capabilities.

One IT Capability, Resolve names, shown in the centre. Viewpoints above it raise IT Requirements, it depends on two IT Capabilities to its left, three implementations to its right meet it, and below it another IT Capability depends on it while a monitoring capability meets one of its requirements.

A list keeps none of these. A hierarchy keeps a distorted version of the first. A spreadsheet keeps one of the three and drops the other two. That is why so many maps look tidy and answer nothing.

Problem three: no shared rules

This is the one that causes the other two. Ask five architects whether "identity" is a capability and you get five answers, all defensible. Without a shared definition, every entry is a judgement call, and judgement calls don't scale or survive a handover.

The rules I ended up with are short. An IT Capability is an ability IT provides, named verb + object, used directly by a person, a Business Capability or another IT Capability. It says what can be done, never how. A candidate has to pass four tests:

Test	Passes when	If it fails, it is
Verb	It reads as "be able to verb object"	An implementation
Consumer	Someone or something uses it directly	A requirement on another capability
No product	Its name holds no product, device or protocol	An implementation
Substitution	At least two implementations are conceivable	Part of a larger capability

Then five rules keep the map consistent. One capability per verb and object: a guest on the Wi-Fi and an employee on the Wi-Fi use the same capability, and the difference is a requirement. Qualify the object only by a property of the object itself. Allow several implementations. Record "depends on" only for what is needed while running, with no cycles. And use a second kind of link, "met by", for the capabilities that serve other capabilities' requirements: backup, monitoring, audit.

I also stopped using the bare word "capability". It is always IT Capability or Business Capability. Half the arguments I have seen in architecture boards came from people meaning different ones.

I didn't write the rules first

None of these rules were designed upfront. Each one was forced by a candidate that looked right and didn't fit. The admin workstation forced the verb test. Segmentation forced the consumer test. Guest Wi-Fi forced the "one per verb and object" rule. Resolve names and Run a workload depended on each other, which put a cycle in the graph. That cycle was fixed by splitting workloads by their class: infrastructure, platform, application.

I also reversed two decisions along the way. Splitting capabilities by consumer looked attractive until I saw it would undo merges I had just made. That is the real lesson: rules you hand down without the cases behind them don't survive contact with real entries. The cases are what make the rules stick.

Why this is finally maintainable

The fourth thing I learned is why this used to be impossible and isn't any more.

Architects tried to keep these maps by hand, and no modelling tool fixed that, because the hard part was never drawing the boxes. It was applying the rules consistently to hundreds of entries and keeping every link true as things change.

I did this work with a language model beside me, and the rules are what made that work. In one sitting we drafted 31 IT Capabilities and 175 requirements, each traced to the decision it rests on. Because the rules are explicit, they are checkable: does every dependency point to a lower number, does every cited decision exist, does every gap name the requirement it blocks? A script answers that in seconds. And because the requirements name standards rather than products, replacing a product should touch one implementation, not the capabilities above it.

The architect's job moves from keeping the map current to deciding the rules and the hard cases. That is a job people can actually do.

I'm Tete Mensa-Annan. I ran the software engineering platform at a regulated pharma, and I have spent thirty years watching good intent get lost between the strategy and the systems. If your capability map has stalled, the problem is usually the rules, not the effort, and I'm happy to talk about yours.