Marcel van Oosterwijk

Blog

  • Practice Note: Building on Established Reference Models

    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.

  • Practice Note: AI as an Enabler for Knowledge Synthesis

    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.

  • Practice Note: The New Bottleneck

    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.

  • Blog Retrospective #3

    I have now completed sixty posts.

    The first retrospective examined the writing process. The second examined the emerging theory of product quality assessment. This time, the most interesting development may not be found inside any individual field note. It is found in the relationships between them.

    What Happened?

    During this cycle, the field notes moved across a much wider range of subjects. Some continued the work on product reference models, Product Ownership and assessment. Others explored system continuity, understanding debt, documentation and the preservation of knowledge. Then the notes wandered into watches, clothing, writing, storytelling and AI-assisted thinking.

    At first glance, this might look as though the blog had started losing focus. Instead, something almost opposite happened. The same ideas began appearing in different places. A watch collection became an example of portfolio capability. A suit became an example of how an object can remain unchanged while its environment changes. A watch strap showed how changing a boundary changes what we perceive as the object. Inherited possessions became a way to understand the loss of system context. A comparison between two watches exposed the danger of replacing a reference model with a reference object.

    The subjects changed. The method did not.

    What Surprised Me?

    The biggest surprise was that everyday observations did not merely illustrate ideas already developed in the papers. They generated new ideas.

    The distinction between a reference model and a reference object emerged through a discussion about whether a Seiko could function as a dress watch. A Rolex may be one implementation of a dress watch. It is not the definition of one. Comparing another watch directly with it risks turning its particular design choices into assessment criteria.

    The same mistake appears in transformation projects when the new system is expected to look and work like the old system. The old system becomes the reference object. And not even an obviously good one. It is the system that must be replaced.

    That simple watch example made the software problem easier to see: We call it transformation, but make resemblance to the past the acceptance criterion.

    The field note then produced a refinement that belongs back in the more formal work: A reference model describes 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. The field notes have therefore become more than a way to communicate the theory.

    They have become a way to develop it.

    What Became Clearer?

    Several recurring patterns are becoming visible.

    The first is the separation of purpose from implementation. Requirements should describe required behavior, not merely reproduce an existing solution. Testing should verify behavior, not bind itself unnecessarily to implementation. Capability assessments should assess capabilities, not prescribe particular processes. Reference models should describe characteristics, behaviors and capabilities, not require resemblance to one preferred example.

    The second pattern is continuity of understanding. A system can survive while the reasons behind it disappear. Source code, documents and tickets may remain available, while the organization gradually loses the ability to explain why a business rule exists, why a trade-off was accepted or whether an unusual behavior is deliberate.

    This led to the idea of understanding debt: the accumulated gap between what the product embodies and what the organization can still explain with justified confidence.

    The third pattern concerns communication. Facts do not automatically form an argument. Sentences do not automatically form a thought. Documents do not automatically preserve knowledge. Structure, context and story are not decoration added after the “real work” is complete. They help make meaning reconstructable.

    The Field Notes Are Beginning to Reinforce One Another

    During the previous cycle, I noticed that the product-quality notes formed a chain. This time, the effect became broader. A note about documentation strengthens a note about understanding debt. A note about understanding debt strengthens the case for Product Continuity. A note about reference objects strengthens the distinction between capability and process. A note about storytelling explains why the more conceptual notes become easier to understand when they begin with watches, clothing or inherited possessions.

    Each note can still stand on its own. But later notes increasingly change how earlier ones are understood. The backlog is therefore no longer merely a queue of separate posts. It is becoming a body of work.

    What Changed in the Writing?

    The strongest recent notes often begin with something concrete and apparently insignificant. A watch. A suit. A photograph frame. An inherited object. A paragraph.

    The reader can follow the observation without knowing anything about assessment, Quality Management or transformation. Only after the principle has become visible does the note pivot toward software or organizations. That pivot is often where the note acquires its real meaning.

    Starting with transformation theory would require the reader to accept an abstraction. Starting with a watch allows the reader to discover the abstraction first. The professional problem is then judged by a principle the reader has already understood.

    This may be becoming the characteristic form of these field notes:

    Begin with an object.
    Discover a distinction.
    Follow it into another domain.
    End by revealing that the original subject was never really the subject.

    What Remains Unproven?

    The growing coherence is visible to me because I have followed every conversation and written every note. It is not yet clear whether it is equally visible to a reader encountering the posts individually.

    Several questions remain:

    • Can readers recognize the recurring method without being given a map?
    • Should related field notes be connected through synthesis pages or thematic collections?
    • Can the new concepts be incorporated into the assessment, Product Continuity and transformation papers without making those papers unnecessarily broad?
    • Do the everyday analogies clarify the professional ideas, or will some readers remember only the watches?
    • Do these distinctions improve actual assessment and transformation work?

    The theory is becoming richer. It must still become usable.

    What Comes Next?

    The next phase should probably combine continued exploration with more deliberate consolidation. The field notes can continue to capture new observations. There is no shortage of material.

    But several ideas now deserve to be carried back into the formal papers:

    • the distinction between reference models and reference objects;
    • the danger of confusing required behavior with one existing implementation;
    • understanding debt as the inability to explain what a product embodies;
    • documentation as the preservation of reconstructable meaning;
    • and field observations as a method for testing and refining conceptual models.

    The blog itself may also need stronger thematic routes through the material. The chronological stream shows when the ideas appeared. It does not necessarily show how they belong together.

    Conclusion

    After the first twenty posts, I discovered a writing process. After forty, I could see an emerging theory. After sixty, I am beginning to see the method connecting subjects that initially appeared unrelated.

    I thought I was collecting observations about quality, assessment, software, watches, clothing, writing and memory. Perhaps I was doing something else. Perhaps I was repeatedly asking the same questions:

    • What is this really for?
    • What characteristics matter?
    • What should remain stable when the implementation changes?
    • What knowledge must survive?
    • How can we make the reasoning visible enough for someone else to continue it?

    The individual field notes are becoming stronger. But their real strength may be that they are no longer entirely individual.

    .

  • Practice Note: The Danger of Reference Objects

    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.