Data Mesh Information Architecture: Modeling Data Products and Domains

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.