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

• 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

• 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.