DMBOK Meets the Modern Stack

DMBOK Meets the Modern Stack

How DMBOK's KAs map to Kafka, dbt, Snowflake/Databricks, OpenLineage, DataHub, Great Expectations, OPA.

Why it matters

DMBOK² (2017) predates much of today's stack. The principles still hold; the operationalisation is new. This lesson is the translation table.

Going deeper

KA	DMBOK practice	Today's tools (examples)
Governance	Charter + council + RACI	Atlan / Collibra workflows
Architecture	Reference models + standards	dbt + Iceberg/Delta + ADRs
Modeling	Conceptual / logical / physical	dbt models + dbml + Erwin
Storage / Ops	Capacity + backup + retention	Snowflake / Databricks / Postgres + Velero
Security	Classify + control + audit	OPA / Ranger / Lake Formation / Immuta
Integration	Patterns + contracts	Kafka / Debezium / Fivetran / Airbyte + dbt
Content	Capture + classify + retain	Box / SharePoint + Macie / Purview
MDM	Match + merge + survivorship	Reltio / Stibo / Profisee / Tamr
Warehouse / BI	Marts + delivery loop	dbt + Snowflake + Looker / Power BI
Metadata	Catalog + lineage + glossary	DataHub / OpenMetadata / Atlan
Quality	Six dimensions + alerts	Great Expectations / Soda / Monte Carlo

The tool isn't the practice. A team using DataHub and not doing stewardship still has no catalog — just an expensive empty database. The DMBOK practice is the thing being implemented; the tool is the implementation.

DMBOK practices vs modern-stack tools is the same relationship as double-entry bookkeeping vs accounting software.

Double-entry bookkeeping is a 600-year-old practice (every transaction posts twice, debits = credits). QuickBooks, Xero, NetSuite are implementations of that practice. The practice survives every vendor change; teams that confuse the two end up re-doing their books every time they switch software.

DMBOK is the practice. Snowflake, dbt, DataHub, Kafka are this decade's implementations. Internalise the practice and tool churn becomes cheap; internalise only the tools and the next platform migration costs you a year.