Compare data mesh's four principles against a centralised data warehouse to justify a transition.
Digital Transformation & Artificial Intelligence
Data Mesh and Domain Ownership of Data Products
Prepares data leaders to shift from centralised pipelines to domain ownership of data products, backed by data contracts, a self-serve platform and federated governance.
🗓️Duration5 training days
📚Content4 modules · 8 sessions
🎓On completionAccredited attendance certificate
About the programme
Course Overview
Centralised data teams were meant to make data trustworthy; instead, many have become the one queue every request must join, while the domains that understand the data best have no direct stake in its quality. Data mesh addresses this by making domains accountable owners of their own data products, supported by a self-serve platform and held together by federated governance rather than central control. This course works through all four principles in sequence: drawing domain boundaries around business capabilities, designing data products that are discoverable, self-describing and trustworthy enough to reuse with confidence, and specifying the platform capabilities a domain needs to publish without waiting on a central team. Federated governance is treated as a genuine design problem, not a slogan, with practical work on which rules must be global and which decisions belong to the domain. The course closes with the organisational shift this requires, reskilling central data engineers into domain teams and resetting incentives so a domain is rewarded for the data products other teams actually reuse.
Expected Learning Outcomes
Draw domain boundaries around business capabilities and assign an accountable data product owner.
Design a data product that is discoverable, self-describing and backed by published quality metrics.
Write a data contract that sets freshness, availability and support commitments between domains.
Specify self-serve platform capabilities that let a domain publish data without central bottlenecks.
Design a federated governance model that separates global rules from domain-level decisions.
Plan the organisational shift of data ownership and incentives from a central team to domains.
Who Should Attend
Chief data officers and heads of data platform planning a move away from centralised pipelines.
Data architects designing the platform capabilities a domain-oriented data strategy depends on.
Domain data product owners newly accountable for data they did not previously manage directly.
Data governance leads redesigning policy for a federated rather than centralised model.
Data engineers moving from a central data team into an embedded domain role.
Analytics leaders whose teams consume data across multiple, previously siloed domains.
Course Modules
Select any module to see its sessions and points.
01Principles of Data Mesh and Domain Ownership
2 sessions · 8 points
Session 1The Four Principles of Data Mesh Compared With Centralised Architecture
- Compare domain ownership, data as a product, self-serve infrastructure and federated governance against a centralised warehouse model.
- Identify where a central data team has become a bottleneck that domain ownership is intended to remove.
- Assess organisational readiness for decentralised data ownership before committing to a mesh transition.
- Sequence a mesh adoption by domain rather than attempting an organisation-wide cutover on a single date.
Session 2Defining Domain Boundaries and Assigning Data Ownership
- Draw domain boundaries around business capabilities rather than around existing team or system structures.
- Assign a domain data product owner who is accountable for quality, documentation and access decisions.
- Resolve boundary disputes where two domains claim ownership of the same underlying data.
- Document each domain's scope so a new data product's home is obvious without escalation.
02Treating Data as a Product
2 sessions · 8 points
Session 1Designing a Data Product for Discoverability and Trust
- Design a data product to be discoverable through a catalogue entry that states its owner, schema and purpose.
- Build a data product so its meaning is self-describing, without requiring a call to the owning team to interpret it.
- Publish data quality metrics alongside each data product so consumers can judge trustworthiness before use.
- Version a data product's schema so consuming domains are not broken by an unannounced change.
Session 2Setting Service Levels and Data Contracts Between Domains
- Write a data contract that states schema, freshness, availability and support commitments between producer and consumer.
- Set a service level for data freshness and uptime that reflects how the consuming domain actually uses the data.
- Monitor data contract compliance and alert both domains automatically when a commitment is breached.
- Renegotiate a data contract when a consumer's requirements change rather than letting silent drift accumulate.
03Building the Self-Serve Data Platform
2 sessions · 8 points
Session 1Platform Capabilities That Remove Central Bottlenecks
- Provide self-serve pipeline, storage and access-control tooling so a domain can publish without central approval queues.
- Standardise the platform's ingestion and publishing interfaces so every domain's data product looks familiar to consumers.
- Automate access provisioning against policy so granting a new consumer access does not require a manual ticket.
- Measure time from a domain's request to a published data product as the platform's core efficiency indicator.
Session 2Balancing Domain Autonomy With Common Standards
- Set common standards for metadata, naming and data quality that every domain's product must meet.
- Allow domains to choose their own processing tools within the platform's supported technical boundaries.
- Review domain-built data products periodically against platform standards to prevent drift into incompatible formats.
- Resolve tension between domain autonomy and platform consistency through an agreed escalation path.
04Federated Governance and Organisational Change
2 sessions · 8 points
Session 1Designing Federated Computational Governance Across Domains
- Design a federated governance body with representatives from each domain and the platform team.
- Agree global rules, such as sensitive data handling, that every domain must apply without local exception.
- Leave domain-specific decisions, such as schema design, to the owning domain within the global rules.
- Automate governance rule enforcement in the platform so compliance does not depend on manual checking.
Session 2Shifting Ownership From Central Data Teams to Domains
- Reskill central data engineers into domain teams so ownership of pipelines moves with the people who understand the data.
- Redefine the central data team's role as platform and standards custodian rather than sole data producer.
- Set incentives that reward a domain for the adoption and quality of its data products, not only for its own reporting.
- Track mesh adoption through the number of trustworthy data products published and reused across domains.
What the participant receives
4 course modules
A structured syllabus
8 training sessions
across 5 days
32 detailed points
Applied, detailed content
Accredited attendance certificate
On completing the programme
Complete your registration
We will contact you within one business day to confirm.
Ready to start?
Reserve your seat and start building the skill.