Two ways to run a transformation

Without CDOs

  • Every project creates its own definitions
  • Long integration debates
  • Endless "system of record" arguments
  • Duplicated effort, inconsistent reporting
  • Vendor data models quietly become enterprise truth

Everyone inventing custom Lego bricks.

With CDOs

  • One agreed definition per concept
  • Clear ownership and stewardship
  • Faster, cleaner architectural decisions
  • Reuse instead of reinvention
  • Vendor systems plug in around stable concepts

Shared set, agreed shapes.

The glue between strategy and delivery

CDOs are the layer that connects strategy to delivery without vendor lock-in. They sit deliberately in the middle of the stack — anchored above the systems that change, and below the strategy that drives change.

Strategic directions Why we change
The strategic drivers that define why change is required and the outcomes the organisation is pursuing — efficiency improvements, growth, student/customer experience, research excellence.
Business capabilities What the organisation does
The core business outcomes enabled by shared data and supporting technology. Capability-aligned (e.g., HERM-aligned for higher education) so initiatives map cleanly across the enterprise.
Conceptual Data Objects / EBIM Stable, business-owned, governed
Person · Student · Worker · Customer · Organisation · Asset · Research. Stable, business-defined data concepts that provide a common anchor across systems and across change.
Applications and platforms Vendor-controlled, replaceable
HR, Student Systems, Finance, CRM, Timetabling, Research Platforms — vendor-controlled and replaceable. They support the concepts above; they don't define them.

CDOs sit in the middle, linking strategy to execution and defining ownership at the data level rather than the system level.