Data operating model
Place each data decision with the team best able to make it.
An operating model defines how business domains, central data teams and technology functions divide accountability while preserving shared semantics, controls and delivery standards.
The actual problem
Centralisation and federation both fail when the interfaces are undefined.
Organisation charts describe reporting lines, not how a metric definition is approved, a data incident is resolved or a cross-domain priority is chosen. Without those mechanisms, central teams become request queues and domain teams create local alternatives.
The operating model should place decisions close to relevant knowledge while centralising only the capabilities and controls that benefit from consistency, scale or independence.
- Central bottleneckOne team must interpret every business request, definition and quality issue across all domains.
- Local duplicationDomains rebuild pipelines and metrics because shared services do not meet their timing or context.
- Responsibility without authorityStewards are named but cannot approve definitions, priorities or source-process changes.
- Unowned interfacesBusiness, analytics and engineering each assume another team will resolve the gap between them.
- Escalation by seniorityConflicts reach executives because no normal forum has defined decision rights.
- Project-only deliveryTeams launch data products without an enduring owner, service level or adoption responsibility.
Method
Design around decisions, services and failure response.
The model begins with work that must happen, not preferred team labels. It distinguishes authority over business meaning from responsibility for technical production and from accountability for using evidence in decisions.
- Work and decision inventory
- Map recurring choices across strategy, definitions, access, quality, architecture, delivery, adoption and retirement.
- Placement principles
- Locate authority according to domain knowledge, enterprise risk, economies of scale, separation of duties and coordination cost.
- Role design
- Define accountable owners, contributors and service responsibilities with actual authority and capacity.
- Service interfaces
- Specify what central and domain teams provide to each other, required inputs, service levels and acceptance criteria.
- Forum and escalation design
- Create the smallest set of forums needed to resolve cross-domain semantics, priorities, risk and architecture exceptions.
- Transition and measures
- Sequence role changes, capability transfer and backlog movement; monitor decision latency, rework, adoption and incident response.
Evidence required
What reveals the operating model that exists in practice.
Formal role descriptions rarely capture the actual flow of work. Backlogs, incidents, recurring meetings and shadow solutions show where authority and capability currently sit.
| Input | What it reveals | Diagnostic question |
|---|---|---|
| Request and delivery backlog | Demand type, queues, handoffs and repeated work. | Which requests require central expertise and which require domain context? |
| Metric and quality incidents | Ownership gaps and escalation behaviour under pressure. | Who diagnoses meaning, source and pipeline failure? |
| Organisation and role descriptions | Formal accountability and capacity assumptions. | Does the named owner have authority, skill and allocated time? |
| Architecture and platform services | Shared capabilities and technical dependencies. | Where does standardisation reduce cost or enterprise risk? |
| Domain workflows and decisions | Context that cannot be centralised efficiently. | Which semantic choices require proximity to operations? |
| Governance forums and exceptions | How conflicts are resolved and policy is adapted. | Which decisions are delayed, duplicated or escalated unnecessarily? |
Outputs
An operating model described through executable agreements.
The model must be usable when a definition changes, a priority conflicts or a quality incident occurs. Boxes and reporting lines are secondary.
- Decision-rights matrixAuthority for semantic, technical, quality, access, priority, risk and retirement decisions.
- Role chartersPurpose, accountabilities, authority, capability and capacity for domain and central roles.
- Service catalogueShared and domain services with inputs, outputs, acceptance criteria and service levels.
- Interaction modelHandoffs between business owners, analysts, engineers, governance and technology functions.
- Forum and escalation mapDecisions resolved in normal work, cross-domain forums and executive exception routes.
- Transition plan and measuresCapability movement, backlog treatment, staffing dependencies and evidence that the model improves flow.
Worked example
A central queue can shrink by changing ownership, not headcount.
A central data team receives 200 requests per quarter and can complete 120. Analysis of the backlog separates work by the knowledge and control required.
| Request class | Current central demand | Proposed placement | Demand retained centrally |
|---|---|---|---|
| Repeated metric interpretation | 110 | Govern contracts; answer 70 through domain ownership | 40 |
| Local exploratory analysis | 50 | Shift 35 to enabled domain analysts | 15 |
| Shared-data incidents | 25 | Central triage with domain meaning owner | 25 |
| Cross-domain strategic analysis | 15 | Retain centrally | 15 |
Capacity released = 120 - 95 = 25 requests per quarter
The model does not simply push work outward. Metric contracts and domain authority remove repeated interpretation demand; enabled analysts take context-heavy exploration; the central team retains cross-domain work and control of shared incidents.
The released capacity can address strategic analysis and systemic quality work, provided domains receive real authority, access and capability rather than an unfunded responsibility.
Limits
Structure cannot compensate for missing capability or sponsorship.
An operating model changes who decides and delivers. It must be supported by skills, capacity, incentives and sustained leadership behaviour.
- Not an organisation chart exerciseReporting lines alone do not define service interfaces, decision rights or escalation.
- Not federation without enablementDomains need governed access, skills, time and support before work can move responsibly.
- Not central standards for every choiceConsistency should be imposed where enterprise value or risk exceeds the cost of coordination.
- Not staticRoles and service boundaries should evolve as domains, platforms and capability mature.