architects

Design at the conceptual level, generate technical artifacts automatically. Bridge enterprise architecture with database implementation.

generation capabilities

From one conceptual model, CaseTalk generates multiple technical outputs:

Architecture articles

• Canvas Helpers

  A working library of canvases for strategic planning, semantic modelling, data governance, and AI delivery — designed to integrate with CaseTalk and the architectural work around it. Free to use, as a thank you to the architects and modellers who care about getting meaning right, and as a tribute to the original authors behind each canvas. The canvases are grouped here by where they sit in a typical journey: Why the work exists, Who is involved, What the subject matter actually is, and How the resulting model is delivered, governed, and put to use.

• What we lost when Datum became Data

  On etymology, semantic drift, and why the words we choose for data shape the systems we build A Word That Carried Its Own Philosophy In Dutch, the everyday word for data is gegevens . It is not a technical term. Any citizen uses it naturally, without a second thought. And yet it encodes something profound: gegevens are things given — handed over, recorded, established by someone, for someone, with intent. The English word ' data ' has the same Latin root. Datum means ' something given '. But that etymology is effectively dead in English practice. Nobody says "one datum" anymore. Nobody asks "given by whom, for what?" The word has shed its own origin. What remained is a term that implies objectivity, neutrality, and independence from any observer. Data just exists. It is out there. You collect it, store it, analyse it. The act of creation — the who, the why, the context — has quietly disappeared. That disappearance has consequences.

• Against the stream

  Why Most "Business Language" Artifacts Flow the Wrong Way TL;DR — Most artifacts that claim to speak "business language" — DDD context maps, OWL ontologies, Gherkin scenarios, DSLs — are built from the technical side and traveled toward business readability. They flow against the current. Genuine business language originates from the natural sentences domain experts actually use, and is formalized from there toward technical implementation. The direction of derivation is not a detail. It determines whether a model is owned by the business or merely legible to it.

• From Ambiguity to Precision

  The Journey from 'Customer → Order' to a Formal Semantic Layer Consider five ways to represent the same business reality: Customer → Order Customer has Order Customer buys Order The person places order . "The person or organisation, identified in our system as customer number 123, placed an order for our products or services identified by order number 20260991." The final expression isn't just "better documentation"—it's the foundation of a semantic layer : a formal, structured representation of business knowledge that sits between your SMEs' expertise and your data systems. This semantic layer is the result of applying FCO-IM (Fully Communication-Oriented Information Modeling), not just an improvement in notation.

• FCO-IM - A layered hypergraph

  Why Hypergraphs? Most graph databases and modeling tools are built on simple graphs — nodes connected by edges, where each edge links exactly two nodes. This works fine for binary relationships, but conceptual modeling demands more. In FCO-IM, a fact type like "Person works at Company in Role" is a ternary relationship — it connects three object types simultaneously. Splitting this into binary pairs (Person-Company, Person-Role, Company-Role) destroys the original semantics. The fact is atomic : all three participants are bound together in a single assertion.

• FCO-IM Is Not Telling You What to Build

  Solution Architects are trained to design. They come to a project with experience, patterns, and hard-won instincts about how systems should be structured. When a formal model lands in their hands, their first instinct is a reasonable one: does this tell me how to build it? And when it seems to, the friction begins. This is the misreading that costs organizations dearly. FCO-IM artifacts — the outputs of CaseTalk's fact-oriented conceptual modeling process — are not architectural mandates. They are not database schemas dressed up in business language. They are something more fundamental, and more valuable: a precise, validated record of how the business talks about its data. "FCO-IM doesn't design your solution — it defines the business reality your solution must respect." That distinction matters enormously. A Solution Architect is free to implement a star schema, a graph database, a microservice mesh, or an event-driven platform. The FCO-IM model does not care. What it does care about — what it was built to preserve — is whether the distinctions that matter to the business survive the translation into technology.

• The Data That Doesn't Know What It Means

  How entity modeling quietly discarded the meaning AI is now desperately trying to recover The Billion-Dollar Semantic Recovery Project There is a quiet crisis at the heart of enterprise AI adoption, and almost nobody is naming it correctly. Organizations are investing heavily in semantic layers, knowledge graphs, ontologies, and AI-powered data catalogues. The pitch is always some variation of the same idea: we will make our data understandable — to machines, to analysts, to the business. We will surface meaning from our data assets. What is rarely said out loud is the uncomfortable premise underneath all of that investment: the data doesn't already know what it means. That is not a technology problem. It is not something a better LLM will fix, or a richer graph schema, or a more expressive ontology language. It is a modeling problem — specifically, a problem that was baked in decades ago when organizations chose how to represent information, and what to keep and what to throw away. This article is about what was thrown away, why it is so hard to get back, and why there is a family of modeling approaches that never threw it away in the first place.

