Enterprise Data Architecture — The Blueprint Layer

Enterprise Data Architecture — The Blueprint Layer

EDM, EDW, integration patterns and the conceptual / logical / physical split DMBOK insists on.

Why it matters

Architecture decisions made on day 1 dominate the platform's cost curve for years. DMBOK names this KA before Storage on purpose: what lives where and how it integrates is a strategic question, not an Ops one.

Going deeper

The three-layer architecture model DMBOK keeps returning to:

• Conceptual — entities and relationships the business recognises (Customer, Product, Order). No technology yet.
• Logical — attributes, keys, normalisation, cardinalities. Still tech-neutral.
• Physical — tables, indexes, partitions, storage tier per workload.

Most teams jump straight to physical (‘we need a Postgres table for X’) and end up rebuilding when the business view changes. The discipline of keeping the three layers separated and traceable is what makes ‘change’ feasible without rewrite.

Enterprise architecture is the master plan of a city, not the blueprint of a house.

The master plan says where the residential zones, commercial districts, transit lines and utilities go. Each architect builds buildings inside it — and they can, because the plan guarantees the building gets water, power and a tram stop. Skip the master plan and every developer trenches their own water main; the result looks like a city until you try to live in it.

Most organisations are building-rich and master-plan-poor: dozens of pipelines and warehouses, no agreed conceptual model, every new system re-trenching the definition of ‘Customer’.