Knowledge Hub

Visionaries and business users thought that because they understand their business, know their problems, understand their use cases, and now have Vibe Coding and AI-assisted development at their fingertips, they could build things themselves.

So they began asking:

"Why do we need Data people? We understand the business. We know what we want to build. And AI can help us build it."

And to be fair, the early results look promising.

POCs went well.
Pilots went well.
Applications were built. Dashboards were created. Workflows were automated.

Everyone is excited.

But now comes the interesting part.

• Now it's time to bring in the actual enterprise data.

• Now it's time for proper user acceptance testing.

• Now it's time to fix data quality issues that nobody noticed during the POC.

• Now it's time to optimise the code because compute consumption is increasing, cloud costs are approaching budget limits, and the expected ROI is taking a hit.

• Now it's time to optimise storage, remove unnecessary data duplication, and manage growing volumes.

• Now it's time to integrate with existing enterprise systems, deal with incompatible data structures, and resolve dependencies.

• Now it's time to migrate from legacy technologies to newer platforms without disrupting business operations.

• Now regulatory bodies are asking questions. We need to produce compliance reports, demonstrate data lineage, maintain audit trails, and prove where the data came from and how it was transformed.

• Now business leaders want transparent and trusted KPIs. We need to reconcile different definitions, validate calculations, and ensure everyone is looking at the same numbers.

I have seen organisations invest years building data platforms, introducing new technologies, and expanding their enterprise architecture. Over time, these investments become part of the technology landscape.

Then something interesting happens.

A new platform is introduced, but the old one stays. A new data warehouse is built, but the previous warehouse continues running. A new reporting solution is launched, but business users still depend on the old reports. Another integration layer is added because replacing the existing one is considered too difficult.

Eventually, the organisation is operating multiple generations of technology, often solving similar problems in slightly different ways.

And nobody really wants to switch anything off.

There are understandable reasons. Dependencies are complicated, business users are comfortable with existing systems, migration carries risk, and nobody wants to be responsible for an outage.

Enterprise data architecture is failing. Not because organizations lack investment, or because the problem is inherently too complex, but because the structure required to hold these ecosystems together is either weak or absent. As data landscapes stretch across domains, platforms, and workloads, coherence simply does not sustain itself. Below diagram show the potentiate challenges faced by different persona(s) in an organization.

Over the past decade, there has been no shortage of progress. Cloud-native platforms, lakehouse patterns, distributed processing, governance tooling - none of this is immature anymore. And yet the outcomes tell a different story. Environments expand, but alignment erodes. Governance becomes more visible, more documented, more discussed - but less effective in practice. Analytical capability grows, but trust lags behind, sometimes significantly. These are not isolated execution failures. They point to something more fundamental.

A new but very known term, folks from Data World are aware of Metadata but Meta Metadata is something which is just surfaced the Data World and for me it’s again a game changer.

Let’s decode it…..

We all know what Metadata is, it’s Data About Data. Please refer to the Metadata as separate topic in this book.

Let me try to make it as simple as possible with a few examples.

For example, a column i.e., Data Of Birth (DOB) is technical metadata right? Now, when we go to the next level and tag, this DOB is for parents, children, for employees or for insurance policy maker that make the DOB attribute more relevant.

Another example can be Weight column, now value in this field is in numbers or digit but by looking in the value we can’t make it out whether this weight is for a person or an object, and further which object e.g., furniture or something else etc.

Giving more info about Metadata is called Meta Metadata.

Domain-Driven Design, commonly known as DDD, is an approach to modelling and system design that starts by deeply understanding the business domain. The term domain refers to the problem area the business is working in, such as banking, healthcare, education, or retail. DDD Modelling focuses on capturing the key business concepts, rules, and meanings, and making sure both business people and technical teams talk about them in the same way.

The main goal of DDD Modelling is to ensure that system design closely reflects real business needs. Instead of designing systems based only on technical convenience, DDD encourages teams to model software around how the business actually operates. When done correctly, the system grows naturally alongside the business, rather than becoming disconnected from it.

A central idea in DDD is the creation of a shared or ubiquitous language. This means that the same terms are used consistently by business experts, analysts, and developers. When a business person says “approved loan,” the developer and the analyst understand exactly what that term means, without needing further clarification. This shared language reduces misunderstandings and makes collaboration much easier.

Information Modelling is the discipline concerned with how information is described, structured, and communicated so that it can be clearly understood and consistently interpreted by people, processes, and systems. Its focus is not on technology or databases, but on ensuring that the meaning of information is precise and unambiguous.

