Conformance Is Not Truth

In the same meeting you will hear all three words used as if they were interchangeable. Someone calls the capability map a model, someone else calls the tool's underlying structure the metamodel and then calls it an ontology two sentences later, and nobody objects, because in that room nothing turns on the difference.

Something does turn on it, though, and it shows up later. The three words name three different jobs. Which one you have decides which questions can be answered mechanically, which findings your validation run is capable of producing, and which kind of error it will never catch no matter how green the report goes. That last one is the part that surprises people.

So: definitions first, then what each one buys, then what none of them will do for you.

A model describes a particular thing

The oldest definition is still the most useful one. Stachowiak's three properties: a model maps something, it reduces it, and it stands in for the original for someone, for a period, and for a purpose. That third property is usually shrunk to "purpose" alone, but the full version is the one that does the work. A model has a substitute function, and who it substitutes for is part of what it is.

Your capability map is a model. So is the process landscape, the application portfolio, the org chart. Each maps some part of an organisation, leaves out almost everything, and leaves out precisely what the purpose allowed it to leave out. The reduction is not a defect to be fixed by adding detail. It is what makes the thing a model rather than the organisation itself.

A model is a purposeful, reduced description of a particular subject, made for someone.

Two consequences follow immediately and are routinely forgotten. A model is only assessable against its purpose. "Is this model good?" is not a question; "is this model good for that decision?" is. And a model says nothing about the language it is written in. It uses that language; it does not define it.

A metamodel defines the language the model is written in

This is where the confusion usually starts, because a metamodel looks like a model. It has boxes and lines and lives in the same tool. But it sits at a different level: it says which element types may exist, which relations may connect them, and which combinations are well-formed.

ArchiMate has one. UML has one, defined in MOF. Your architecture repository has one whether or not it ever shows it to you. The moment the tool refuses a structural relationship because the relationship table does not permit it between those two element types, you have met it.

A metamodel defines the vocabulary and rules of construction that models must obey.

The relation between the two is conformance, and conformance is mechanically checkable. That is the whole appeal. A model either uses element types the metamodel declares, in combinations the metamodel permits, or it does not, and a tool can tell you which without anyone forming an opinion.

The classical layering makes the levels explicit: the instances, the model, the metamodel that defines the modelling language, and above that a language for defining metamodels. Four levels, each one describing the level below. The tower is usually said to stop there, and the top is genuinely reflexive: MOF is defined in MOF. But the standard itself is blunter than its readers. MOF 2.5.1 opens a section headed How Many Meta Layers? by naming "the perceived rigidness of a 'Four layered metamodel architecture'" as one of the sources of confusion in the OMG suite, and allows any number of levels at or above two. Four is convention, not architecture. Whether the bottom level is the organisation itself or the recorded data about it is an old argument, and the OMG layering puts instances there rather than the world. What matters practically is only this. The metamodel governs form. It carries an intended meaning for its element types, but nothing in it establishes, or is able to check, whether a conforming model is true of anything.

An ontology fixes what exists and what may be truthfully said

An ontology also constrains, so it is easy to mistake for a metamodel with different tooling. The difference is in what it is for and where it has to work.

A metamodel constrains how you may draw. An ontology asserts what a domain contains: which concepts there are, which of them are the same concept under different names, what follows from what, and which combinations of statements cannot both hold. It is built to be shared between systems that were never designed together, and it is written in a formalism that a machine which has never seen your repository can still reason over.

An ontology fixes what exists in a domain and what can be truthfully said about it.

There is also a structural difference worth knowing before you argue with someone about it. In the metamodelling tradition the levels are meant to be strict: instances at one level, the model above them, the metamodel above that, and no mixing. The principle is cleaner than the practice, and UML itself breaks it with stereotypes, powertypes and instance specifications. In RDF and OWL the levels share a single graph, and classes and individuals are described with the same machinery. How far you may actually push that depends on the dialect. RDFS and OWL Full let a thing genuinely be a class in one statement and an individual in the next, the latter at the price of undecidability. OWL 2 DL allows only punning: the same identifier may appear in both roles, but the two readings are interpreted independently, and nothing inferred about the class reaches the individual. The two traditions do not layer the same way, and expecting them to is a reliable source of frustration.

It is worth saying where the boundary between the two is crossed on purpose. The foundational ontologies, UFO, BFO and DOLCE among them, exist precisely to give modelling languages a semantic grounding, and OntoUML is what that looks like in practice. The division of labour set out here is a working distinction, not a wall.

Where the distinction bites

The practical test is which question you are asking.

Can two architects draw the same situation the same way, and will the tool stop them when they cannot? That is a metamodel question. No amount of ontology will answer it, because an ontology does not care what your diagram looks like.

Do these two systems mean the same thing by "customer"? That is an ontology question. No metamodel will answer it, because both systems can be perfectly conformant to their own metamodels and still mean different things. In fact that is the normal case.

