Reference Architectures — Hub, Mesh, Lakehouse, Fabric

Reference Architectures — Hub, Mesh, Lakehouse, Fabric

The patterns DMBOK + modern practice converge on, and the decision lever for each.

Why it matters

Architectural fashion changes every five years; the underlying decision levers don't. Knowing which lever the pattern is actually pulling lets you pick the right pattern instead of the trending one.

Going deeper

Patterns + the lever each pulls:

Pattern	Lever it pulls	Cost it imposes
Hub-and-spoke EDW	Central control, single canonical model	Central team becomes a bottleneck
Data Lake	Cheap raw storage of any shape	Catalogue + governance gap (‘swamp’)
Lakehouse (Delta/Iceberg)	ACID + schema on cheap lake storage	Open-table-format operational maturity
Data Mesh	Decentralised domain ownership	Strong platform + federated governance required
Data Fabric	Metadata-driven virtualisation	Mature catalog + lineage prerequisite

Pick by org shape, not by vendor pitch. Mesh on an org with no platform team is chaos; Fabric on an org with no metadata is vapourware; classical EDW on an org of 200 product teams is gridlock.

Reference architectures are the different floor-plans for the same warehouse site.

On the same plot of land you could build (a) one giant central distribution centre (EDW), (b) a sprawling self-storage facility where customers DIY (lake), (c) the self-storage facility plus a barcode scanner (lakehouse), (d) several local depots each run by its district (mesh) or (e) any of the above with a smart inventory system that lets one search engine see across all of them (fabric).

Each layout solves the same logistics problem differently. The bad outcome isn't picking the ‘wrong’ pattern — it's picking one that needs operating muscles your org doesn't have yet.