A Diagram Cannot Be Wrong

Put a capability map on a wall and ask five people what one of the arrows means. You will get five answers, all of them reasonable. The line between Customer Onboarding and CRM might mean the platform automates the capability, or merely stores its data, or that someone once decided the CRM team owns the budget for it. The box below another box might mean decomposition, or it might mean the modeller ran out of horizontal space.

Nobody in the room experiences this as a problem, because everybody repairs it silently. Humans are extraordinarily good at reading intent into an underspecified picture, and business architecture has been able to rely on that generosity for its entire history. The diagram was drawn for people, people filled in what it left out, and the practice worked well enough.

That arrangement is now under pressure from two directions at once, and I think the discipline has not fully registered either.

What an ontology actually is

The word arrives with more baggage than it deserves, so it is worth being plain about it.

An ontology is not a glossary, and it is not a data model. A glossary tells a reader what a term means. A taxonomy arranges terms in a classification. A data model in its physical form says how records are stored; in its conceptual form it comes considerably closer to an ontology, and the difference there is not the picture but the reach. An ontology is written to hold across systems that were never designed together, in a logic that admits what it does not know, with identifiers that still mean something outside the tool that created them.

The Dewey Decimal system is the canonical taxonomy, and it is regularly offered as an example of an ontology, which it is not. Dewey tells you that 616.12 sits beneath 616. It has no way to say that a heart disease is treated by a procedure, and there is nothing in it that anything could violate.

What an ontology adds to all of these is consequence. It fixes which concepts exist, which relations may hold between them, and which combinations of statements cannot both hold. A taxonomy tells you how things are classified. An ontology tells you what can be truthfully said about them, and therefore rules some things out.

It is worth being exact about how that ruling out actually happens, because the usual illustration of it is wrong. Suppose approves is declared to run from a role to a decision type, and someone attaches it to a document instead. In the OWL family this raises no error whatsoever. Domain and range are not constraints there; they are inference rules. The reasoner will conclude that the document is a decision type and carry on quite happily. You get a contradiction only if the model also states that documents and decision types are disjoint, at which point the reasoner has something to bite on. The alternative is to leave the reasoner out of it and check the graph against a shape that says this relation points at a decision type and nothing else, which is a different mechanism with different tooling.

Both routes arrive at the same place, and the place is the point: the model has become capable of failing a check. But which route you take decides what kind of failure it is able to report, and the two are not interchangeable.

So the useful test of whether you have an ontology is not whether you have written definitions down. It is whether your model is now capable of being contradicted.

Contradicted, not falsified. A model that passes every check can still describe an organisation that stopped existing eighteen months ago; consistency is a property of the model, not a report about the world. The title of this piece is a backhanded compliment in both directions. A diagram cannot be wrong, which is precisely its problem, and the thing that replaces it cannot be right either. It can only be checkable, and that turns out to be worth a great deal more than it sounds and a great deal less than it is sold as.

Business architecture is already semantic

Here is the part that makes this less of a leap than it sounds. Business architecture is not lacking semantics. It is full of them; they are just not written anywhere that anything can reach them.

Take the simplest capability map: Customer Management over Acquisition, Onboarding, Service, Retention. That structure already asserts concepts, distinct identities and a hierarchy. What it does not say is which hierarchy. Is Onboarding a kind of Customer Management, or a part of it? Almost always the second, which makes the map a partonomy rather than a taxonomy, and the difference is not academic. Subsumption inherits properties downward and composition does not, so a traversal that treats the one as the other returns answers that look sound and are not. The map does not merely leave this unstated. It has nowhere to state it.

Now add the relations that any real architecture practice already maintains in some form. Onboarding uses customer data. Onboarding is realised by a process. That process is supported by a platform. The capability is governed by a policy. The strategy requires the capability. What you have at that point is no longer a tree. It is a set of nodes and typed edges, which is formally a graph, and the distance from there to a knowledge graph is much shorter than the tooling debate suggests.