What does this organisation actually look like? That is a model question, and neither of the other two will answer it, because both are about apparatus rather than about your organisation.

In my own work the same governance principles are maintained twice, deliberately. Once as invariants over a metamodel: rules such as whoever decides must actually hold the right they exercised, or a suspended mandate grants no rights, expressed so that an ill-formed governance structure cannot be built in the first place. And once as constraint shapes over a shared vocabulary, so that a statement coming out of one source can meet a statement coming out of another and be checked against the same principle. That is not redundancy. The first prevents; the second integrates. Neither substitutes for the other.

What each one buys

Models buy shared attention. They are cheap, immediately useful, and they let a room agree on what it is talking about long enough to decide something. This is not a small thing, and the more formal artefacts do not replace it.

Metamodels buy well-formedness and mechanisation. Once the element types are declared, a class of defect stops being a matter of taste: a missing target, an impossible connection, a role accountable for something it holds no right over. They also buy the discipline of having had to say what your boxes actually are, which is more valuable than it sounds and often more painful than expected.

Ontologies buy inference and shared meaning: integration across sources that were never designed to meet, and conclusions that follow from what was stated instead of being restated by hand. Two things usually credited to the ontology belong to the substrate underneath it. Identifiers that survive leaving the tool, and queries that traverse relations rather than matching text, are what a graph with a global identifier scheme gives you; a plain RDF graph carrying no axioms at all does both. The separation is worth making, because the substrate is far cheaper to adopt than the axioms.

Explanation is a third thing often promised and less often delivered. Some reasoners will hand you the justification for an inference, which is what makes a derived answer disputable by someone who knows the domain. That is a property of the tool you chose, not of the language.

What none of them will do

Now the part that decides whether any of this is worth the effort.

Conformance is not truth. A model can conform perfectly to its metamodel and describe an organisation that does not exist. Every check passes, the report is green, and the model has been wrong since the reorganisation. Nothing in the metamodel layer looks at the world; it looks at the model. A green validation is a statement about form, and reading it as a statement about the organisation is the most common and most expensive confusion in tool-led architecture practice.

Consistency is not truth either. An ontology that is logically consistent can be consistently wrong. Reasoning preserves whatever you put in; it does not check it against anything outside.

Absence is not negation. This one costs people real money. Ontology languages of the OWL family assume an open world: what is not stated is not thereby false, only unknown. So the findings most organisations actually want, that no control is instantiated here, that no mandate backs this right, that this approval chain terminates in nothing, do not come from the reasoner. They come from a constraint check that evaluates the graph exactly as it stands, which is a different mechanism with different tooling. If you take away one technical point, take this one: inference tells you what follows, validation tells you what is missing, and confusing the two produces a system that reports no problems because it was structurally incapable of finding any.

Then apply the first rule to the second mechanism as well. A constraint report saying that no mandate backs this right is a statement about your graph, not about your organisation. The mandate may exist and simply never have been recorded. Closing the world closes it over the data you happen to hold.

Nor will a reasoner tell you that two things are different. OWL makes no unique name assumption: two identifiers denote distinct things only once something says so. That matters more than it sounds, and it has a twin one level up, at the point where you write the rule.

A constraint checks what you told it to compare. The independence rule in my model, that the addressee of a challenge must not be the decider, compared the nodes. Two distinct roles held by the same person satisfied it and passed. The rule was formally impeccable and did not do what it was written to do. No formalism catches that class of error. A counterexample did, and only because someone went looking for one.

The two mechanisms also do not automatically share what they know. In my own validation runs the reasoner's inferences are not materialised at all, which means a class defined in the ontology as the union of two others has to be written out longhand in the constraint shapes. The ontology knows; the validator does not, unless something in between made it so.

Expressiveness has a price. The more a language lets you say, the less it can decide automatically and the slower it decides it. Almost all useful work sits far below the expressive ceiling, and reaching for the ceiling is usually a sign that the modelling question has not been narrowed enough.

And shared meaning only pays where it is shared. If one team, in one tool, maintains one model for its own use, an ontology is overhead. A metamodel and a firm discipline about naming will do. The investment starts earning at the point where several sources, several tools or several parties have to mean the same thing, or where software has to act on the model without a human present to repair the ambiguity.

The rule of thumb

A model says what we hold to be the case. A metamodel says how we are permitted to say it. An ontology says what the words mean, to anyone, including systems that have never met us.

Pick by the question you actually need answered, and resist the pull toward the most formal artefact available. But whichever you pick, none of them is self-maintaining, and none of them is true by construction. Correspondence to reality is not a property you can validate. It is a process someone has to run, repeatedly, and the most rigorous formalism laid over a stale fact produces nothing but a very well-formed falsehood.

More as the work develops.