The Methodology Ontology: What It Takes to Make Methods Machine-Executable

There is a gap between a method that a person can follow and a method a machine can execute, and almost all published methodology sits on the wrong side of it.

Take any well-known strategy framework. It is described in a book, a diagram and a set of worked examples. A competent consultant reads it and can apply it, because they supply the enormous amount of implicit knowledge the description leaves out: when it applies, what counts as a valid input, what to do when the input is partial, how its output connects to the next step.

A machine has none of that. Hand a language model the same description and it will produce something shaped like the framework, filled with plausible content, connected to nothing.

Closing that gap is an ontology problem, and it is the least visible and most demanding part of what we build.

What an ontology actually is

Stripped of the philosophy department connotations, an ontology is a formal specification of the entities in a domain and the relationships between them.

For enterprise methodology that means answering questions that written methods never answer explicitly:

• What kind of thing is a “capability”? How does it relate to a process, a role, a system, a value stream?
• When two methods both produce something called a “customer segment,” are those the same entity or two different ones?
• If an operating model design changes a capability, which downstream artefacts are affected?

These sound like pedantic questions. They are the questions that determine whether methods can be composed at all. Without answers, every method is an island and every handover between methods is manual translation performed by a human — which is exactly the translation loss that makes change work expensive.

One definition per model

The rule we hold to is simple to state and demanding to maintain: one definition per model.

When two hundred methods reference “business model,” they reference the same entity with the same structure, not two hundred locally consistent variations. When a Jobs-to-be-Done analysis produces a customer need, that need is the same class of object that a business model pattern consumes as input.

This is why the corpus can behave like a system rather than a library. The output of one method is genuinely available as the input of another, because they are typed against the same model of the enterprise.

Maintaining that discipline across 200+ models is not a one-time modelling exercise. It is continuous work: every new method has to be reconciled against the existing entity model, and occasionally the entity model has to change, which means revisiting what depends on it.

The corpus does not maintain itself.

Why this cannot be scraped

A reasonable question: if the methods are published, why not train a model on all of them and skip the ontology?

Because the ontology is not in the publications. It is the layer beneath them — the reconciliation decisions, the entity definitions, the relationship semantics. A published framework tells you what to do. It does not tell you that its notion of “capability” is coarser than the one used by the operating model method three chapters later, or how to reconcile them when both are applied to the same organisation.

That reconciliation is judgement work, performed by people who understand both methods deeply, and it accumulates over years. This is the part that fifteen years of transformation work produced and that a corpus of text does not contain.

There is a second reason. Methods that were never published — the ones developed in client work, tested against real undertakings, revised when they failed — are a substantial part of the corpus. They exist because the work happened.

From ontology to execution

The ontology is what makes the executable layer possible. Once entities and relationships are specified, each method can be expressed as a specification with:

• Defined inputs — which entities it needs, in what state
• Defined operations — what it does with them
• Defined outputs — which entities it produces or modifies
• Applicability conditions — which types of undertaking it belongs to

At that point a method is no longer a document. It is a component. And components compose: give the engine an undertaking type and it can determine which methods apply, in which order, with which dependencies between them — because that information is in the specifications rather than in a consultant’s head.

This is the mechanism behind the step nobody else performs: turning a brief into a structured workflow with the applied methods filled in.

The enterprise knowledge model

The other half of the picture is the model of the organisation itself.

An executable method needs something to execute against. That is the enterprise knowledge model: a living, validated map of how the organisation actually works — its building blocks and how they connect. Not an architecture diagram, which describes systems, and not an org chart, which describes reporting. A structural model of the business.

Methods read from it and write to it. A capability assessment reads the capability entities and writes their assessed state. An operating model design proposes changes to those same entities. Because both work on one model, the second can see what the first concluded.

This is unglamorous infrastructure and it is where the leverage is. The alternative — every method carrying its own private picture of the organisation — is what makes conventional methodology work fundamentally unscalable.

Why it is worth the effort

Ontology work is expensive, slow and invisible to users. Nobody has ever bought software because of an entity model.

But it is the difference between a system that generates strategy-shaped text and a system that structures a real undertaking. Everything visible in the product — the workflow generation, the provenance chain, the ability to carry reasoning from strategy through to delivery — depends on it.

If the model is wrong, the outputs are locally plausible and globally incoherent. If the model is right, methods compose, and the compounding starts.