No framework sees your whole organisation
TOGAF, ArchiMate, BPMN, ITIL and PRINCE2 are each a partial view. Run one organisation's records through all of them and the same things fall out every time — cost, identity, infrastructure.
Most organisations past a certain size have committed to an architecture framework. Somebody was certified, a tool was bought, a modelling standard was agreed, and a set of diagrams now exists that describes the business in that framework’s terms.
This is not a criticism of that decision. The frameworks are good. TOGAF gives you a disciplined way to talk about architecture domains. ArchiMate gives you a modelling language precise enough that two people mean the same thing. BPMN makes process explicit. ITIL organises service management. They exist because the problems they address are real.
But every one of them is a lens, and a lens has edges.
The experiment
Take a single mid-size organisation and reduce it to a manageable set of records — the departments, the capabilities, the processes, the systems, the data objects, the integrations, the infrastructure, the vendors, the costs, the policies, the projects. Around forty things, all of them real, none of them controversial.
Now render that same set through each framework in turn and count what each one can hold.
| Framework | Records placed | Layers covered |
|---|---|---|
| ArchiMate | 33 of 39 | 6 of 10 |
| ITIL | 28 of 39 | 4 of 10 |
| TOGAF | 27 of 39 | 4 of 10 |
| DDD | 18 of 39 | 2 of 10 |
| BPMN | 11 of 39 | 3 of 10 |
| Jira | 8 of 39 | 2 of 10 |
| PRINCE2 | 6 of 39 | 2 of 10 |
ArchiMate is the most complete, and it still has nowhere to put six of the thirty-nine. That is worth saying plainly rather than skipping past: the broadest framework in common use covers a little over half the layers, and it is genuinely good at what it covers.
The narrower ones are not deficient. BPMN placing eleven records is not a failure — BPMN is a process notation and it models process superbly. The failure is only ever in the expectation that a process notation should describe an organisation.
The interesting part is what falls out
Run the exercise repeatedly and a pattern appears in the residue. It is the same categories almost every time.
Cost. Licence spend, vendor contracts, cost centres. TOGAF has no home for them. ArchiMate has no home for them. BPMN, DDD and Jira have no home for them. Only ITIL catches cost — through its financial management practice — and PRINCE2 catches a version of it as the business case. So the architecture diagram and the spend conversation are structurally disconnected, and every organisation reconciles them by hand, in a spreadsheet, once a year, badly.
Identity. Who acts, under what authority, within what boundary. Almost no architecture framework models this, because when the frameworks were designed the actors were people with job titles and the authority question was answered by an org chart. That assumption is now under real pressure from software that acts on someone’s behalf.
Infrastructure detail and registry. The environments, the tenancies, the endpoint estate, the record of what is even registered as existing. Some frameworks gesture at this; few hold it at the resolution an operations team actually needs.
None of these are exotic. They are the three things most likely to come up in an executive conversation about whether a change is affordable, safe and possible.
Why this matters more than it used to
For years this was tolerable. The framework covered the architecture conversation, the finance system covered the cost conversation, identity was an IT concern, and humans held the joins in their heads. Inefficient, but survivable.
Two things changed.
The first is that the joins are now where the value is. The question executives ask is not “what does our application architecture look like” but “if we fund this initiative, what does it touch, what does it cost, and what breaks.” That question crosses every boundary the frameworks draw. Answering it means assembling four partial views by hand, which is why it takes three meetings and still arrives as an estimate.
The second is that software has started acting on the organisation’s behalf. When the actor was a person, the authority question was answered socially. When the actor is an agent invoking tools against production systems, the authority question has to be answered by a model — and if your representation of the organisation has no concept of delegation, boundary or source authority, you cannot answer it at all.
Frameworks are views, not containers
The mistake is not choosing a framework. The mistake is storing the organisation inside one.
Once the model lives in the framework, the framework’s edges become the organisation’s edges. Anything it cannot express does not get recorded, and anything not recorded is invisible to every question asked later. The tool’s limitations quietly become the business’s blind spots.
The alternative is to hold the organisation as a graph — every record, all the layers, including the cost and identity and infrastructure that no single framework wants — and treat each framework as a projection over it. Ask for TOGAF and you get TOGAF’s four domains. Ask for BPMN and you get pools, lanes and activities. The architects keep working in the language they know, the executive gets a plain-terms view, and neither is looking at a separate model that has to be kept in sync with the other.
Nothing is lost in translation, because nothing was translated. It was projected.
Two objections worth taking seriously
“Our framework does cover that.” It might. Whether a given record belongs in a given band is a judgement, and reasonable architects disagree — the mappings behind the table above are configuration, tuned to how a particular organisation actually uses its framework, not universal truth. If you would place things differently, that is not a problem with the exercise. It is the exercise. What survives the argument is the shape of the residue, and in our experience the residue keeps containing cost.
“This is just an argument for another tool.” It is an argument for not letting the modelling notation decide what your organisation is allowed to know about itself. If your current tooling holds all ten layers and renders every lens, you already have what this describes and should keep it.
Most do not. Most have a good framework, a partial model, and a set of important questions that fall between the diagrams — which is usually discovered the week someone has to answer one.
If this is the kind of thinking you want applied to your own organisation, discovery is where it starts.
Book a discovery