Data Platform Operating Model (CDM-Centred)

by

How data is structured, governed, and consumed across the organisation

1. Purpose

To provide a stable, governed data platform that:

  • delivers consistent reporting across systems and regions
  • supports ERP and Fabric transition
  • reduces reconciliation and duplication
  • enables scalable analytics and AI use cases

2. Core Principle

Data is not delivered as tables — it is delivered as structured, governed objects with defined behaviour

3. Platform Structure

3.1 Canonical Data Model (CDM)

The platform is built on a consistent pattern:

  • Core → the business object (e.g. Person, Project, Order)
  • Meta → descriptors (codes, dates, classifications)
  • Identifiers → cross-system identity relationships
  • Item / Values → transactional or measurable data

👉 This creates a repeatable, cross-domain structure

3.2 Domain-Based Design

Each business domain follows the same structure:

  • Person
  • Project
  • Customer
  • Supplier
  • Order / Invoice
  • Finance

👉 Ensures consistency across the platform

3.3 Layered Architecture

  • Bronze → raw ingestion
  • Silver → aligned, structured CDM views
  • Gold → reporting-ready datasets
  • Platinum → advanced analytics / ML

👉 CDM sits primarily in Silver / Gold

4. Identity & Key Strategy

4.1 Canonical Identity

  • Each object has a canonical identifier (OBJECT_SEQ)
  • Derived from strongest available source:
    • system identity (e.g. Entra)
    • email or equivalent
    • source system fallback

4.2 Multiple Identities are Expected

  • Objects may have multiple valid identifiers:
    • ERP
    • Payroll
    • User / system
    • external references

👉 These are modelled explicitly in meta_identifiers

4.3 No Name-Based Matching

  • Names are descriptive only
  • Not used for identity resolution

4.4 Identity is Time-Aware

  • current vs historic identity is tracked
  • rehire and reuse scenarios are supported

5. Data Access Model

5.1 Standard Access Pattern

  • All data accessed via controlled views / APIs
  • e.g. get.myview

5.2 Parameterised Access

  • domain, view, version, filters
  • supports:
    • current vs history (mode)
    • scoped queries

5.3 Row-Level Security (RLS)

  • enforced at source (Fabric / Warehouse)
  • based on organisational context (e.g. company)

6. Governance Model

6.1 Structural Governance

  • CDM defines:
    • object structure
    • attribute meaning
    • identity rules

👉 Governance is embedded in design, not just policy

6.2 Change Control

  • changes to:
    • structure
    • identity logic
    • key attributes

require:

  • impact assessment
  • controlled release

6.3 Stability Contract

  • CDM views are:
    • versioned
    • stable for consumers
  • breaking changes are managed, not ad hoc

7. Roles & Responsibilities

Data Engineering (You / Team)

  • define CDM structure
  • manage identity resolution
  • implement data pipelines and views
  • ensure performance and scalability

Reporting / Analytics

  • consume CDM views
  • apply business logic in reports
  • avoid redefining core structures

Business Stakeholders

  • define meaning of attributes
  • validate outputs
  • request enhancements via governed process

8. What the Platform Solves

  • inconsistent identifiers across systems
  • duplicate and conflicting records
  • region-specific data fragmentation
  • fragile report logic
  • manual reconciliation effort

9. What Success Looks Like

  • consistent reporting across HR, Finance, and Delivery
  • reduced identity-related issues
  • faster report development
  • clear data ownership and structure
  • scalable foundation for ERP and Fabric

10. Strategic Position

The data platform is not a collection of datasets — it is a governed system of business objects, designed to provide consistency, traceability, and scalability across the organisation.

Leave a Comment