Category: Practice Notes

The term reference model is already well established within systems engineering, enterprise architecture and other engineering disciplines. It generally refers to an abstract representation of a domain that defines concepts, their relationships and a common frame of reference while remaining independent of a particular implementation.

For readers unfamiliar with the concept, the Wikipedia article provides a concise overview of the commonly accepted definition:

https://en.wikipedia.org/wiki/Reference_model

This Practice Note does not attempt to redefine what a reference model is. Instead, it establishes the perspective adopted throughout this body of knowledge.

Many reference models successfully describe what exists. They identify concepts, components and relationships. They provide a shared vocabulary and a structural understanding of a domain.

In practice, however, organizations face a different challenge. Over time, the structure often survives while the understanding behind it gradually disappears. Documentation remains available, yet the reasoning that shaped it becomes difficult to reconstruct. New team members can read the model without fully understanding why it exists, what assumptions influenced it or under which circumstances it should evolve.

From the perspective of these Practice Notes, a reference model is therefore valuable not only because it represents a domain, but because it enables the continuity of understanding of that domain.

Three questions become particularly important.

• Does the model preserve the intent behind its concepts and relationships?
• Can its meaning be reconstructed when context has been lost?
• Can the model evolve without losing the reasoning that originally made it useful?

These questions extend beyond documentation. They concern the preservation of organizational knowledge and the ability to make informed decisions as organizations, products and capabilities evolve.

The Practice Notes therefore build upon the established concept of a reference model rather than replacing it. Their contribution is to explore how reference models can support continuity of understanding, deliberate development and defensible assessment throughout the lifecycle of organizations, capabilities and products.

Future reference documents in this body of knowledge adopt this perspective as their foundation.

While continuing to add new Practice Notes to the growing body of knowledge on this blog, I found myself wondering how each new insight would affect the publications we were in the process of creating.

A single new observation might strengthen an argument in a derived theoretical paper. Another might influence the capability methodology. A third might require changes to the product guidance, consulting offering or training material.

Each new Practice Note had the potential to affect several different publications.

Initially, this seemed perfectly reasonable. Then another thought occurred to me.

What if I had to perform all of those updates manually?

Every new insight would require reviewing multiple publications to determine whether they should be updated. Every update would require checking whether the same insight should also appear elsewhere. Every publication would gradually become another artifact requiring maintenance. As the body of knowledge continued to grow, so would the effort required to keep all of those representations aligned.

At that moment I realized something important.

The challenge was not maintaining the knowledge. The challenge was maintaining all of its representations.

The previous Practice Note proposed maintaining a single canonical body of knowledge and generating all other knowledge assets from periodic Knowledge Snapshots.

Conceptually, this governance model is straightforward: practice Notes become the authoritative source, Knowledge Snapshots provide stable baselines. Publications, methodologies, training material and consulting offerings become derived representations of that knowledge.

While this may work in theory, the question is whether it is practical. Historically, the answer would often have been no. The bottleneck wasn’t the creation of knowledge, but the repeated synthesis of that knowledge into many different representations.

Every publication required manual interpretation. Every revision required manual consistency checking. Every new insight increased the cost of keeping the knowledge assets aligned. The governance model was sound, but the economics were not.

Recent advances in AI fundamentally change the economics of knowledge synthesis. AI is exceptionally well suited to transforming an existing body of knowledge into multiple coherent representations for different purposes and audiences.

This is a fundamentally different role from creating knowledge. Knowledge continues to originate through experience, observation, experimentation, discussion and reflection.

AI enters the process only after that knowledge exists. Its contribution is synthesis.

This distinction is important.

Organizations learn through experience. People make observations. Teams discover better ways of working. Experts refine concepts and challenge assumptions. Those activities create knowledge.

Once that knowledge has been captured, however, another activity begins. The knowledge must be organized. Synthesized. Presented. Explained. Adapted for different audiences. Connected to existing concepts. Translated into methodologies, publications, training material and consulting guidance. This is knowledge synthesis.

For many organizations, synthesis has traditionally been the most expensive part of knowledge management.

The governance model described in the accompanying Practice Note becomes practical because the economics of synthesis have changed.

Rather than manually maintaining many independent artifacts, organizations can maintain one canonical body of knowledge and periodically regenerate derivative assets from approved Knowledge Snapshots.