The primary goal of Information Modelling is to achieve semantic clarity. When information is clearly defined and consistently represented, it can be exchanged reliably across departments, systems, and even organizations. This clarity is essential for effective collaboration between business and IT, as well as for building systems that truly reflect business intent.

Information Modelling concentrates on capturing facts, terms, and relationships in a structured and rigorous way. It emphasizes meaning over implementation. Instead of asking how data will be stored, it asks what facts exist in the business, how those facts are expressed in language, and how they relate to one another. Because of this, Information Modelling acts as a bridge between business communication and data modelling.

NIAM, which stands for Natural Language Information Analysis Method, is an early fact-oriented approach to Information Modelling that was developed in the 1970s and 1980s. Its key idea is simple but powerful: business information should first be expressed in plain natural language before being transformed into formal models. By doing this, NIAM allows business users to understand and validate information models without needing technical knowledge.

• NIAM originally stood for “Nijssen’s Information Analysis Methodology.” This refers to the fact-based modeling approach developed by G. M. Nijssen in the 1970s. 
• Later on, the acronym was generalized to “Natural Language Information Analysis Method.” This change was made because many people contributed to the method, not just Nijssen, and to emphasize its basis in natural language. 

The primary goal of NIAM is to capture business information in a way that is both easy to understand and structurally precise. Instead of starting with diagrams or tables, NIAM begins with sentences that describe facts about the business. These sentences reflect how people naturally talk about their work, making it easier to confirm whether the model accurately represents reality.

Object-Role Modelling, commonly known as ORM, is a fact-oriented conceptual modelling method that represents information as objects playing roles in facts. Unlike traditional data modelling approaches that focus on attributes or tables, ORM treats facts as the core building blocks of information. Each fact describes how one or more objects participate in a relationship.

The main goal of ORM is to provide a precise and expressive way to capture business information and rules directly in the model. It allows modellers to describe not only what facts exist, but also the constraints that govern those facts. This makes ORM particularly useful in environments where accuracy, consistency, and clarity of business rules are critical.

ORM builds on the ideas introduced by NIAM but adds much stronger structure and formality. In ORM, every piece of information is modelled as a fact type. For example, instead of saying that an employee has a department attribute, ORM represents the information as the fact “Employee works for Department.” In this statement, both Employee and Department are objects, and “works for” describes the roles they play in the fact. This approach keeps the model close to business language while making relationships explicit.

Fully Communication Oriented Information Modelling, commonly referred to as FCO-IM, is a modern fact-oriented information modelling method that focuses on capturing information exactly as it is communicated in natural language. Developed from the 2000s onward, FCO-IM addresses a long-standing problem in modelling: the loss of meaning that often occurs when business statements are translated into technical models.

The primary goal of FCO-IM is to eliminate the gap between business communication and technical design. Instead of forcing business facts to fit immediately into predefined structures such as entities and attributes, FCO-IM records facts in their original verbal form. These verbalized facts are then systematically transformed into formal models, ensuring that nothing is lost or reinterpreted along the way.

Unlike earlier modelling approaches, FCO-IM treats communication itself as the object of modelling. It recognises that business knowledge is first expressed through spoken or written sentences. These sentences carry nuances, timing, responsibility, and intent that are often weakened or removed when models jump too quickly into abstraction. FCO-IM preserves this richness by treating each sentence as a first-class modelling artefact.

Ontology or Knowledge Modelling is the practice of defining a formal and structured representation of knowledge within a domain. It identifies the important concepts, shows how they are related, and defines rules that govern those relationships. The purpose is to create a shared understanding that can be interpreted consistently by both humans and machines.

The main goal of Ontology Modelling is to build a framework that supports semantic clarity, interoperability, and reasoning. Unlike traditional data models that primarily focus on structure and storage, ontologies are designed so that systems can understand meaning and draw logical conclusions from it. This makes them especially valuable in environments where information must be integrated across different systems and interpreted intelligently.

Ontologies go beyond simple definitions of concepts. They define categories, hierarchies, constraints, and rules within a domain. For example, in a healthcare context, an ontology may define that a Patient undergoes a Treatment, and that Treatment can be classified as either a Procedure or a Medication. It may further define that a Medication is a type of Therapeutic Intervention. By establishing such hierarchies and relationships, the ontology provides a structured knowledge framework rather than just isolated definitions.