It would be unfair to claim that none of this has ever been defined. ArchiMate defines its relationship types and publishes a table of which may connect what. BIZBOK defines capabilities, value streams and information concepts and how they relate. A metamodel-conformant repository is in far better shape than a slide, and the criticism above lands on the drawing, not on the standard.

What is missing even in the well-run repository is identity. Nothing guarantees that the Customer in the application landscape is the Customer the value stream model used last quarter, or that supports means in one model what it meant in the other. Every relation type can be impeccably defined within each model and the concepts still fail to line up across them. That is the ordinary case, not the pathological one, and it is the case that costs money.

What implicitness costs

Three costs, and they compound.

The first is silent equivocation. Customer in the CRM model, Customer in the risk register and Customer in the revenue model are frequently three different concepts wearing one word: a contract holder, a data subject, a billing account. As long as the models stay in separate slide decks, nothing breaks. The moment anyone integrates them, or asks a question that crosses them, the three quietly merge into one and the answer is wrong in a way that leaves no trace.

The second is that analysis degrades into a workshop. Ask which business capabilities are affected if an identity service goes end-of-support. In principle this is a traversal: the service supports a verification process, the process realises the onboarding capability, the capability enables the acquisition value stream. Three hops, and the better repositories will in fact run them for you, because there is a graph underneath. What they cannot tell you is whether those edges still hold, or whether the supports one team recorded means what the supports another team recorded meant. So the question goes back to interviews, and the answer arrives incomplete and already stale. Impact analysis is routine in software architecture because the artefacts it traverses are the ones the build actually consumes, and drift announces itself as a broken build. Nothing in business architecture breaks.

The third cost is the one I care about most. A model that cannot fail a check is a model nobody has to maintain. A drawing cannot be inconsistent in any way that anything will report; it can only be unconvincing, which is a matter of taste and therefore not actionable. Give the same content typed relations, stable identities and constraints, and specific defects become detectable rather than debatable. A role accountable for an outcome but holding no decision right over it is a structural gap, not an opinion. Two bodies with unresolved final approval over the same object is a mandate collision. A high-risk object with no instantiated control is a control gap. None of those findings require a judgement about whether the architecture is any good. They require only that the model be capable of contradiction.

It is worth noticing what those three findings have in common. Each of them is about something that is not there, and that decides which machinery produces them. Ontology languages of the OWL family assume an open world, in which an absent statement is unknown rather than false, so a reasoner will report none of the three. They come from a constraint check that evaluates the graph exactly as it stands. Inference tells you what follows; validation tells you what is missing. Most of what an architecture practice actually wants to be told sits on the validation side, and a programme that buys only the reasoner discovers late that it bought the half it needed less.

What the checks do not reach

A model that cannot fail a check is a model nobody has to maintain.

That is part of why architecture repositories rot so predictably. Not because architects are careless, but because nothing in the artefact ever announces that something has gone wrong with it.

Only part, though, and the honest version of the argument has to say so. Constraints catch structural defects. They do not catch a model that is structurally impeccable and describes last year's organisation. Drift becomes visible only where it happens to break something formal: a decommissioned system still sitting at the end of a required relation, a dissolved committee still holding an approval that some rule says exactly one body must hold. Where the organisation changed and the model merely stayed plausible, every check passes.

A green report is a statement about form. Reading it as a statement about the organisation is the most expensive confusion available in this field, and making a model machine-checkable makes that confusion easier to fall into rather than harder, because now there is a report and the report is green. Correspondence to reality is not a property anything validates. It stays a process somebody has to run. What the constraints change is that neglect now has some chance of announcing itself instead of none.

The second reader

The pressure that has genuinely changed the calculation is newer, and it is not about tidiness.

Business architecture models now have a second audience, and it is not generous. Point a retrieval system at the architecture repository and it will happily answer questions about capabilities, ownership and dependencies. What it is actually doing is finding text that resembles the question. Resemblance is not derivation. The system has no way to distinguish the Customer of the risk register from the Customer of the billing model, because nothing in the source ever made them distinguishable, and it will not hedge, because nothing told it to.

