Schedule

Data Mesh is a federated approach to data management and governance developed by Zhamak Dehghani. It’s structure is based on domains and data products, elements that have also seen wide attention from organizations that are not otherwise working towards a full Mesh implementation. Working with autonomous domains who share data to the rest of the organization via data products is an excellent way to bring data work closer to the business and to allow domain-specific prioritization instead of a massive centralized bottleneck team. However, with domains having their own understanding of business and its core concepts, semantic interoperability becomes a challenge. This workshop focuses on the problems of Information Architecture in a de-centralized landscape. How can we document what data we have available, how do we understand what other teams’ data means, and how do we maintain a big picture of what is where? We will explore conceptual modeling as a key method of documenting the business context and semantics of domains and data products, more detailed logical modeling as a means to document data product structures, and consider both within-domain and cross-domain linking of various models and objects in them. As a hands-on exercise, we will model a domain and design some example data products that maintain strong links with their domain-level semantics. The workshop will give you the basic skills to do data modeling at these higher levels of abstraction, and understanding of the key characteristics and challenges of the Data Mesh that affect the way we need to do data modeling.

Learning objectives

• Understand the basics of the Data Mesh paradigm and its challenges relating to information architecture and semantics
• Learn the basics of conceptual modeling as a method of defining the business context of domains and data products
• Learn the basics of logical modeling as a part of data product design process
• Learn how solution-level metadata (e.g. data contracts) can expose domain-level context across domain boundaries
• Understand the basic operating model of information architecture management in the context of independent domain teams within a Data Mesh setup

Who is it for

• Data Architects
• Chief Data Officers and Heads of Data interested in federated operating models
• Data Product Owners and Team Leads working in a federated model
• Data Governance experts

Detailed Course Outline

1. Introduction

• Welcome and introductions
• Course agenda and goals

2. Data Mesh basics

• General idea
• Four pillars of Data Mesh according to Dehghani
• Domains and domain teams
• Data products
• The interoperability challenge

3. How conceptual models help with cross-domain understanding

• Basics of conceptual modeling: entities, relationships, and attributes
• How to identify the real business objects
• Building definitions and glossaries

4. Hands-on exercise: modeling a domain

• Domain boundaries
• Identifying entities within the domain
• Definitions and “domain ontology”

5. Data modeling as part of data product design

• Understanding product scope as part of the domain model
• Logical model as product-level design & documentation
• Deriving logical models from conceptual model
• Maintaining links with the domain model
• What happens when the product expands beyond the domain?

6. Ensuring semantic interoperability at the domain boundary

• Exposing metadata from domains and data products
• Data contract basics
• Domain glossaries vs. shared enterprise glossaries
• Dealing with polysemes

7. Data Mesh information architecture operating model

• Domain team responsibilities
• Data product owner responsibilities
• Platform team responsibilities
• Federated governance

8. Conclusion

• Key takeaways
• Where to start in your organization
• How to learn more

Whether you call it a conceptual data model, a domain model, a business object model, or even a “thing model,” the concept model is seeing a worldwide resurgence of interest. Why? Because a concept model is a fundamental technique for improving communication among stakeholders in any sort of initiative. Sadly, that communication often gets lost – in the clouds, in the weeds, or in chasing the latest bright and shiny object. Having experienced this, Business Analysts everywhere are realizing Concept Modelling is a powerful addition to their BA toolkit. This session will even show how a concept model can be used to easily identify use cases, user stories, services, and other functional requirements. 

Realizing the value of concept modelling is also, surprisingly, taking hold in the data community. “Surprisingly” because many data practitioners had seen concept modelling as an “old school” technique. Not anymore! In the past few years, data professionals who have seen their big data, data science/AI, data lake, data mesh, data fabric, data lakehouse, etc. efforts fail to deliver expected benefits realise it is because they are not based on a shared view of the enterprise and the things it cares about. That’s where concept modelling helps. Data management/governance teams are (or should be!) taking advantage of the current support for Concept Modelling. After all, we can’t manage what hasn’t been modelled!

The Agile community is especially seeing the need for concept modelling. Because Agile is now the default approach, even on enterprise-scale initiatives, Agile teams need more than some user stories on Post-its in their backlog. Concept modelling is being embraced as an essential foundation on which to envision and develop solutions. In all these cases, the key is to see a concept model as a description of a business, not a technical description of a database schema. 

This workshop introduces concept modelling from a non-technical perspective, provides tips and guidelines for the analyst, and explores entity-relationship modelling at conceptual and logical levels using techniques that maximise client engagement and understanding. We’ll also look at techniques for facilitating concept modelling sessions (virtually and in-person), applying concept modelling within other disciplines (e.g., process change or business analysis,) and moving into more complex modelling situations. 

Drawing on over forty years of successful consulting and modelling, on projects of every size and type, this session provides proven techniques backed up with current, real-life examples.

Topics include:

• The essence of concept modelling and essential guidelines for avoiding common pitfalls
• Methods for engaging our business clients in conceptual modelling without them realizing it
• Applying an easy, language-oriented approach to initiating development of a concept model
• Why bottom-up techniques often work best
• “Use your words!” – how definitions and assertions improve concept models
• How to quickly develop useful entity definitions while avoiding conflict
• Why a data model needs a sense of direction
• The four most common patterns in data modelling, and the four most common errors in specifying entities
• Making the transition from conceptual to logical using the world’s simplest guide to normalisation
• Understand “the four Ds of data modelling” – definition, dependency, demonstration, and detail
• Tips for conducting a concept model/data model review presentation
• Critical distinctions among conceptual, logical, and physical models
• Using concept models to discover use cases, business events, and other requirements
• Interesting techniques to discover and meet additional requirements
• How concept models help in package implementations, process change, and Agile development

Learning Objectives:

• Understand the essential components of a concept model – things (entities) facts about things (relationships and attributes) and rules
• Use entity-relationship modelling to depict facts and rules about business entities at different levels of detail and perspectives, specifically conceptual (overview) and logical (detailed) models
• Apply a variety of techniques that support the active participation and engagement of business professionals and subject matter experts
• Develop conceptual and logical models quickly using repeatable and Agile methods
• Draw an Entity-Relationship Diagram (ERD) for maximum readability
• Read a concept model/data model, and communicate with specialists using the appropriate terminology.