Schedule

Data Mesh has become one of the most influential ideas in modern data management. By organizing data around business domains, giving domain teams ownership of their own data, and sharing everything as data products, organizations can finally scale data work beyond the central team that always becomes the bottleneck. But decentralization comes with a catch that most teams discover too late: when every domain speaks its own language and builds its own products, understanding the data across the organization becomes the new bottleneck. What is a “customer” in Sales versus Finance? What does this data product actually contain, and can I trust it? How do I even find it? These are not technology problems: they are problems of meaning, and no technical platform solves them on its own.

This is where information architecture and data modeling earn their place at the center of a Data Mesh. Data modeling is often dismissed as a slow, technical, back-office activity. In reality, it is the most reliable way to capture what the business needs to know about, in language the business actually uses. We can then translate this shared understanding into well-designed, reusable data products. A conceptual model describes the reality behind the data: the things a domain cares about and how they relate. A logical model turns that understanding into a concrete structure fit for a specific use case. Done well, this modeling work becomes the bridge between business reality and technical implementation, and the foundation for semantic interoperability between independent domains.

In this full-day workshop you’ll work through that journey end to end. We start with the essentials of Data Mesh — its four principles, domains, and data products — and the interoperability challenge they create. You’ll then learn the fundamentals of conceptual modeling and put them to work in a hands-on exercise, modeling a real domain for a fictional online retailer and building its glossary. From there we move into logical modeling as part of data product design, and into the metadata, data contracts, and glossaries that expose a domain’s meaning across its boundaries. Finally, we step back to the operating model: the roles, feedback loops, and enterprise-level structures that let federated teams stay autonomous while still pulling in the same direction. Throughout, the emphasis is practical and accessible: you don’t need to be a modeling specialist to follow along, and you’ll leave able to apply these ideas in your own organization.

Learning objectives

• Understand Data Mesh and its core challenge: Grasp the Data Mesh paradigm, its four principles, and why federated domain ownership creates a semantic interoperability problem at the domain boundary.
• Capture meaning with conceptual modeling: Learn how to describe a domain in business language using entities, relationships, and attributes – and how to avoid the common pitfalls that derail modeling efforts.
• Build domain definitions and glossaries: Understand how to write clear, business-language definitions that capture a domain’s language and make data understandable to others.
• Design data products with logical modeling: Learn how logical models serve as use-case-specific designs derived from the conceptual model of a domain.
• Expose context across domain boundaries: See how Data Product Definitions, data contracts, and metadata standards (ODPS, ODCS) make a domain’s meaning discoverable and interoperable enterprise-wide.
• Handle language problems: Learn to deal with synonyms and homonyms (polysemes) using preferred and alternative labels, domain glossaries, and shared enterprise glossaries.
• Operate information architecture at scale: Understand the roles, responsibilities, feedback loops, and the Enterprise Knowledge Plane that keep semantics aligned across autonomous domain teams.

Who is it for

This workshop is designed for anyone responsible for making data understandable, trustworthy, and reusable in a decentralized or domain-oriented setup. No deep modeling background is required: the concepts are introduced from the ground up.

• Data architects and data modelers
• Chief Data Officers and people in Data Office roles
• Data product owners and domain owners
• Data Management and Data Governance professionals
• Data engineers and platform teams working with domains and data products
• BI and Analytics specialists who depend on well-defined, trustworthy data
• Business analysts who bridge business needs and data
• Data and IT consultants advising on Data Mesh, data products, or information architecture.

Detailed Couse Outline

1. Introduction and Objectives

• Welcome and introductions
• Overview of the day’s goals and structure

2. Data Mesh Basics

• The general idea and background of Data Mesh
• The four principles: domain-driven ownership, data as a product, self-serve platform, and federated computational governance
• Domains and domain teams: what a “domain” is and how to define one
• Data products: definition, anatomy, and types (source-aligned, aggregate, consumer-aligned)
• The interoperability challenge: technical vs. semantic interoperability at the domain boundary

3. Conceptual Models for Cross-Domain Understanding

• Why data needs business context to be useful
• How data models capture context
• The three levels of modeling: conceptual, logical, and physical
• Basics of conceptual modeling: entities, relationships, and attributes
• Identifying the real business objects and common pitfalls to avoid
• Building entity definitions and domain glossaries

4. Hands-On Exercise: Modeling a Domain

• Introducing “Storefront”, a fictional online retailer
• Defining domain boundaries: who owns what
• Identifying entities within a domain
• Building a conceptual model and named relationships
• Creating definitions and a Domain Glossary

5. Data Modeling as Part of Data Product Design

