A modern data platform is the technology infrastructure that supports distinct analytical and AI workloads, each with its own data requirements, consumer types, latency expectations, and governance profiles.

A few years ago, modernizing the data platform meant migrating from on-premises infrastructure to a cloud data warehouse and rebuilding dashboards on top of it. The resulting platform was designed for a narrower job: reporting and business intelligence (BI). 

Three forces have since converged to stretch it well beyond that original design envelope:

1. Machine learning (ML) workloads are moving from experimentation into production faster than existing infrastructure can absorb. Many enterprises now have dozens of models in production compared with single digits just three years ago.
2. Operational analytics are demanding real-time data delivery and write-back capabilities that traditional platforms were never designed to handle.
3. New AI workloads from generative AI knowledge systems, followed quickly by autonomous AI agents, have arrived with architectural requirements that barely existed two years ago.

There’s now a gap between what most enterprise data platforms were built to do and what the business needs them to do. Closing that gap with the right architecture, operating model, and sequencing for AI workloads supplies a lasting competitive advantage. 

What workloads do a modern data platform need to support?

A modern data platform needs to support many distinct analytical and AI workloads. Getting the architecture right starts with a clear-eyed view of what the platform must accomplish. Too often, organizations define the goal aspirationally— “we want to be AI-native”—rather than ground it in current workloads and realistic expectations for the next 24 months.

In practice, enterprise data platforms must support five distinct workloads, each with different data requirements, consumer types, latency expectations, and governance profiles.

Workload	Description	Requirements
BI analytics and reporting	Dashboards, statutory and regulatory reporting; the majority of current enterprise data use	Read-only, SQL-centric, T+1 data freshness
Embedded and operational analytics	Analytics woven into real-time operational decisions such as pricing engines and inventory management	Fast response times; ability to write actions back into operational systems
ML and advanced analytics	Full ML lifecycle through production, including fraud detection, demand forecasting, and churn prediction	Python and Spark; high compute intensity; strong model governance
Knowledge and content (GenAI)	Knowledge assistants, document summarization, policy Q&A; the main enterprise GenAI entry point today	Embedding pipelines, vector stores, large language model (LLM) gateways, grounding infrastructure
Agentic AI and autonomous decision making	AI agents that observe, reason, decide, and act—often without human intervention	Real-time data, historical context, model inference, write-back capabilities

Where the organization aspires to be is the wrong question. The right one is where its workloads will realistically sit over the next few years. Architecture decisions should follow from that.

What are the main modern data platform architectures?

Three distinct architectural patterns have emerged, each with a different set of trade-offs across workload coverage, operational complexity, talent requirements, and vendor exposure.

Warehouse-centric with selective extensions

A single cloud data warehouse serves as the center of gravity. Modern warehouses have converged with lakehouse capabilities. Native vector search is emerging across all three platforms for basic GenAI use cases, and open table formats create an on-ramp to lakehouse capabilities without taking on full complexity from Day 1. This architecture hits its ceiling at agentic AI and complex real-time requirements, but offers the broadest talent availability, fastest time to value, and lowest total cost of ownership.

Lakehouse as integration platform

An open lakehouse architecture converges batch and event data in a single governed storage layer. Its strongest advantage is ML integration. Data engineering and data science work on the same storage with shared catalog, access controls, and lineage, creating a tighter feedback loop and making results more auditable and repeatable. Growing capabilities support GenAI and agentic workloads through loosely coupled AI infrastructure.

Best of breed, by workload

Different workloads get different engines, connected by an event-streaming backbone and unified by a governance and semantic layer. No workload is out of reach. But the operational complexity is significant, requiring 6 to 10 distinct services plus the integration layer, sophisticated DevOps, cross-engine governance, and mature FinOps. Most organizations think they need this but they actually need a better-executed lakehouse. This pattern might be the right architecture for only the most technically mature companies (5% to 10%).

The boundary between these three architectures has blurred. Warehouse and lakehouse capabilities are converging, which means enterprises no longer face a binary choice between simplicity and future readiness. Adopting open table formats creates a path to lakehouse capabilities without the upfront complexity. For most enterprises focused on BI, reporting, and early-to-moderate ML and generative AI, the extended warehouse is the pragmatic choice. And since lakehouse SQL engines haven’t yet matched warehouse performance for high-concurrency BI queries, a dual-engine model is a likely end state.

Why the semantic layer determines whether the platform actually delivers

Across all three architectures, the semantic layer is both the highest-leverage investment and the hardest to retrofit. What’s commonly called “the semantic layer” is, in fact, three distinct capabilities. Each serves different workloads and matures on different timelines.

The business intelligence metrics layer—including metric definitions, dimension hierarchies, and calculation logic—is the essential starting point. It ensures that “revenue” and “active customer” mean the same thing everywhere they’re used. Organizations that build their infrastructure in the right sequence will start here.

The data catalog and lineage layer—including metadata management, quality profiling, lineage tracking, and access controls—provides the governance backbone every workload depends on. Organizations with a well-sequenced approach will build it in parallel with the metrics layer.

The ontological layer is what gives AI the business context it needs to move beyond generic responses. By mapping relationships among customers, products, suppliers, processes, and business rules into a machine-readable model, organizations create a shared understanding of how the business works. As foundation models commoditize, it isn’t the choice of LLM, but the depth of this ontological layer that determines whether AI produces genuinely enterprise-specific insight and action. Organizations that declare the semantic layer complete after building only the BI metrics layer are setting their AI initiatives up to fail.

How should leaders get started?

Leaders should get started by delivering value early and incrementally. This way, the outcomes of each phase of investment justify the next phase.

Platform programs fail most often not because the architecture was wrong, but because the organization ran out of patience or funding before value materialized.

Three funding archetypes work in practice, often in combination depending on organizational context and CFO disposition:

• A use-case-led approach. A specific business outcome justifies each increment. This approach works best for organizations with skeptical CFOs or no history of successful platform delivery.
• A capability- and migration-led approach. Each platform layer enables new workloads and decommissions legacy costs. This approach works best for organizations retiring existing platforms with strong central platform teams.
• A product-led model. The platform operates as an internal product funded by adoption metrics. This approach works best for mature organizations with chargeback mechanisms.

Successful organizations start with the most valuable use case, build only what’s needed to deliver it, show the results, and use that credibility to fund the next priority. They ship a measurable outcome in three to six months. 

The cost of delay isn’t zero. Technical debt accumulates, legacy platforms become harder to decommission, and the semantic infrastructure of every future workload becomes harder to retrofit with every system built on inconsistent definitions. The organizations that develop a lasting competitive edge will start now, deliver value early, and build the capability to evolve their platform as needed.