A recurring idea in this body of work is that organizations need an explicit reference if they want to preserve, develop and assess understanding over time.
Without such a reference, understanding gradually becomes implicit. People leave. Context disappears. Decisions remain while their rationale is forgotten. Eventually, whatever happens to survive — an existing system, a process, a framework, a set of requirements — may become the implicit definition of what should exist.
The Reference Model provides an alternative. It makes important concepts, relationships, expectations, assumptions and boundaries explicit enough that future people do not have to reconstruct everything from the realization itself.
But there is a potential problem with this argument. If documentation does not preserve understanding simply because it exists, why should a Reference Model?
It should not. A Reference Model is necessary for Continuity, but it is not sufficient.
Making Understanding Explicit
The first step toward preserving understanding is making enough of it explicit.
This is important because artifacts tend to survive longer than the reasoning that created them. A system may continue operating long after its designers have left. A capability may retain its processes after nobody remembers why they were introduced. A product backlog may continue evolving after its connection to the original product intent has weakened.
A Reference Model helps by separating the intended understanding of the subject from its current realization. That creates a stable point from which the subject can be developed and assessed without treating the current implementation as the definition of what is correct.
But making understanding explicit is not the same as preserving it. A Reference Model is itself an artifact. It can survive while the understanding required to interpret it disappears.
A Model Must Remain Interpretable
Imagine finding a carefully structured Reference Model ten years after it was created. The concepts are still there. The relationships are documented. Important expectations are described. Nothing has been deleted.
Yet some of the terminology has changed. Several concepts no longer mean quite what they once did. Assumptions that were obvious to the original authors are no longer obvious to the current organization. Nobody remembers why one relationship was considered significant while another was deliberately excluded.
The model survived. Its interpretation did not.
This is the same problem that affects ordinary documentation. Preserving information does not automatically preserve the context required to reconstruct its meaning.
A Reference Model therefore needs more than correct statements. Where necessary, it must preserve enough rationale, assumptions, definitions and context for future people to understand what those statements were intended to mean.
Otherwise, the model may remain readable while becoming progressively less understandable.
A Model Must Remain Connected to Reality
There is another risk. Once a Reference Model becomes authoritative, its contents can begin to acquire authority simply because they are in the model.
An expectation may originally have been based on operational evidence. An assumption may have reflected a particular business condition. A relationship may have been inferred from several observations. A constraint may have represented a deliberate decision rather than an unavoidable fact.
Over time, those distinctions can disappear.
Eventually someone asks:
Why do we believe this?
And the answer becomes:
Because it is in the Reference Model.
At that point, the mechanism intended to prevent Reference Substitution risks becoming a Reference Object itself.
A Reference Model should therefore remain connected, where relevant, to the basis for its claims. That does not mean every statement needs an academic citation. It means that important distinctions between observation, evidence, assumption, decision, interpretation and intent should not disappear simply because they have been synthesized into a model.
Agreement does not solve this problem either. An entire organization may agree with what the Reference Model says. That agreement is useful evidence that the model represents shared understanding. It is not necessarily evidence that every claim within the model remains correct.
The Reference Model must remain open to challenge from evidence.
The Boundary Must Be Explicit
No Reference Model can contain everything.
The moment we describe a product, capability, system or body of knowledge, we make decisions about what belongs inside the subject and what remains outside it. Those decisions matter because the boundary helps define the object being understood.
Without an explicit boundary, absence becomes ambiguous. If something is missing from the Reference Model, is it outside the subject? Was it deliberately excluded? Is it considered insignificant? Is it unknown? Or did somebody simply forget it These possibilities have very different meanings.
A useful Reference Model therefore needs an explicit subject and sufficiently clear boundaries. Not because boundaries can eliminate every ambiguity, but because they allow people to reason about what the model claims to represent.
Before asking whether a Reference Model is complete, we need to know what it is intended to be complete about.
The Problem of Appropriate Abstraction
Reference Models need abstraction. If a Capability Reference specifies a particular process, role structure and toolset as the definition of good capability, it may prevent legitimate alternative realizations.
If a Product Reference simply reproduces the current architecture, requirements and behavior, the existing product becomes the model for its own future. The Reference Model has then become too concrete. Instead of preserving intent independently of realization, it preserves the realization.
But abstraction has an opposite failure mode. Consider a Capability Reference that says an organization should have effective governance, appropriate competence, efficient processes and continuous improvement. It is difficult to disagree with. It is also difficult to do much with.
What would distinguish a strong realization from a weak one? What evidence would matter? What should Development attempt to improve? What exactly should an assessor assess?
Excessive abstraction can make a Reference Model universally acceptable precisely because it no longer makes sufficiently meaningful distinctions.
The challenge is therefore not to maximize abstraction. It is to find the appropriate abstraction.
A Reference Model should be abstract enough to permit alternative realizations, but specific enough to distinguish meaningful alternatives.
This principle applies beyond any particular domain.
A Capability Reference must avoid prescribing one organizational implementation while remaining specific enough to describe meaningful organizational ability.
A Product Reference must remain independent of today’s implementation while being concrete enough to guide Development and Assessment.
A model of a body of knowledge must allow understanding to evolve without reducing that understanding to principles so generic that the observations, relationships and reasoning that gave them meaning disappear.
The object changes. The problem remains the same.
A Model Must Be Maintained Through Learning
Even a well-bounded, appropriately abstract and interpretable Reference Model eventually becomes outdated if understanding continues to evolve while the model does not.
New evidence appears.
Operational experience challenges assumptions.
Assessments reveal weaknesses in the reference itself.
Development creates possibilities that were not previously considered.
The environment changes.
Stakeholders learn that they value something differently than expected.
A Reference Model that cannot change eventually stops representing current understanding.
But simply updating it creates another Continuity problem. If yesterday’s model says one thing and today’s says another, future people may need to understand not only what changed but why.
Otherwise maintenance preserves the latest answer while destroying the reasoning that connects one state of understanding to the next.
A living Reference Model therefore needs stewardship.
Changes should be deliberate. Important revisions should remain reconstructable. New evidence should be able to challenge old assumptions. Learning should feed back into the reference rather than accumulating elsewhere until the model gradually drifts away from what the organization actually knows.
Continuity does not require the Reference Model to remain unchanged. It requires understanding to remain continuous while the Reference Model evolves.
The Reference Model Is Not the Understanding
This leads to an important qualification.
A Reference Model does not contain organizational understanding in the same way that a database contains records.
Understanding exists through the relationship between the model, the evidence behind it, the context in which it is interpreted, the people who use it, the realizations it guides and the learning that changes it.
The Reference Model gives that understanding structure.
It makes important parts explicit.
It provides an independent reference for Development and Assessment.
It helps future people reconstruct why the subject is understood in a particular way.
But the artifact itself is not Continuity.
A perfectly preserved Reference Model can still become incomprehensible, outdated, disconnected from evidence, incorrectly scoped or so abstract that it ceases to guide meaningful judgment.
The same lesson that led to Reference Models therefore applies to Reference Models themselves.
Artifacts do not preserve understanding merely because they survive.
A Reference Model does not preserve understanding by itself.
It creates a structure through which understanding can be preserved, challenged, developed and continued over time.
Leave a Reply