Most conversations I have with data and AI executives follow the same arc. They start with ambition: AI initiatives, semantic layers, copilots. Within five minutes, they land on the same blocker. Not the cloud platform. Not the tooling. The transformation layer. The logic that turns raw data into something the business can actually use.
The problem isn't that the logic is old. It's entangled. Business rules, data movement, schema handling, and orchestration live together in the same scripts, the same stored procedures, the same ETL jobs. Often written years ago by people who have since moved on.
Disentangling business logic from technical execution isn't a refactoring exercise. It's an architecture decision.
The maintenance trap: how entanglement happens
Nobody sets out to build entangled pipelines. It happens one source system at a time.
A developer writes a stored procedure that extracts data from the ERP, applies a currency conversion, filters inactive records, and loads the result into a reporting table. The business logic (what counts as an "active" record, how currency conversion works) lives inside the same block of code as the technical logic (how the data moves, how errors are handled). The two aren't separated because at the time, there was no reason to separate them. One source, one pipeline, one developer who understood all of it.
Then a second source arrives. A third. An acquisition brings a fourth with a completely different schema. Each new source gets its own pipeline, its own embedded logic, its own author. Within a few years, the transformation layer is the most fragile asset in the enterprise. Not because any single pipeline is poorly written, but because the accumulated logic is undocumented, person-dependent, and resistant to change.
This is transformation debt. Unlike technical debt in application code, it compounds non-linearly. Each new source system multiplies the number of mappings. Each migration forces a full rework of logic that was never designed to move. Each regulatory audit exposes lineage gaps that take weeks to trace.
Three symptoms show up consistently.
Key-man risk. Two or three people understand the transformation layer. When one leaves, the institutional knowledge leaves with them. Documentation, if it exists, describes what the code was supposed to do. Not what it actually does today.
The cost of change. When a source system changes (an SAP migration, a schema update, a new SaaS platform), the downstream impact is unknowable without manually tracing every affected pipeline. I've seen organisations where a single source-system change triggers months of remediation. Not because the change is complex, but because nobody can confidently identify everything it touches.
Resource drain. Maintenance absorbs capacity that should go toward new data products. I regularly talk to teams where most engineering effort goes to keeping existing pipelines running. In some cases, entire teams of 20 or 30 people maintain an integration layer built for a business that no longer exists in its original form.
What disentangling actually means
The idea of separating business logic from data movement isn't new. What changed is that it's now architecturally achievable.
The separation works like this. Business meaning (what a "customer" is, how "revenue" is defined, which records are "active," how entities relate to each other) is captured explicitly in a model. That model is the system of record for what the business intends. The technical execution (SQL, Spark, dbt models, platform-specific loading patterns) is generated from that model rather than written by hand.
Compare that to the status quo, where business meaning is implicit in the code. When a developer writes WHERE status != 'INACTIVE' AND region IN ('EU','APAC'), the business rule is embedded in the implementation. Change the definition of "active" or add a region, and someone has to find every place that logic appears and edit it manually. Across hundreds of pipelines and dozens of source systems, that's the maintenance trap.
In a disentangled architecture, the business rule exists in one place: the model. The code is a derived artifact. Change the rule in the model, the code regenerates. Change the target platform, the code regenerates for the new environment. The model stays the same. This is what makes it possible to reconcile metadata from multiple source systems against a single business model rather than embedding each source's assumptions in the pipeline code.
What does that change in practice?
Source system changes become visible in the model. The affected code regenerates rather than getting manually hunted down and patched. Migration becomes a regeneration exercise, not a rewrite.
Lineage, documentation, and audit trails come from the model, not from the code. Not from a separate documentation layer that drifts. The model knows what the business intended. The code reflects that intent deterministically.
And because the business logic lives in the model rather than in platform-specific SQL, the same model generates code for Snowflake, Databricks, Microsoft Fabric, or any other target. Platform migration stops being a logic rewrite.
The AI payoff: metadata as a by-product
This is where disentangling matters most, and where most teams underestimate what it gives them.
Every AI initiative (copilots, GenBI, agentic workflows, semantic layers) depends on the same thing: a machine-readable description of what the data means and how it was derived. Not a data dictionary someone wrote two years ago and forgot to update. Not YAML files that describe code rather than business intent. A structured, queryable metadata layer that AI systems can reason over.
Entangled pipelines can't provide this. When business logic is embedded in code, the only way to understand what the data means is to read the code. That works for the developer who wrote the pipeline. It doesn't work for an AI system that needs to answer "what does this revenue figure include?" or "can I trust this customer count for forecasting?"
Enterprise AI needs four things from the data foundation: integrated data across sources, active metadata describing the logic that governs it, explicit semantics in machine-readable form, and full lineage from source to consumption. In an entangled architecture, none of these exist reliably. In a model-driven architecture, all four fall out of how the data is built. They aren't retrospective documentation projects. They're consequences of the approach.
The business pressure to deploy AI is what's creating the urgency to fix the data foundation. And the data foundation can't be fixed without disentangling the transformation layer.
What this looks like in practice
We work with a bank managing regulatory-grade complexity: hundreds of source tables, a covered bond program, ECB and Basel reporting requirements. Their core data team is five to eight engineers doing work that would traditionally need twenty or more.
We see manufacturing companies absorbing SAP migrations and saving thousands of engineering hours. We see two-person teams rebuilding decades of legacy data in months.
The common thread is architecture, not heroic engineering. When business logic lives in a model and the code is generated, the team's effort scales with the complexity of the business, not with the number of source systems or the volume of SQL to maintain.
When to disentangle
If you're planning a platform migration, an ERP transition, or an AI initiative, this question is already on your table.
Every new pipeline built in the entangled pattern adds to the transformation debt. Every source system onboarded without an explicit model deepens the key-man risk. Every AI initiative launched on top of undocumented, untraceable logic inherits that fragility.
The organisations moving fastest on AI decided to disentangle early. Not as a separate project, but as the foundation for everything that followed.
