top of page

Why Semantics Is the Missing Foundation of Modern Data Architecture

  • Hannah Dowse
  • May 1
  • 3 min read

As organisations invest heavily in data platforms, analytics, and AI, a familiar frustration keeps resurfacing: despite more data than ever, decision‑making is still slow, inconsistent, and fragile. According to Juha Korpela, the root cause isn’t tooling or technology - it’s a lack of shared meaning.


In this session, Juha explores why enterprise semantics has become a critical capability for modern data and AI initiatives, and how conceptual data modeling provides a practical path to achieving it. Rather than advocating for heavy frameworks or academic theory, he offers a grounded, experience‑based perspective on how organisations can rediscover clarity, reuse, and trust in their data.


The Growing Cost of Missing Semantics


Most organisations already have vast amounts of documentation—data dictionaries, BI semantic layers, transformation logic, and business glossaries. Yet contradictions persist. Two departments use the same term but mean different things. Metrics don’t reconcile. AI models behave unpredictably because context is implied rather than explicit.


Juha argues that this is not a governance failure - it’s a semantic failure.

When meaning is scattered across dashboards, SQL, and people’s heads, it becomes impossible to scale understanding. Semantic knowledge becomes local, brittle, and dependent on individuals rather than the organisation. As AI adoption grows, this problem compounds: AI systems don’t infer business meaning naturally - they need it to be defined.


Semantics Explained: From Words to Meaning


A key contribution of the session is demystifying what “semantics” actually means in a data context. Rather than treating it as an abstract or academic concept, Juha frames semantics as a layered structure:


  • Business glossaries describe terms and definitions.

  • Taxonomies organise those terms into categories and hierarchies.

  • Ontologies define the relationships between concepts and the rules that govern them.


These aren’t separate initiatives or tools—they are different levels of expressing the same underlying understanding of the business. The challenge is that most organisations attempt to document semantics after systems are built, rather than discovering semantics before implementation.


Conceptual Data Modeling as a Discovery Practice


This is where conceptual data modeling plays a central role.


Rather than starting with databases, schemas, or pipelines, Juha advocates starting with conceptual models—high‑level representations of business concepts and their relationships, independent of technology. These models don’t aim to be complete or perfect. Their purpose is to facilitate conversation, alignment, and clarity.


Through modeling, organizations surface assumptions:

  • What is a customer?

  • When does an order really exist?

  • How do products, contracts, and events relate?


By answering these questions visually and collaboratively, semantics emerges naturally. Glossaries become easier to maintain. Taxonomies become meaningful rather than arbitrary. Ontologies evolve incrementally instead of being designed upfront in isolation.


Knowledge Plane vs Data Plane


One of the most important architectural ideas in the session is the separation between the knowledge plane and the data plane.


The data plane is where most organisations already focus their efforts: storage, processing, pipelines, performance, platforms. The knowledge plane, however, is where meaning lives - concepts, definitions, relationships, and context.


When these two planes are tightly coupled, meaning becomes hard‑coded into implementations. Change becomes painful. Reuse becomes limited. By separating them, organisations gain flexibility:


  • Semantics can evolve independently of systems.

  • Multiple data products can share the same meaning.

  • Different technologies can consume the same knowledge layer.


This separation also creates a natural foundation for knowledge graphs, metadata platforms, and AI‑ready architectures - without requiring every organisation to “boil the ocean.”


Why Traditional Semantic Layers Fall Short


Juha is careful to point out that BI semantic layers and transformation logic are not inherently wrong, but they are insufficient on their own. They tend to be:


  • Tool‑specific

  • Optimised for consumption rather than understanding

  • Difficult to reuse across domains and teams


True enterprise semantics must live above individual tools and platforms. It must reflect business reality first, not reporting convenience.


A Pragmatic Path Forward


Perhaps the most refreshing aspect of the session is its pragmatism. This is not a call for a massive semantics program, enterprise ontology initiative, or multi‑year governance effort.


Instead, Juha outlines a realistic path:

  • Start with conceptual models as a shared language.

  • Treat semantics as a product that evolves.

  • Separate meaning from implementation.

  • Accept that semantics is never “done”—only useful or outdated.


By focusing on clarity rather than control, organisations can create semantic assets that people actually use.


Semantics as an Enabler, Not an Overhead


Ultimately, the session reframes semantics from being an academic concern to a strategic enabler. It is what allows data teams to move faster without breaking trust. It is what makes AI explainable, reliable, and aligned with business reality. And it is what turns data from raw material into shared understanding.


For organisations struggling with fragmented metrics, duplicated logic, and AI initiatives that don’t quite land, Juha’s message is clear: before scaling data, scale meaning.

 
 
bottom of page