• The data product design process
• Understanding product scope within the domain model
• Logical models as product-level design and documentation
• Deriving logical models from the conceptual model
• Connecting the data product to its business context and maintaining links to the domain model

6. Ensuring Semantic Interoperability at the Domain Boundary

• Exposing metadata from domains and data products
• Data Product Definitions as collections of business and technical metadata
• Data Contract basics: promises, machine-readability, schema compliance, and versioning
• Example standards: Open Data Product Standard (ODPS) and Open Data Contract Standard (ODCS)
• Domain glossaries vs. shared enterprise glossaries
• Dealing with polysemes: synonyms, homonyms, and the Enterprise Knowledge Plane

7. Data Mesh Information Architecture Operating Model

• How information architecture creates and scales value
• Roles and teams: data product owner, domain owner, platform team, and domain DevOps team
• Product ownership, backlog management, and the data product lifecycle
• Modeling at the design stage and the importance of feedback loops
• Organizing data modeling on two levels: product and enterprise/domain
• Cross-domain interoperability and the Enterprise Knowledge Plane
• The goal: context-aware data utilization for AI, applications, and people

8. Conclusions and Next Steps

• Key takeaways
• Where to start in your own organization
• How to learn more
• Open Q&A and discussion

Rapid requirements gathering using the Information Product Canvas

The Information Product Canvas is a pattern template for capturing the data and information requirements for a single Information Product, in 30 minutes, in a language both stakeholders and data teams understand. In this hands-on, full-day workshop Shane Gibson, the creator of the canvas, teaches you the twelve areas of the canvas, how to complete it interactively with your stakeholders, and how to use it to prioritise what to build first. You spend half the day completing canvases in small groups on a realistic case study, and finish with a hands-on session on using an AI assistant alongside the canvas. You leave able to run the canvas pattern storming workshop with your own stakeholders the next working day.

Course description

Ask a data team what slows them down most and the answer is rarely the technology. It is the gap between what stakeholders ask for and what the team ends up building. Stakeholders and data teams speak very different languages. Requirements take weeks or months to gather, and nobody can say when they are done. They arrive full of ambiguity, describe a dashboard when the real need is a decision, and focus on a specification of what is wanted rather than why it is needed. The data team cannot work out what to build from the requirements, so they guess, build, and then hear the words every data professional dreads: “That’s not quite what I wanted.” Meanwhile the detailed requirements document nobody reads sits in a folder, and the data team is treated as an order taker rather than an enabler by stakeholders.

The Information Product Canvas closes that gap with one shared language and one conversation. It is a pattern template, twelve areas on a single canvas page, for defining a single Information Product: the business questions it must answer, the actions and outcomes those answers drive, who will use it and how, what data it needs, what is in and out of scope, and how big a job it is.
The stakeholder and the data team fill it in together, in one 30-minute session, so the requirements are validated in real time rather than weeks later. Because the canvas captures the why as well as the what, it also becomes the basis for prioritising across many Information Products and for feeding the rest of the Information Value Stream: the concept model, the transformation logic, the metric definitions, the acceptance tests and the build.
It is a pattern, not a framework: pick it up, use it, change what doesn’t fit, keep using it. Shane created the canvas and has iterated it with data and analytic teams for more than a decade. It is documented in his book “An Agile Data Guide to Information Product Canvas” and extended by more than ninety companion articles.
In this full-day workshop you learn the canvas by using it.

After an overview of the pattern template and the problems it solves, we work through the twelve canvas areas step by step with a worked example, explaining what is captured in each area and why, with Q&A after each one. Half the day is spent in small groups populating canvases based on a realistic case study organisation, so you practise the pattern rather than watch slides about it. You then learn how to facilitate the canvas live with stakeholders using the Pattern Storming workshop format, review real-world canvases from a range of industries, and see how completed canvases are used to prioritise and to drive delivery.
The day closes with a hands-on session on using an LLM assistant such as Claude or ChatGPT alongside the canvas, bring your laptop and your own LLM access to take part. No prior experience with the canvas, or with agile ways of working, is required.

Learning objectives

