💍 The Marriage of Modeling Structure and Movement

Where Data Modelers and Data Engineers Finally Say “I Do”

“Data modeling describes what data is_.
Data movement modeling describes how data_ becomes what it is.”

For decades, these two worlds lived side by side — data modelers defining the form, and data engineers shaping the flow. Each spoke a different dialect of metadata. And somewhere between the ERDs and the DAGs, the truth of the data got lost.

But times are changing. The modern data world is witnessing a marriage — between modelers and engineers, between structure and transformation, and even between their tools.

💡 Two Worlds Apart

Historically, data architecture was split between two professional tribes.

Press enter or click to view image in full size

Each world produced beautiful work — but when combined, the seams often showed.

• Business semantics got lost in SQL.
• Lineage stopped at table boundaries.
• Testing happened too late.
• Documentation lagged behind delivery.

The gap between model and movement became a recurring source of friction.

🧩 Structure and Movement — Two Sides of the Same Truth

To model data structurally is to ask:
➡️ What do we need to know?

To model data movementally (transformationally) is to ask:
➡️ How does this data become what we need it to be?

One defines nouns (entities).
The other defines verbs (actions).

Together, they form the full grammar of data.
But our tools and processes rarely allowed them to coexist.

🏗️ PowerDesigner’s Forgotten Vision

In the early 2000s, PowerDesigner already foresaw this union. It introduced the Data Movement Model (DMM) — a way to capture how data moves between models and entities. Mappings could describe derivations, filters, joins, and aggregations.

Few organizations, however, used it.
🔹Modelers stayed in LDM/PDM territory; engineers preferred ETL tools.
🔹The DMM quietly disappeared from most enterprise architectures.

Meanwhile, Erwin Data Modeler allowed column mappings between models, but its approach was limited — you couldn’t easily map transformations within the same layer, such as those inside a shared integration schema. Transformation logic was always “somewhere else.”

==🔁 Rediscovery in the Age of DBT and Coalesce==

Fast-forward two decades. We now see transformational modeling return through modern tools like DBT, Coalesce, VaultSpeed, WhereScape, and SQLDBM.

They’ve brought the Data Movement Model back — this time in YAML and SQL.

• DBT models define what is built and how it’s derived.
• Coalesce adds metadata-driven lineage and visual DAGs.
• SQLDBM even distinguishes between relational and transformational models.

In short, the idea of uniting structure and movement has resurfaced — now expressed in open, code-based form rather than a proprietary repository.

But this idea isn’t new. Years before “data-as-code” became a trend, some teams were already merging logical models and transformation logic in a single metadata framework.

One of the earliest and most complete implementations emerged at De Volksbank (then ASN), where PowerDesigner was extended to capture not only what data looked like but how it became that way.
🔹Inside that solution, we introduced a fundamental distinction between two types of modeled entities — a pattern that still underpins today’s metadata-driven architectures.

⚙️ The Marriage Model — From ERD to DAG

In this model, formal entities act as the structural anchors between modeling layers. They define what is delivered to, or expected from, the next logical layer of the architecture — for example, from source access to business integration or from business to delivery.

Between and within those layers live the non-formal entities — the working structures used inside the model for stepwise transformations, enrichments, or aggregations.

👉 In short:

• Formal entities define the interfaces between models — what goes in and out.
• Non-formal entities define the steps within a model — how the transformation happens.

So the true flow looks like this:

Source Entity → Source Access Entity → Business Entity → Delivery Entity

with multiple Intermediate and Aggregate entities living inside each model to represent transformation logic.

Requirements, metadata, and testing wrap around the entire flow — providing traceability, validation, and governance across every layer.

When structure and movement are modeled this way:

• Transformation logic becomes explicit and modular.
• Lineage spans both inter-model (formal) and intra-model (non-formal) transformations.
• Documentation and SQL generation stay consistent across every layer.

This was the architectural heart of the Volksbank/ASN solution — a concept that prefigured what today’s metadata platforms and declarative pipelines are finally rediscovering.

🧠 The Human Side of the Marriage

This isn’t just technical — it’s cultural. At many organizations, modelers and engineers live in different ecosystems, even reporting to different managers.
🔹One speaks UML, the other YAML.
🔹One loves conceptual integrity, the other lives for runtime efficiency.

But in a metadata-driven world:

Everyone becomes a modeler.

• Modelers learn to describe transformations functionally (derive, filter, aggregate).
• Engineers start expressing logic declaratively, through metadata and templates.
• Both speak the same language of data movement as metadata.

When that happens, semantic clarity meets engineering automation — and data finally becomes both understood and operational.

🔍 A Marriage That Already Happened

What makes this story fascinating is that it already happened — quietly, years before “data-as-code” or “metadata-driven pipelines” entered the conversation.

At De Volksbank (then ASN), we applied these principles in practice: logical data models extended with transformation semantics, inheritance hierarchies, and requirement mappings — all stored and versioned as metadata inside PowerDesigner.

That solution proved that when both structure and movement are modeled together, the result is more than just documentation: it becomes an executable, auditable, and fully traceable view of how data evolves through every layer of the warehouse.

In Part 2, we’ll travel back to those origins — 🕰️ Inside the De Volksbank / ASN Solution — to explore how that early implementation anticipated today’s DBT, Coalesce, and metadata-driven development platforms.

Stay tuned — that’s where the marriage gets its family history. ❤️

🔗 Related Reading

If you’d like to see how this marriage of structure and movement worked in practice, read my case study:
👉 From Whiteboards to Working Models: How We Built a Model-Driven Data Warehouse at ASN Bank with CrossBreeze

It describes how we used PowerDesigner, CrossTest, and PowerDecomposer to turn logical data models into executable pipelines — the very foundation of today’s metadata-driven practices.

🏡 Looking Ahead — The New House

And where do modelers and engineers now live together happily?

In VS Code.

🔹A shared workspace for YAML, SQL, Jinja, Mermaid, and Markdown.
🔹A single repository for both models and transformations.
🔹And with AI (Copilot) as their ever-present wedding planner — suggesting code, generating diagrams, validating consistency.

VS Code is the house.
AI is the building crew you hire to help construct your (data)house.

That’s the future of metadata-driven development — where the ERD and the DAG hang proudly on the same living-room wall.