Sign up for Data Mesh Understanding's free roundtable and introduction programs here: https://landing.datameshunderstanding.com/

Please Rate and Review us on your podcast app of choice!

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

Episode list and links to all available episode transcripts here.

Provided as a free resource by Data Mesh Understanding / Scott Hirleman. Get in touch with Scott on LinkedIn if you want to chat data mesh.

Transcript for this episode (link) provided by Starburst. See their Data Mesh Summit recordings here and their great data mesh resource center here

GoDataDriven Data Mesh Webinar: https://godatadriven.com/topic/webinar-data-mesh-9-feb-2022-thanks/

GoDataDriven Self-Service Whitepaper (info-gated): https://godatadriven.com/topic/data-democratization-whitepaper/

Steven's LinkedIn: https://www.linkedin.com/in/stevennooijen/

Guillermo's LinkedIn: https://www.linkedin.com/in/guillermo-s%C3%A1nchez-dionis/

In this episode, Scott interviewed two people from the European data consultancy GoDataDriven - Steven Nooijen, Head of Strategy, and Guillermo Sánchez, Analytics Engineering Tech Lead.

Guillermo started off by talking about how for the last ~3 years, he was seeing the data engineering team as the bottleneck before data mesh came onto the scene. For Steven, they were seeing lots of companies that were building out data platforms, especially data lakes, and then not really getting the promised benefits so data mesh made sense.

All agreed data mesh is not right for every company and then mentioned some good signs that an organization should consider data mesh. Guillermo pointed to a lot of the usual suspects: size of company, size of data team, how many data consuming teams do you have, how many data sources do you have, etc. He then gave a specific example: if you have a data analyst in a consuming domain that has to wait more than 1 week for data, there is a bottleneck somewhere. Is it centralization? Not sure but time to investigate and that might be where you start to consider data mesh.

Steven gave the example of an even earlier indicator that bottlenecks are occurring: teams start to hire their own data people rather than leverage the central team. Guillermo also pointed to the rise of consuming teams getting direct data access from producing teams instead of going through the data team.

Guillermo made a very crucial point: data mesh is really about interfaces. People talk about data products being the technical communication interfaces between teams. So as long as people trust the data product and teams adhere to interface standards, data mesh can work. But that trust is earned, not given.

Both Guillermo and Steven talked about the need for an easy path, a golden path. With that golden path, it can be relatively simple and low friction for domain teams to share their data for the vast majority of use cases. There is also a need for some quality control to make sure data products are trustworthy, have reasonable SLAs, etc.

Per Steven, what they've seen to date at customers is most domains are happy to follow that golden path. But, you certainly need that path to start out where they are - trying to make them use foreign tooling/workflows is going to be a tough sell. They are also leveraging the concept of a "certified" data product label. The core data mesh implementation team awards this to high-quality data products and it's easy for teams using the happy path get - it is harder to get certified if you use your own tooling. This acts as a quality control measure.

Steven talked about when evaluating where on the centralization/decentralization slider decisions should fall, you should really look at domain maturity and organization maturity. Centralization provides more support, if being more of a bottleneck, in many cases so there is a trade-off. Are domains really ready to take on the full responsibility of whatever task you are considering? It's okay to not have a one-size-fits-all approach.

Somewhat atypically, Guillermo and Steven recommended starting your proof of concept, if you need to do one, with a single domain. They recommended starting with an eager domain and to make sure they have support from the platform team. Pick a consumer-aligned domain with a high demand for data. Again, this advice runs somewhat counter to what many have said and that is absolutely valid.

Instead of the proof of concept, Steven recommends driving high level buy-in via a C-level sponsor. That way, you have time and funding to get things moving. Obviously easier said than done but if you can go this route, your journey is likely to be smoother as you won't have to constantly be looking for funding. When driving buy-in via the C-level sponsor, Steven mentioned never once using the phrase "data mesh". The execs really responded to using "self-service" and the 4th industrial revolution concept.

When driving buy-in, Guillermo talked about directly telling the teams what does this mean explicitly for them. You have to make it mutually beneficial!

Data Mesh Radio is hosted by Scott Hirleman. If you want to connect with Scott, reach out to him on LinkedIn: https://www.linkedin.com/in/scotthirleman/

If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

All music used this episode was found on PixaBay and was created by (including slight edits by Scott Hirleman): Lesfm, MondayHopes, SergeQuadrado, ItsWatR, Lexin_Music, and/or nevesf

The Match Ball: Leeds United 4-1 Huddersfield Town