💡 From debate to convergence — how the data community is redefining modeling for the metadata and AI era. When I asked whether we still need traditional data modeling tools, I expected opinions. What followed was something richer — a thoughtful, cross-disciplinary conversation between data modelers, architects, tool builders, and AI enthusiasts. The responses revealed a shared realization: Modeling is not dying — it’s evolving. Traditional tools like [[PowerDesigner]], [[ERwin]], and [[ER/Studio]] gave us structure and...

Creating a Shared Space for Data Understanding and Co-Creation In [[model-driven data engineering]], [[collaboration]] between business and technical teams often starts too late — after pipelines are built and logic is locked in. The [[Collaborative Layer]] changes that: a controlled environment where data modelers and business users co-create [[mappings]], explore source data, review intermediate transformation results, and validate logic together using familiar tools like [[Power BI]]. It’s a bridge between [[data transparency]] and [[semantic understanding]], turning model development into a...

A Metadata-Driven Perspective on Bridging Business Semantics and Data Engineering When Bill Inmon introduced the Business Language Model (BLM), he envisioned a bridge between business language and data — a model that could translate unstructured text into structured insight. Two decades later, model-driven data engineering is realizing that same vision: by treating business meaning as metadata, not just documentation. Press enter or click to view image in full size Since the dawn of data warehousing, one fundamental...

Over the past months, I’ve created a growing collection of Medium publications that explore the world of data modeling, metadata, architecture, and automation from two complementary perspectives — the technical and the human. This article explains how these publications connect, why the naming evolved, and how they now form a consistent ecosystem for readers and practitioners. Data architecture has many audiences. Some want to understand how models, metadata, and platforms work. Others need to see why these structures matter to business outcomes. When...

Entity-First Series · Track B (Technical) — Part 1 Series navigation: A1 — Why We Need a Business-Friendly Data Transformation Model • B1 (you are here) • A2 — Entities, Subject Areas & Transformation Steps • B2 — YAML → SQL Generator dbt and SQLMesh both center on files that define transformations (SQL + metadata), but they differ in how they structure that metadata and expose lineage. This article breaks down their folder layouts, concepts, and artifacts — then shows how to map them cleanly to...

Stop Mixing Raw and Derived Data in Your Integration Layer Too often, data teams store raw source columns and business derivations together in the same intermediate tables. This creates lineage confusion, audit headaches, and broken reproducibility when logic changes. This article proposes a simple modeling pattern: separate derivations from pass-through data, historize every meaningful change (bi-temporal SCD2), and keep purely technical reshaping as lightweight views. The result: clear lineage, reproducible outputs, and maintainable data platforms...

BFM is a structured way to capture business logic and translate it into SQL/ETL code.It bridges business-friendly definitions with technical implementation through strict rules, reusable functions, and automated code generation.This structured playbook can be used by the team (business users, data modelers, engineers) step-by-step. Separation of concerns Business defines what, system generates how. Logical building blocks Source → Select/Derive → Filter → Aggregate → Union → Output. Business-friendly naming Technical names are hidden until SQL...