The Evolution of Data Architectures: From Data Warehouses to Lakehouse
From cubes to commodity storage
The enterprise data warehouse solved a real problem: give the business one governed, performant place to ask questions. It did that beautifully for structured, well-understood data — and then the world changed shape.
Semi-structured logs, event streams, images, documents and now model artefacts arrived faster than schemas could be designed. The data lake absorbed the volume but lost the discipline: no transactions, no reliable schema, no serious governance.
What the Lakehouse actually consolidates
The Lakehouse is not a new marketing layer over a lake. It is the reintroduction of warehouse guarantees on open storage:
- ACID transactions over object storage, so concurrent writes stop corrupting tables.
- Schema evolution and enforcement, so pipelines fail loudly instead of silently.
- Unified governance across tables, files, models and dashboards.
- One copy of data serving BI, data engineering and machine learning.
The architectural consequence
Once the storage layer is trustworthy, the interesting decisions move up the stack: domain ownership, contract design between teams, cost attribution, and how quickly a data product can be certified for reuse.
The winning architectures I see in Swiss enterprises are boring in the storage layer and opinionated in the governance layer.
What I would do first
- 1.Pick one high-value domain, not a platform-wide migration.
- 2.Land raw data once, model it in layers, and publish a contract.
- 3.Measure freshness, cost and consumption from day one.
- 4.Only then talk about AI use cases — they inherit whatever discipline you established here.