• FCO-IM Changes the Conversation

  Data modelers trained in the conceptual/logical/physical paradigm often struggle to grasp what fact-oriented modeling — and FCO-IM in particular — actually offers. This isn't a failure of intelligence; it's a collision of mental models. Traditional data modeling treats structure as the primary artifact. Fact-oriented modeling treats semantics as primary, with structure as a derivable consequence. This distinction matters enormously when we move from project-level modeling to enterprise-scale concerns.

• Titanic Data (Model)

  On many conferences where AI, ML or data science is mentioned, a simple dataset is used to underpin the storyline of the sessions. The Titanic dataset is such a relatively small and simple example. Until now a Fact Oriented Model was absent. So, let's see how we can build one out of the dataset by verbalizing it.

• Governance with DMBOK

  The DAMA organization has created an enormous body of knowledge called the Data Management Body of Knowkledge ( DMBOK ). In version 2 they introduced Fact Oriented Modeling for the first time. Both ORM and FCO-IM are condensely described. To illustrate how governance is central in the huge field of data management is shown by the DMBOK Wheel.

• Foreign Keys are easy

  Every now and then a discussion arises on social media, or during a conference meet-up, where the conversation or question focusses on the topic of Foreign Keys. Traditional modelers seem to occasionally struggle with foreign keys in respect to one-to-one, one-to-many, and many-to-many characteristics, or the minimal and maximum cardinality, or its direction. This is not a big issue in Fact Oriented Modeling, since foreign keys are simply generated from a conceptual model. Foreign keys are a result of fact types and their transformations. The direction and cardinalities of the foreign keys are determined by simple rules from the conceptual model.

• Advantages of Fact Based Modeling

  In the realm of data modeling, the FCO-IM (Fully Communication Oriented Information Modeling) method has emerged as a powerful successor to the well-established NIAM (Natural Information Analysis Method). Both approaches rely on the use of natural language to construct data models. FCO-IM, however, takes this methodology a step further, offering numerous advantages that make it an ideal choice for creating elegant and highly adaptable models, all the while ensuring ease of validation by both business experts and users.

• Full Data Architecture

  Information architecture distinguishes between different layers and compartments, each with specific models. The compartments are then ordered and their models aligned. This article described the compartments and models influenced by CaseTalk and by Fact Based Modeling.

• Transformation of Models

  A conceptual information model of the business is a great asset, as well as a solid investment due to it being independent of technology. Since IT undergoes rapid changes, the only truly long-living asset is the information model.

• Zachman Framework

  Information systems are meant to automate the repetetive tasks of the employees of your business. Systems administer data relevant to it's business owners and users (E.g.: people, places, things, events and reasons). Designing these systems requires lists of datamodels, proces models, database models, schemas and diagrams with object classes, procedures, documentation sets, and lots more.

• Why Communication Matters

  Fully Communication Oriented Information Modeling (FCO-IM) emphasizes modeling the communication aspect of data. Employees constantly exchange facts through communication, such as "Invoice 1238 has an invoice date 1-1-1999". FCO-IM models such communication and facts in natural language. This article highlights the importance of communication in developing a fact-based data model.

Tool integration

• When Your Information Model Speaks Back

  CaseTalk Version 15 Live Demo At a recent DAMA South Africa session, CaseTalk founder Marco Wobben demonstrated how upcoming version 15 of the information modeling tool bridges the gap between conceptual modeling and Large Language Models — turning static data models into interactive, AI-powered knowledge systems. The headline feature: CaseTalk now integrates with multiple LLMs (Claude, ChatGPT, Mistral, and others) via the Model Context Protocol (MCP), allowing AI agents to read, query, and reason about your information model in real time. What does that mean in practice? An AI That Understands Your Business — Not Just Language

• Supporting ER/Studio

  Idera ER/Studio is a data modeling tool with a modern interface, supporting a wide range of databases. CaseTalk supports the logical data models using a script generator. Generated script can simply be executed inside ER/Studio in order to have the logical model automatically build for you.

• Supporting PowerDesigner

  PowerDesigner is a tool used by many data architects. CaseTalk strengthens them by using language, well-documented entities, and tables. However, if your goal is simply to draw a relational diagram, you should perhaps consider using the CaseTalk Viewer.

• Denodo Data Virtualization

  Denodo is a Data Virtualization environment that simplifies the process of moving data from one place to another. This is done through configurable layers containing various views, which are based on table definitions that live in source systems. The upper layers of views should represent business needs and require solid data modeling. These layers act as an interface, and are usually designed top-down, meaning fields are first defined and the implementation (data) of the interface is associated later.