Treat quality rules as metadata Most data quality implementations begin with queries. SELECT COUNT(*) FROM customer WHERE customer_id IS NULL; Or: SELECT customer_id, COUNT(*) FROM customer GROUP BY customer_id HAVING COUNT(*) > 1; Useful, but fragile. Why? Because quality logic is: Buried in SQL files Scattered across projects Not centrally visible Difficult to propagate Often forgotten during migration MDDE approaches data quality differently. It treats quality rules as metadata. Not as ad-hoc SQL. When metadata...

From PowerDesigner, erwin, Hackolade and ArchiMate to Modern Metadata Workspaces Most enterprise data platforms do not start with dbt. They start with: PowerDesigner erwin Data Modeler ArchiMate repositories SSDT database projects Industry-specific capability models These tools represent years — sometimes decades — of modeling investment. But they often suffer from the same problem: The model lives in one place. The implementation lives somewhere else. And over time, they drift apart. MDDE addresses this gap by...

The Model Workspace When structure becomes visible, the next question is inevitable: Where does it live? If metadata exists only inside a database, it becomes opaque. If it exists only in diagrams, it becomes stale. If it exists only in SQL, it remains absorbed. MDDE solves this by making the workspace itself an architectural surface. This article walks through how models, entities, mappings, and artifacts are organized — and why that structure matters. Most SQL-based...

Why structure matters more than tooling Most architectural approaches fail not because the ideas are wrong, but because there is no clear place to put them. Guidelines float in documents. Rules live in ad-hoc scripts. SQL sits wherever it happened to be created. MDDE takes a different stance: Architecture should be visible in the project structure itself. This article describes a minimal, opinionated MDDE project layout that has proven practical in real work — without...

Turn your metadata and diagrams into living, navigable documentation in Confluence — complete with automated publishing, versioned visuals… Turn your metadata and diagrams into living, navigable documentation in Confluence — complete with automated publishing, versioned visuals, and business-friendly formatting. This article builds on the concepts introduced in previous parts: Part 1: Why Metadata-Driven Design Needs Visual & Text-Based Harmony Part 2: Automating draw.io Diagram Generation from Metadata Part 3: Parsing draw.io Diagrams Back into Metadata...

Translating Legacy Semantics into the Common Integration Layer Modernization isn’t about rewriting code — it’s about restoring meaning. Over time, legacy systems drift away from the business concepts they were meant to represent. The data still flows, but the semantics erode. What once described your business now merely encodes your past. In his talk Legacy Architecture Migration Patterns, Nick Tune captured this perfectly: “Modernization is a chance for semantic convergence.” That’s where the Anti-Corruption Layer (ACL) comes in — not...

Series: Choosing the Right Data Modeling Tool in the Era of Metadata Engineering For decades, data modeling tools such as ERwin, PowerDesigner, and ER/Studio were at the heart of every data architecture. They offered what we needed at the time — structure, visualization, and control. But over the years, something changed. Data architectures became distributed, schema evolution accelerated, and most of our logic moved from hand-crafted SQL to metadata-driven pipelines. Today, data modeling isn’t just about drawing entities and relationships. It’s...

How your generated code can carry its own lineage, dependencies, and release identity. Every generated artifact — a SQL table, view, UDF, or mapping script — has a story behind it. 🔹Which model version was used? 🔹Which upstream tables feed it? 🔹Which dashboards depend on it? 🔹When was it last generated, by whom, and for which release? That information exists in our metadata repository, notebooks, or CI logs. But once the code lands in the data warehouse,...

How Functional Transformation Modeling United Logic, Lineage, and Requirements — a Decade Ahead of Its Time “Before YAML, before DBT, before Coalesce — we were already modeling transformations as metadata.” In the previous article, we explored the marriage of data models and data movement, and how modelers and engineers finally began speaking the same language. This story now goes deeper — into a real-world architecture that quietly achieved that unity long before the modern data stack existed. At De...

How to move beyond technical extraction and build business-friendly lineage that truly explains data flow Modern data catalogs like Databricks Unity Catalog and Microsoft Purview promise automated lineage across your entire data platform. They scan SQL code, notebooks, and ETL pipelines to show how data moves between tables and systems. But there’s a catch: this lineage is purely technical — extracted from code syntax, not from business intent. It tells you what technically happens, but not why it happens. To understand real data flow...