Graph retrieval over an ontology behaves differently, and the difference is not accuracy at the margin. It is traceability. An answer assembled by traversing asserted relations can show its path: this capability, via this process, supported by this system, governed by this policy. The derivation arrives with the answer, which means it can be checked and, more to the point, disputed by someone who knows the domain.

Two qualifications, because the claim is routinely made larger than it is. The path shows how the answer was assembled, not where the underlying statements came from or who vouched for them, which is a separate thing to record and is usually not recorded. And in most such systems a language model still writes the final sentence. The retrieval step becomes auditable. The wording does not.

Once software does not merely answer but acts, the requirement gets sharper again. An agent needs to know more than that a CRM supports onboarding. It needs to know which organisational capability it is exercising, what decision type that constitutes, and on whose authority, because technical permission to call an API and institutional authority to make a decision are different properties. The first is represented everywhere, in scopes and roles and access policies.

The second is not unrepresented, and it is worth knowing that before claiming a vacuum. Verifiable credentials in the vLEI scheme carry organisational role authority. ODRL expresses permission, prohibition and duty. XACML decides authorisation from policy. SBVR, an OMG standard since 2008, puts obligation and permission directly into business vocabulary. What none of them has is presence. Almost nothing an organisation actually runs on knows, in machine-readable form, who was entitled to decide what.

The same caution applies on the modelling side. Dietz's enterprise ontology and the DEMO method have modelled actor roles, authority and commitment for three decades, through a transaction pattern in which someone requests, someone promises, someone states and someone accepts. It is closer to what I am describing than anything in mainstream business architecture, and it never crossed over. Any honest version of this argument owes an account of why the second attempt should go differently, and mine is narrow: the consumer has changed. The earlier work addressed human modellers, who could always repair an ambiguity by asking someone. The new reader cannot ask.

That gap is the subject of my own research, and business architecture is where the representation has to start, because it is the discipline that already models what an organisation does at the right level of description.

What this does not mean

It does not mean a two-year enterprise ontology project. Those fail, reliably, and they fail for a structural reason: an ontology built to be complete has no test that tells it when to stop, and no consumer whose failure would reveal that it went wrong.

The discipline that works is narrow, and it already has a name. Start from competency questions, the questions the ontology exists in order to answer, and let them decide both what gets modelled and when you are finished. Grüninger and Fox proposed this in the mid-nineties and it remains the only reliable stopping rule anyone has produced.

Then fix the handful of relation types your practice already leans on: realises, supports, governs, decides, is accountable for. Define them properly, including what they may and may not connect, and decide for each one whether that definition is there to license an inference or to fail a check, because a single mechanism will not give you both. Give the concepts stable identifiers, so that the Customer in one model is provably the same thing as the Customer in another. If you also need them provably different, assert it: these logics make no unique name assumption, and two identifiers do not denote different things until something says they do. Add constraints only where a violation would actually matter to someone.

Nor does an ontology decide anything on its own. It does not determine what the organisation ought to do, where authority ought to sit, or which trade-off is right. It checks the model against rules the organisation itself wrote down. The norm stays human, and so does the question of whether the model still describes anything. What becomes machine-checkable is only whether the structure conforms, which is a far smaller claim than the one usually made for this technology, and the only one I think holds.

The part that is genuinely uncomfortable

There is a real cost, and it is not the modelling effort.

Making the semantics explicit makes disagreement visible much earlier. The moment you have to state what governs means, or which body actually holds final approval, you discover that two parts of the organisation have been operating on incompatible readings for years and getting along fine precisely because nobody wrote it down. The ontology does not create that conflict. It ends the arrangement under which the conflict could be deferred indefinitely.

I think that is the value, not a side effect. An architecture practice that produces pictures nobody can contradict is producing documents. One whose models can be queried, violated and therefore corrected is producing something an organisation can act on, and, increasingly, something its software will act on whether or not anyone ever made the semantics explicit.

More as the work develops.