Those assets may include:

• conceptual publications;
• capability descriptions;
• product guidance;
• assessment methodologies;
• consulting playbooks;
• training material;
• onboarding guides;
• indexes;
• traceability matrices;
• AI assistants.

Human effort shifts accordingly. Instead of maintaining documents, people improve understanding. Instead of synchronizing publications, they enrich the canonical body of knowledge. The cost of regeneration decreases dramatically.

The governance model itself remains technology independent.

Organizations still require:

• stewardship;
• critical thinking;
• peer review;
• traceability;
• professional judgement;
• continuous learning.

AI does not determine what becomes organizational knowledge. It does not decide which observations are significant. Those remain human responsibilities.

AI helps synthesize the resulting knowledge into coherent and consistent representations.

Without governance, AI simply produces more content. With governance, AI enables organizations to preserve continuity while continuously communicating an evolving understanding.

This observation extends beyond the framework described in these Practice Notes.

Any organization maintaining professional disciplines, methodologies, capability frameworks, operating models or enterprise knowledge faces the same synthesis challenge.

As AI reduces the cost of synthesis, organizations gain an opportunity to redesign how they govern knowledge.

Rather than maintaining many independently evolving artifacts, they can maintain one authoritative body of knowledge and regenerate the representations required for different purposes.

This improves consistency. It improves traceability. Most importantly, it improves continuity of understanding.

As a consequence of using AI in my writing, the cost of writing has decreased dramatically. An idea that once required several evenings of outlining, drafting, rewriting and polishing can now become a coherent paper much faster. Arguments can be tested in different forms. Weak transitions can be repaired. Examples can be added. Alternative structures can be explored without starting again from scratch. For that, I am incredibly grateful.

But one important cost has not decreased nearly as much: the cost of serious review. A reviewer still has to read the paper carefully. They still have to understand the argument rather than merely recognize the words. They may also use AI, but that’s not enough.

They still have to compare the claims with their own experience, identify hidden assumptions, notice contradictions, challenge weak reasoning and decide whether the model is actually useful. That takes time. More importantly, it takes qualified attention.

AI can help produce more documents, or more incremental versions of the same documents. It does not automatically create more people willing and able to judge whether those documents deserve to be trusted.This changes the bottleneck.

Previously, writing itself limited how much material could be produced. If creating a paper took months, review requests were naturally infrequent. Now drafting is cheaper. A paper can be improved repeatedly, and new versions can appear almost whenever a new insight emerges. That sounds positive. Until every small improvement is sent to the same colleagues for another serious review.

The cost of producing the new version may have become low. The cost imposed on the reviewer has not. That creates a new responsibility for the writer. Cheap drafting should not lead to expensive review churn.

I may revise a paper privately many times. I may collect new examples, conceptual distinctions, field observations and corrections in a backlog. But a new version should only be published when those changes together create a significant improvement.

Not merely better wording. Not one extra paragraph. Not version 1.04 because I had another thought on Tuesday. A new review should be worth the attention it asks for.

This suggests a simple structure. Field notes can remain the exploratory layer. They capture observations while they are fresh. Several notes may begin pointing in the same direction. The stable insight then enters the backlog for the relevant paper. Only when enough important changes have accumulated does the formal paper absorb them and become a genuinely new version.

The production cycle becomes faster. The release discipline should become stricter. This applies far beyond my own papers.

Organizations can now produce reports, proposals, strategies, requirements, policies and presentations at unprecedented speed. Much of it will be polished, plausible and professionally written. But polished language is not the same as sound reasoning. And increased output does not create increased capacity for careful judgment.

The danger is not only that AI will produce poor documents. It is that it will produce more documents than anyone can seriously assess. The scarce resource is shifting from creation to judgment.

The cost of producing documents has collapsed. The cost of deciding whether they deserve to be trusted has not.

Is, let’s say, a Seiko Presage Sharp Edged suitable as a dress watch? One way to answer that question is to find an undisputed dress watch—perhaps a Rolex—and compare the Seiko against it. The Rolex may be thinner. More restrained. Its dial may be simpler, its case less assertive, its overall appearance more traditional. Conclusion: the Seiko is not a dress watch.

But something has gone wrong. We did not assess whether the Seiko was suitable as a dress watch. We assessed whether it resembled the Rolex.