• Capture the requirements for one Information Product in 30 minutes: Deliver the data elephant one bite at a time, defining requirements in small, well-formed chunks the data team can deliver in days or weeks rather than months.
• Speak a shared language: Learn a data requirements language that both stakeholders and data teams understand, so one conversation produces requirements the stakeholders recognises and the team can build from.
• Collaborate visually with stakeholders: Fill in the canvas in front of stakeholders and get real-time validation, instead of writing a document and waiting weeks for feedback.
• Capture the what and the why: Elicit the actions stakeholders will take and the business outcomes they expect, turning the data team from order taker into business value enablers.
• Make scope and priority visible: Use Will / Won’t, T-shirt sizing and stack ranking so stakeholders can make trade-off decisions and see at a glance what gets built first.
• Facilitate the canvas and teach it to your team: Run the structured Pattern Storming workshop with your own stakeholders, avoid the common anti-patterns, and leave with a repeatable pattern your whole team can run the next working day.
• Use AI alongside the canvas: Apply practical techniques for using an LLM assistant to draft, challenge and refine canvases, while keeping the stakeholder conversation at the centre.
• Use the completed canvas downstream: See how a well-formed canvas feeds concept models, acceptance testing and prototyping, so the requirements keep paying off long after the workshop.

Who is it for?

This workshop is for anyone who gathers, defines, prioritises or builds from data and information requirements, on either side of the conversation. No prior experience with the canvas, or with agile ways of working, is required.

• Business Analysts who gather data requirements on behalf of a data team
• Data Product Managers and Product Owners who need to define and prioritise data work
• Data Analysts who want to agree outcomes with stakeholders before starting work
• Data Engineers who are frustrated with requirements they cannot build from
• Data Architects and Data Modellers who need well-formed requirements as input to their models
• Data Leaders looking for one repeatable requirements pattern for their team
• Agile Coaches and Scrum Masters who want to add a data-specific pattern to their toolkit
• Business stakeholders who commission Information Products and want to be understood the first time.

Detailed Course Outline

Bring your laptop and access to an LLM assistant of your choice (Claude, ChatGPT or similar).

Introduction and Objectives

• Welcome and introductions
• Team up: forming the small groups you will work in for the day
• Overview of the day’s goals and structure

Why Data Requirements Keep Going Wrong

• The language gap between stakeholders and data teams
• The seven symptoms: too slow, never done, ambiguous, unbuildable, the what without the why, unused documents, order taking
• What an Information Product is, and why we define one at a time
• Where the canvas sits in the Information Value Stream: from discovery to delivery

The Information Product Canvas: An Overview

• The canvas as a pattern template, not a framework
• The twelve areas at a glance and how they fit together
• The difference between a canvas and a requirements document

The Twelve Canvas Areas, Step by Step

• Business Questions: the questions the Information Product must answer, how many, how long, how much, why
• Actions and Outcomes: what people will do with the answers, and what changes in the organisation as a result
• Personas: who will use the Information Product
• Delivery Type: how they want it delivered, dashboard, report, data service, API, AI Agent, or something else
• Data Sync: how fresh the data needs to be, from monthly to real time
• Core Business Events: the data needed to answer the questions, captured as core business concepts and events
• Feature Stories: the specific features and behaviours the Information Product needs
• Will / Won’t: what is in scope, what is explicitly out, and how that enables trade-off decisions
• Information Product Name: giving the work a name everyone uses
• Product Owner: who makes the trade-off decisions on behalf of the stakeholders
• Vision Statement: the elevator pitch that distils the canvas into a few sentences
• T-Shirt Size: how big a job this is, without false precision
• Cross-checking the areas: using the canvas as a quality check on the completeness of the requirements

Hands-On: Completing a Canvas for the Case Study

• Introducing the case study organisation, its stakeholders and its problems
• Working in small groups to populate each area of the canvas as it is introduced
• Playing the roles of stakeholder and data team
• Group playback: comparing canvases across groups and spotting the differences
• Feedback and coaching on each group’s canvas

Facilitating the Canvas with Stakeholders: Pattern Storming

• The Pattern Storming Canvas Workshop: a structured, collaborative session for completing a canvas with stakeholders
• Sequencing the areas, timeboxing, and keeping the conversation moving
• Getting to a completed first canvas in 30 minutes
• Common anti-patterns and how to avoid them
• Adapting the pattern: what to change and what to keep

Real World Examples

• Real Information Product Canvases from a range of industries and use cases
• What a strong canvas looks like, and what a weak one looks like
• Define Once, Reuse Often: how canvases compound across a portfolio of Information Products
• Prioritising across canvases: stack ranking to decide what to build first

Hands-On with AI: Using an LLM Alongside the Canvas
Bring your laptop and access to an LLM assistant of your choice (Claude, ChatGPT or similar).

• Where an LLM helps in the canvas process, and where it doesn’t
• Using the canvas as structured context for an LLM
• Techniques for drafting, challenging and refining a canvas with an LLM
• Keeping the human conversation at the centre

From Canvas to Delivery

• Using the completed canvas as the input to creating a concept model
• Turning business questions, actions and outcomes into acceptance tests
• From canvas to prototype: getting something in front of the stakeholder early
• Keeping the canvas alive as the Information Product evolves

