“Ch 16 — Be Water. The Continuous Practice of Data Modeling” — @practicaldatamodeling

Why this is in the vault

The final chapter of Mixed Model Arts Book One. Reis reframes data modeling as a perpetual program, not a finite project — the key shift is governance-as-continuous-function. Directly relevant to how RDCO frames ongoing agent-COO engagements: not “build it and leave” but “own the program.”

The core argument

Reis opens with a mixed martial arts metaphor: early fighters specialized in one discipline; the survivors adapted. Data modeling follows the same arc — practitioners who treat it as a one-time deliverable become obsolete; those who treat it as continuous training last.

The “Done” Delusion: Most data initiatives are scoped as finite projects with a “done” milestone. Reis cites a conversation with Marco Wobben (Netherlands) whose team has been modeling continuously for nearly two decades — no notion of “done.” The reframe: data modeling is a program, like finance or operations, not a project.

Continuous Sense-Making: The data model is a living reflection of the business. Treating it as something you revisit annually (or only when it breaks) systematically lets the map diverge from the territory.

The Ownership Problem: Data flows everywhere and is owned by nobody in most organizations. Diffuse ownership makes accountability impossible — “if everyone is responsible for data quality, no one is.” A dedicated steward role (or at minimum, explicit program ownership) is necessary. This is distinct from the “data modeler” title, which often doesn’t exist; instead modeling is practiced by data engineers, analytics engineers, and architects who each need calibrated depth.

Be Water: The chapter title echoes Bruce Lee — adapt to the container you’re in. The practitioner who succeeds is not the one with the most elegant initial model, but the one who keeps the model aligned with an evolving business over time.

Note: Reis mentions Ch 14 (levels of data modeling) will be published next — the series is being finalized for print publication.

Mapping against Ray Data Co

Medium-strong. Two clean hits:

Program vs. project is the right framing for RDCO engagements. RDCO’s value proposition should not be scoped as “we’ll build your data architecture” — that’s a project. The stickier (and more defensible) version is “we run your data program on an ongoing basis,” analogous to how an outsourced CFO runs finance. This chapter is the clearest articulation of why the ongoing model is structurally superior, not just commercially preferable. Worth referencing explicitly in RDCO positioning and sales materials.
The ownership problem maps directly to the COO-as-Claude positioning. When RDCO deploys Claude as a client’s operational layer, someone must own the program. If the client’s founder owns it nominally but RDCO runs it operationally, the stewardship relationship must be explicit — who has authority to change the model, who adjudicates conflicts. The “everyone owns data quality / no one does” anti-pattern is exactly the failure mode RDCO needs its engagement contracts to prevent.

Secondary: The calibrated-depth idea (data engineer needs deep modeling skills, data scientist needs enough to design feature stores) is a useful framework for scoping what RDCO delivers to different client archetypes.

Series completion note

Ch 16 is the final chapter of Mixed Model Arts Book One. The series arc in the vault:

Ch 8 — Grain → Ch 9 — Aggregation → Ch 10 — Time → Ch 11 — Semantics → Ch 12 — Synthesis → Ch 13 — Seeing the Business → Ch 15 — People & Organizations → Ch 16 — Continuous Practice
Ch 14 (Levels) is forthcoming (artwork in progress per Joe’s note)

2026-04-20-practical-data-modeling-ch15-people-organizations — the organizational/political chapter; pairs directly with this one
2026-04-12-practical-data-modeling-mma-ch13-seeing-the-business — earlier chapter in the series
../00-vault-concepts/agent-deployer-positioning — “run the program” framing supports RDCO as ongoing operator, not one-time builder
../01-projects/coo-engagement-template — where the program-vs-project distinction should land in contract language

Copyright note