Jaco van der Laan

đź§± Designing the Open Metadata Modeling Platform

11/10/2025  Â·  Data Engineering  Â·  Data Modeling Tools  Â·  Metadata

governance metadata
‹ ›

Series: Choosing the Right Data Modeling Tool in the Era of Metadata Engineering

🌍 The Vision: From Tool to Ecosystem

In the first two articles of this series, we explored how:

🔹VS Code and YAML can serve as the foundation for metadata-driven design.
🔹Dedicated modeling tools still play a crucial role for visualization, validation, and governance.

Now we’ll look forward — beyond evaluating today’s tools — to designing the open modeling platform of the future. One that merges the flexibility of code with the structure and semantics of enterprise data modeling.

This article outlines what such a platform would look like, how it could work, and what principles should guide its architecture.

🧩 The Problem with Today’s Tools

Most data modeling tools today were designed for a pre-DevOps world:

  • They store models in proprietary repositories.
  • They treat code as an export format, not a source.
  • They provide limited integration with modern toolchains.

At the same time, pure metadata-in-code solutions (YAML, JSON, Python) often lack:

  • Visual navigation and abstraction layers.
  • Role-based collaboration and change control.
  • Model-level governance and semantic validation.

The result? Teams must choose between agility and structure — either flexible scripts or rigid GUIs, but rarely both.

⚙️ The Open Metadata Modeling Platform

Imagine instead a hybrid architecture where both can coexist:

YAML + Git (VS Code)
↓
Open Metadata Layer (DuckDB / Graph / API)
↓
Modeling Platform (Visualization, Governance, AI)
↓
Documentation / Catalog / Lineage

This is not a single tool — it’s an ecosystem built around five design principles.

🧠 Principle 1 — Metadata as Code, Not Configuration

Everything starts as text. YAML, JSON, or declarative SQL define entities, relationships, and transformations.

The platform doesn’t invent a new modeling language; it reads the existing metadata and gives it meaning.

The modeling tool becomes a semantic interface, not a metadata gatekeeper.

🔗 Principle 2 — Open, Queryable Metadata Storage

At its core sits an open metadata database — ideally something lightweight and queryable, such as DuckDB or SQLite.

Every model, entity, attribute, and rule is stored as structured data. This enables:

  • Validation and lineage via SQL queries.
  • API access from external systems.
  • AI assistance through a common schema.

This is the opposite of the old “black box repository.” It’s transparent, portable, and auditable.

🧭 Principle 3 — Semantic Navigation, Not Just Diagrams

Most modeling tools focus on diagrams — boxes and lines.
The future platform focuses on semantics:

  • Navigating relationships, dependencies, and lineage.
  • Viewing context dynamically (technical, business, or logical).
  • Rendering visualizations on demand from the metadata layer.

Think of it as a knowledge graph for data design — where every concept, key, and transformation is a node in a navigable web.

👥 Principle 4 — Collaboration and Governance Built-In

Modeling happens in teams, not in isolation. The platform must enable:

  • Commenting and discussion on entities and relationships.
  • Model diffing across branches or versions.
  • Role-based approval and publishing workflows.
  • Audit trails that trace every change from YAML to database.

Governance doesn’t mean bureaucracy — it means clarity, ownership, and traceability.

🤖 Principle 5 — AI as Metadata Assistant

With all metadata accessible and structured, AI can now act as a true modeling co-pilot.

Practical AI use cases:

  • Auto-generating initial models from DDL, CSVs, or logs.
  • Suggesting naming conventions or datatype consistency.
  • Detecting redundant entities or unused attributes.
  • Explaining lineage and dependencies in natural language.

The modeling platform of the future won’t replace modelers —
it will help them think faster and validate better.

đź§® Architecture Sketch

Here’s a simplified view of the ecosystem:

+——————————+
| VS Code + YAML |
| (definition, templates) |
+—————-+————-+
↓
+——————————+
| Open Metadata Store |
| (DuckDB / Graph / API) |
+—————-+————-+
↓
+——————————+
| Modeling Platform |
| – Visualization & Layout |
| – Validation Rules |
| – Governance & Review |
| – AI Assistant |
+—————-+————-+
↓
+——————————+
| Documentation & Catalog |
| (DataHub, Confluence, etc.) |
+——————————+

Each layer can evolve independently — the platform provides extensibility rather than lock-in.

đź§© Design Principles Summary

Press enter or click to view image in full size

🚀 The Path Forward

The Open Metadata Modeling Platform isn’t a dream — it’s already emerging across open ecosystems.

Tools like DataHub, OpenMetadata, and SQLMesh are moving in this direction, and initiatives combining Draw.io, DuckDB, and VS Code extensions are proving that metadata engineering can be both open and collaborative.

The next step for our industry is not just to replace legacy modeling tools — it’s to redefine modeling as a live, connected, and AI-augmented metadata practice.

đź“– Earlier articles:
🧩 The New Landscape: From Data Models to Metadata Graphs
🧠 Selecting a Data Modeling Tool for the Metadata Era