Library · Data Practice OS
Operating model
Reference guide · Published · Source reviewed
Technology is the easy half. An AI-ready practice needs clear ownership, and a platform that lets teams ship without raising tickets. The model borrows from Team Topologies and takes the useful parts of Data mesh: domain ownership and data as a product. It does this without asking every domain to become a data engineering shop on day one.
The teams
| Team | Type | Owns | Does not own |
|---|---|---|---|
| Data platform team | Platform | Accounts and workspaces, networking, identity, CI/CD, the Paved road templates, governance-as-code, cost tooling, the interop layer | Business logic in data products |
| Data product teams (per domain: Registration & Licensing, Road Assets, Traffic & Safety, Corporate) | Stream-aligned | Their gold data products: contracts, quality, documentation, SLAs, semantic definitions | Platform plumbing |
| AI & data practice (enabling) | Enabling | Standards, patterns, evaluation tooling, coaching, the reusable AI components (gateway, agent templates, MCP tools) | Long-running delivery for a domain |
| Data governance office | Governance | Classification standards, stewardship, privacy assessments, AI use-case risk process | Day-to-day access approvals (data owners do that) |
Early on, a central delivery squad usually builds the first products with domain SMEs, then hands them to domain ownership as the domain team forms. That is a deliberate transition, not a permanent central team.
Roles that must exist
- Data owner (business executive): accountable for a domain's data; approves access and classification.
- Data product owner: the backlog, consumers and SLA of one or more data products.
- Data steward: definitions, quality rules and metadata.
- Analytics engineer: dbt models, tests, semantic definitions.
- Platform engineer: infrastructure as code, CI/CD, security controls, cost tooling.
- AI engineer: RAG, agents, evaluation, gateway integration.
- FinOps lead: cost visibility, budgets, optimisation (FinOps).
The paved road
A team starting a new product should get, from one template:
- A repo with a dbt project, CI pipeline and environment promotion (CI/CD and environments).
- A data contract skeleton (Data contracts) and quality tests.
- Compute and roles provisioned by Terraform, with cost tags pre-set.
- Classification and masking applied by inherited tags.
- Catalog registration, documentation site and lineage, automatically.
- Optionally, an evaluation harness and a gateway key for an AI use case.
Target: from idea to a governed product in development in under a day, without a ticket.
Forums
| Forum | Cadence | Decides |
|---|---|---|
| Architecture review | Fortnightly | ADRs, deviations from the paved road |
| Data governance council | Monthly | Classification standards, cross-domain disputes, policy changes |
| AI governance forum | Fortnightly | AI use-case approval by risk tier, incidents |
| FinOps review | Monthly | Budgets, anomalies, optimisation backlog |
| Practice community | Fortnightly | Show-and-tell, patterns, shared problems (open to all) |
How we measure the practice
| Metric | Why |
|---|---|
| AI uses in production with every readiness gate passed, and their bands (AI readiness assessment) | The core outcome |
| Lead time from idea to production product | Platform effectiveness |
| % of production change via CI (Data as code) | Governance integrity |
| Consumer-detected data incidents per month | Trust |
| AI use cases in production with a passing evaluation | AI value, safely |
| Cost per product and per AI answer, against budget | Sustainability |
| Legacy workloads decommissioned | Migration progress, measured honestly |
Skills and capability uplift
Plan for both platforms only if you are choosing both. Typical pathways: SQL analysts to analytics engineers (dbt and the semantic layer), ETL developers to data engineers (Python, CI, Spark or Snowpark), BI developers to semantic modellers, and a small cohort of AI engineers (evaluation, RAG, agents). Pair vendor certifications with real delivery on paved-road projects.
Decision rights (RACI)
Adapted from a platform team's Data platform roles and scopes (proposed). Docs name roles, not people, and a roster maps roles to people. Each decision has one Accountable role. No one approves their own proposal for security or production changes. Each role has a delegate. If roles disagree, the platform director decides.
| Decision | Director | Asset owner | Custodian | Architect | Platform owner (DBA) | Security | Engineer | Source lead |
|---|---|---|---|---|---|---|---|---|
| Classify a data source | I | A | C | I | C | R | C | |
| Grant access to a data source | A | C | R | C | I | |||
| New database, schema or role | I | C | A | C | R | |||
| Naming and repo structure | A | C | R | I | ||||
| New tool or pattern | C | A | C | C | R | |||
| Load design and checks | C | C | I | A, R | C | |||
| Source file format and schedule | I | C | A, R | |||||
| Move to production | A | C | I | C | C | C | R | I |
| Accept a risk | A | C | R | I |
Decisions and their status are tracked in the Decision register. Analysis goes in an options paper (Options paper and fact check).