Conclusions and Next Steps

• Key takeaways
• Running your first canvas with your own stakeholders next week
• Continuing the journey: the book, the companion articles and the AI Coach
• Open Q&A and discussion

Data, AI, and agent governance as one discipline

AI agents are already in our data flows. They read data nobody governs. They act faster than any review cycle can follow. Boards, regulators, and teams ask who decides, on what basis, and who is accountable. Most of us cannot answer with confidence.
The position of this masterclass is that AI governance is not a new discipline, but data governance under pressure, where the questions stay the same while the speed, the scale, and the methodologies change. We start where accountability moves from humans to machines without anyone approving the move. We will take one business object and follow it the whole way: govern its meaning, encode that meaning so machines act on it, and place its decision rights where the understanding lives.

Why you need to attend this masterclass:

• Organizations structure data governance and AI governance separately. This divide creates gaps.
• In highly automated designs, failures are not as easy to catch.
• A policy document cannot keep up with systems that act at machine speed. Governance has to become something we do, not something we have.

What we cover:

• The handover and the accountability gap
• Unified governance scope: data, AI, and agent governance as one
• Governing meaning, and the three forms of drift
• The Data Governance Triad
• Encoding meaning so machines act on it
• Federated decision rights.

Learning objectives

• Name where decision-making has already passed from humans to machines, and why that handover is rarely an informed, deliberate choice
• Treat data, AI, and agent governance as one discipline, asking the same four questions: who decides, on what meaning, under which constraints, and who is accountable
• Recognize semantic drift in its three forms, definitional, contextual, and behavioral
• Apply the Data Governance Triad, negotiating meaning, directing through informed, deliberate choices, and auditing for accountability, as one connected cycle
• Understand how negotiated meaning is encoded, so machines and humans act on it
• Understand the accountability spectrum and federation.

Who it is for

Data and AI leaders, governance and risk practitioners, data product owners, and architects. Anyone responsible for how decisions get made, and answered for, in a distributed and increasingly automated organization. Governance does not have to be your title.

Detailed course outline

Introduction
Overview of workshop goals and introduction round. Four recent failures to understand the urgency of the matter. We explore the ironies of automation, including “the better a system performs, the less anyone watches it.”

• Four real world cases from 2025 and 2026
• Bainbridge’s ironies of automation (1983)
• The move from augmentation to delegation to abdication.

Key learning: Where decision authority has already moved from humans to machines in your own organization, and the associated patterns.

Axis 1. Unified governance scope
Why treating AI governance as a separate function repeats old mistakes. The working definition of data governance aligns with corporate governance.

• The four questions: who decides, on what meaning, under which constraints, and who is accountable
• Alignment with ISO 37000: the board governs, the executive manages, data governance works the same way
• Old School and New School, and why both fail: committees that are too slow, and everything-as-code that is fast but unaccountable.

Key learning: How to apply the same four governance questions to any decision, human or machine.

Axis 2. The meaning side
Meaning lives in shared practice and needs to be constantly negotiated. We work through why meaning has to be negotiated rather than assumed and then name the three ways a shared definition is challenged by semantic drift.

• Why meaning is negotiated, drawing on Frege’s sense and reference and Wittgenstein’s meaning-in-use
• Definitional drift: usage changes while the definition holds still
• Contextual drift: the context changes while data and definition stay fixed
• Behavioral drift: an actor acts differently though nothing was redefined.

Key learning: The three forms of semantic drift, and which one automation can catch versus what needs human negotiation.

Axis 2 continued. The Data Governance Triad
Three functions that run at the same time and feed each other. We work through the Data Governance triad and how to activate it.

• Data Negotiation: makes meaning explicit
• Data Direction: shapes the strategic focus
• Data Audit: ensures evidence and accountability.

Key learning: How to assign the three functions to a decision..

Axis 3. The technical side
Machines act on facticity, the raw pattern, not on factuality, which needs context and judgment. Negotiated meaning has to be encoded to production.

• The semantic backbone: schemas, taxonomies, ontologies, and knowledge graphs
• From documentation to runtime: move from glossary for humans to structure enforced at runtime
• The Four-Plane model (control, data, observability, user).

Key learning: How a negotiated definition becomes a data contract and schema a machine acts on.

Practical federation
We place a decision on the accountability spectrum and apply subsidiarity: the lowest capable level decides, and the level above assists and intervenes only when the lower level cannot. Federation is a state of maturity, not an architecture you install.

• The accountability spectrum: direct human control, human-in-the-loop, human-designed loops, bounded autonomy
• Federation as maturity.

Key learning: How to place a decision on the accountability spectrum and decide which level should own it.