The Rolex became a reference object.

That matters because a Rolex is not the definition of a dress watch. It is one implementation of a dress watch. Its proportions, materials, dial layout and styling are particular design choices through which it realizes certain characteristics. By comparing the Seiko directly with the Rolex, we quietly turn those choices into assessment criteria.

We are no longer asking:

Does the Seiko possess the characteristics of a dress watch?

We are asking:

Does the Seiko implement those characteristics in the same way as the Rolex?

A better approach is to define the typical characteristics of a dress watch.

Perhaps:

• restrained proportions;
• an elegant case;
• a leather strap;
• limited complications;
• an appearance that complements rather than dominates formal clothing;
• and the ability to fit comfortably beneath a shirt cuff.

Now we have something closer to a reference model.

Against those characteristics, the answer becomes more interesting. The Seiko may not be the purest or most traditional dress watch. Its case and dial may be more expressive than the classical ideal. But it satisfies enough of the relevant characteristics that it can reasonably function as one. So yes: perhaps it is at least kind of a dress watch.

The assessment changed because we stopped comparing to a reference object and started measuring against a reference model.

Now turn to software. What are the requirements for the new system?

“We don’t really have proper requirements. We don’t have the time, money or capability to define them. But the new system should look and work like the old system.”

So the old system becomes the reference object. The same old system that must be replaced.

Now, with considerably more money at stake, we make exactly the same mistake again. The old system is one implementation of the required business behavior. But instead of identifying that behavior, we copy the implementation. Its screens become requirements. Its workflows become requirements. Its terminology and data structures become requirements. Even its limitations, workarounds and historical accidents risk becoming requirements.

Apparently, the old system is not good enough to keep—but its implementation is good enough to copy. The irony is difficult to miss.

A transformation project begins because the current system is no longer suitable, then uses that same system as the model for the future. We call it transformation, but make resemblance to the past the acceptance criterion.

Of course, the old system can still be useful. It may contain valuable examples, business terminology, accumulated knowledge and behaviors that must not be lost. But it should help us discover the reference model, not replace it.

The real questions remain:

• What must the new system enable?
• Which outcomes must it support?
• Which behaviors must remain possible?
• Which characteristics must it possess?
• Which constraints still matter?
• Which parts of the old system were merely consequences of one particular implementation?

A reference model describes the required behavior and characteristics.

A reference object shows one possible implementation of them.

When the reference object replaces the reference model, one implementation quietly becomes the requirement. And QA verifies the implementation rather than the required behavior.

For years I tried to make my reports correct. Then I tried to make them complete. Eventually, I realized I wanted something else: I wanted them to be skön att läsa—enjoyable to read. At first, that sounded almost inappropriate. A report is supposed to be factual, objective and complete. It isn’t supposed to compete with a novel. Or is it?

Looking back over years of writing reports and giving presentations, I noticed a pattern. Of the many presentations I have delivered, those that received the strongest engagement were rarely the ones in which I tried hardest to explain every fact. They were the ones in which I unintentionally told a story. Not fiction. A real story.

Those presentations felt different. I was more relaxed. I wasn’t constantly wondering whether I had forgotten a fact or whether someone would misunderstand a definition. I simply invited the audience to walk the same path that had led me to the insight. The audience seemed to enjoy that journey as much as I did.

Only recently did I realize that the same principle applies to writing. Many technical reports feel like collections of facts. Everything is correct. Everything is complete. Yet reading them feels like climbing a staircase while carrying boxes. Every page asks the reader to do more work. What if the facts themselves are not the problem? What if the problem is that they have no journey to travel on?

The reader keeps asking:

“Why are you telling me this?”

A story answers that question naturally.

Ironically, storytelling may be one of the most effective ways to communicate technical ideas. Not because it simplifies them. But because it makes understanding feel effortless. A story does not replace facts. It gives the facts somewhere to live.

Yet storytelling and style are often treated as luxuries for which professional work has no time.

“Don’t waste my time. Just give me the facts.”

But facts without a story do not eliminate the work of creating meaning. They merely leave that work to the reader. Making a report skön att läsa takes time. Framing a presentation as a story takes time.

So does trying to understand a report whose writer decided that readability was a luxury.

So does trying to make sense of a presentation that is merely a wall of facts.