Type level modeling can be easily done. Like any high-level concept map, everything written down can be compared to writing on a clean sheet of paper, or any empty blackboard: it’ll fit. There’s a Dutch saying, “Paper is patient,” meaning the paper will not protest or object to your writings.

Writing down “customer” and “product” and “purchase” and “location” on our paper is all too easy. The hard part is when you have to specify what that actually means, how to identify it, or even when to stop writing. When the domain is complicated and/or elaborate, the involvement of domain experts and subject matter experts is necessary in order for the universe of discourse to be understood.

List

Limiting the list of concepts to what is actually required can be hard. After that stage, the next step in decorating concept maps or conceptual models is to pose the question, “What do we register with that concept?”

Which attributes are supposed to belong to “customer” and which to “purchase” etc.? The list of attributes has no limits, except in the mind of the domain expert. As a modeler or business analyst, how do you determine where to stop?

Details

On a blank page, the conceptual model grows freely, and sometimes it grows beyond control or validation. Only when an actual logical or physical model is required will the real come to the surface: Which datatype should be assigned to an attribute? And are we sure? Is the attribute a single value, or can it be multiple at the same time? Do we need to insert another concept to organize the data structure, or remove it to prevent redundancy? Are the concepts subtypes or supertypes? Which concepts are supposed to be simple lookup tables in the implementation and which become a value constraint in the database?

These questions are relevant to the business but are only formulated when an IT process of design and development has begun. They may then be formulated in a technical format and from a technical perspective. The domain experts then have to understand and answer the specifics in IT jargon.

Fact Oriented Modeling

Fact-oriented modeling prevents difficult questions from appearing later, limits the scope of modeling, and validated the concepts as they are mentioned. It keeps the technical implementation aspects at bay while still allowing the business to verbalize their data in their own language.

Fact-oriented modeling enables the domain experts in the business (read: non-IT) to express the way they communicate about their data in their own language. It does not require any technical knowledge, or ability to read complicated diagrams with boxes and arrows. Yet, from the business-oriented fact models, tools enable the ability to derive technical diagrams and the generating of a wide range of implementation artifacts.

Domain experts are invited to express their data in their own language. The communication about their data is written down in the form of facts. Once sorted by kind and classified by type name, the modeling can begin. Below, you’ll find a few example fact types with their fact expressions:

Purchase: "Customer 98365 purchases order 201977877."

Order Date: "Order 201977877 is created on 2019/01/01."

Delivery Location: "Customer 98365 wants the order delivered to MAK1649129727."

It is important to understand that multiple fact expressions may exist per fact type. Multiple to support more than one example, but also multiple to allow different ways to verbalize the same fact. For instance, the method of fact-oriented modeling allows for another set of expressions to be easily added without altering the meaning of the information:

Purchase: "Order 201977634 is ordered by customer 78399."

Allowing various domain experts to phrase their facts is beneficial in making sure they are understandable and readable to a wider audience without resulting in a conflicting model. Not only are multiple phrases supported, but it also supports the alignment of various universes of discourse, and multiple languages at the same time.

Advantages

By allowing the expert to precisely verbalize a fact to illustrate its meaning, the following advantages arise:

• Fact Expressions are readable in natural language;
• Types are illustrated by real and concrete examples;
• Valuable and detailed business glossary are built;
• High quality models are continuesly checked for well-formedness;
• Fine grained editing of information models support both waterfall and agile approaches;
• Metadata on the smallest elements in the model support a high level of governance.

Start

Though Fact Oriented Modeling seems complicated and too detailed for some, it takes away confusion and contradiction in later development stages. The model is constantly validated by tools while expressions are added or changed. The constant feedback makes it possible to build high-quality information models from the start.

Once the modelers and business learn how to state facts in their own language, the maturity of the model is propelled to a higher level almost instantly. This not only improves the information model itself, but also the derived and generated artifacts required for system development. Readability is maintained throughout the process, while adjustments to the information model are made by adding and changing expressions. Governance on an expression level adds great insight to who said what, who modeled it, and who is the owner. Needless to say, the changes are monitored closely.

By preventing a clean slate to be filled by type level concepts without detailed descriptions, identifications, and examples, information modeling may seem tedious and difficult. However, nothing could be further from the truth. It simply requires you to be precise and answer all questions from the start, and not delaying them until a later stage where everything needs correction. This way, the seemingly hard beginning becomes the easiest path. All that is needed is to view it from a broader perspective.

More elaborate examples can be found here. This article has been published previously on linkedin.

Important Note

If you experience IT and Business misalignment, Fact Oriented Modeling may help dissolve that. If the cause of misalignment is an organization in disarray, that will be brought to the surface as well. Be aware that Fact Oriented Modeling makes IT talk to/with people, thereby mapping the knowledge of the business and everything that comes with it.