Why Building Enterprise Data Platforms Is Harder Than Architecture Diagrams Suggest

Most enterprise data platform architecture diagrams look remarkably straightforward.

Multiple source systems feeding into ingestion pipelines, a data lake or lakehouse organized into Bronze, Silver and Gold, followed by a semantic layer, analytics and increasingly, AI.

On paper, it looks clean, logical and scalable.

Then implementation begins. Technically, everything seems to work. The pipelines run. Data flows through the layers. Dashboards are delivered. Yet Finance, Sales and Operations still disagree on the numbers.

1. Enterprise data doesn't follow clean architectural boundaries

Consider a typical lead-to-cash lifecycle - Customer information is created, updated and maintained across marketing platforms, CRM, CPQ, contract management, ERP, billing, logistics and service systems. Each application has its own data model, identifiers, business rules and ownership.

And most enterprise landscapes haven't evolved according to the clean architecture diagrams we like to draw.

Acquisitions, reorganizations, system migrations, process changes and years of customizations have created fragmented environments with overlapping applications and inconsistent information.

But much of this complexity exists for a reason. Decisions made years ago may have been the right ones at the time, solving real business problems and delivering the value the organization needed.

Over time, the systems and the information they hold have evolved in different directions. Even something as fundamental as a customer can mean different things across systems.

Marketing sees a prospect. Sales manages accounts and opportunities. Finance maintains billing entities. Service tracks installed assets and entitlements. Now try building a customer 360, calculating customer profitability or establishing a reliable installed-base view.

What looked like a data integration exercise quickly turns into an architecture problem involving identity resolution, master data, historical relationships and conflicting business definitions.

The challenge isn't just integrating data from different systems. It's reconstructing business information that has evolved differently across the enterprise.

2. A data platform cannot fix every problem upstream

I've seen organizations invest heavily in modern data platforms expecting them to solve years of fragmented and inconsistent data.

The thinking is simple: bring everything into a lakehouse, transform it through Bronze, Silver and Gold, establish a semantic layer and finally get the trusted enterprise view everyone wants.

But if the installed base hasn't been maintained correctly, moving it into a lakehouse won't establish what is actually deployed. And if Finance and Sales disagree on definitions, the platform cannot independently decide which interpretation is correct.

A well-designed platform can reconcile information, identify anomalies, apply quality controls and create consistent analytical representations. But without addressing the problems upstream, it risks becoming a permanent reconciliation engine.

We also can't wait for every source system to be fixed.

The architectural challenge is deciding what must be corrected at source, what can be reconciled within the data platform and what should remain contextual to different business domains.

These decisions influence data contracts, ownership, integration patterns and how we design our enterprise data models.

Original diagram from the article Why Building Enterprise Data Platforms Is Harder Than Architecture Diagrams Suggest, showing a fragmented enterprise lifecycle and one customer represented differently across systems. — Original article visual: one customer, many versions of truth across the enterprise lifecycle.

3. Medallion architecture is a pattern, not an enterprise information architecture

Modern lakehouse technologies have made data ingestion, storage and processing considerably easier.

Medallion architecture gives us a useful framework: Bronze for raw source data, Silver for cleaning and integration, and Gold for business consumption.

But drawing three layers is the easy part.

Should Silver contain cleaned, source-aligned datasets or consolidated enterprise entities with shared business rules?

Where should identities be reconciled? How do we handle CDC, schema changes, slowly changing dimensions, historical corrections and deleted records? Should Gold contain reusable enterprise entities, domain-specific data products or reporting-oriented models? And where do business definitions and metrics actually live?

Consider Finance needing the customer hierarchy that existed when revenue was recognized, while Sales wants today's hierarchy after an account consolidation.

Both are valid, but they answer different questions.

This is where decisions around source fidelity, temporal modeling, enterprise data models, semantic layers and ownership become critical.

Bronze, Silver and Gold help organize how data is refined. They don't tell us how enterprise information should be modeled, governed or interpreted. A beautifully implemented medallion architecture can still be a poorly architected enterprise data platform.

Platform moves data. Architecture creates trust.

Original diagram from the article Why Building Enterprise Data Platforms Is Harder Than Architecture Diagrams Suggest, showing how diverse sources flow through Bronze, Silver and Gold layers into trusted governed consumption-ready data. — Original article visual: technology moves data; architecture creates trust.

4. Data engineering is software engineering

Enterprise data platforms are complex, continuously evolving software systems. Yet we sometimes approach them as collections of pipelines, notebooks and SQL transformations.

Reliable platforms need proper engineering discipline. Version control, CI/CD, infrastructure as code, automated testing, data contracts, lineage, observability and controlled releases should be standard practices, not afterthoughts.

Testing must go beyond whether a pipeline executed successfully. We need to validate data quality, reconciliation, historical correctness and schema compatibility, with mechanisms to detect changes and assess their downstream impact.

AI-driven development lifecycles (AI-DLC) create interesting opportunities here. AI will help accelerate SQL and pipeline development, test generation, documentation, code reviews, impact analysis and troubleshooting.

But generating transformations faster doesn't guarantee that we've implemented the right business logic or architecture. Without strong engineering controls, we may simply create technical debt faster. The goal isn't to build more pipelines. It's to deliver reliable, reusable data capabilities faster.

5. And now we want to make it AI-ready?

We've spent years trying to establish consistent, trustworthy enterprise data for analytics and reporting. Yet we're still dealing with many of the same foundational challenges.

Now we expect these platforms to support AI agents, intelligent applications and increasingly autonomous business processes.

But what happens when an AI agent acts on inconsistent customer records, outdated contract information or conflicting business definitions?

Maybe the question isn't whether our data platforms are AI-ready, but whether our enterprise data architecture is ready for what we're asking AI to do.

6. Finding the right architectural balance

Modern data platforms offer powerful capabilities, but evolving technologies and architectural patterns also bring new complexities, especially in established enterprise environments.

We rarely have the luxury of starting from scratch. Nor can we wait for perfectly harmonized source systems or expect a data platform to fix every upstream problem.

I believe the real challenge is finding a pragmatic balance. How do we build data architectures that adapt to a constantly evolving enterprise, address foundational data problems and continue delivering value without introducing yet another layer of complexity?

I'd be interested to hear how others are approaching this.

Originally published on LinkedIn on October 27, 2026. The author's publication archive is now hosted here as well.