Data Mesh Radio

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 hereEpisode 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.Immanuel's LinkedIn: https://www.linkedin.com/in/immanuel-schweizer-17839242/In this episode, Scott interviewed Immanuel Schweizer, the Data Officer for EMD Electronics.Some interesting thoughts and questions from the conversation:Good governance starts at data collection - what are ethical and compliant ways to collect data from the beginning? This points to intentionality around data use stretching into the application - what should you collect that might not be part of the day-to-day application function but that might might lead to generating insights that will be used to generate a better user experience? And what are the ethical concerns?Should we initially create data products to serve specific use cases or should we focus on sharing data first and then shaping what people consume most into data products? EMD is approaching data products from a different angle than most, using the second approach.When looking at data mesh, should you start with the high data maturity teams or work to pull everyone up to at least a decent baseline maturity level? If you work with the most mature teams, will their challenges really be applicable to the not-so-mature domains? Can you find good reuse patterns to scale your mesh implementation?Domain owners are much more willing to share data if they understand use cases for how their data will be used and maintain control to prevent misuse. Reluctance comes from an incomplete picture causing concerns - the more visibility into how data can be and is being used, the more willing domain owners are to share. But understanding your end-to-end data supply chain is tough, especially to start. How do you evaluate when to spend the time with a domain to get them data mesh ready? If you need a high value use case to justify spending time with that domain, are you leaving many domains behind? This ties to #2 and #3.Set your target picture but be ready to adjust your target picture along the way. The world is ever changing, don't lock in to an expected target outcome.Good data governance is about speeding up 1) access to and 2) usage of data. EMD launched a data literacy program where the employees spend the majority of a 10 week timeframe learning about data and how to make use of it. For Immanuel, making things tangible relative to data makes people much less hesitant to explore and use data.You should make using data a "part of the job" so it is tracked and part of the review process. Otherwise, you are missing out on a key incentive to leverage data.How many people in your organization wish they could be leveraging data more often to make decisions? What's holding them back? Is it tooling, knowledge, incentivization, access, etc.?How can we democratize insights? So much of insight generation is one-off, how do we make that scalable, shareable, and repeatable?Per Immanuel, EMD's data mesh journey is not that typical in that they are still getting their arms around centralizing data in a constructive way. It was previously locked away in the domains. So, they are starting their data mesh - or decentralization - journey by centralizing data in a certain sense. Wannes Rosiers mentioned this at DPG Media as well. This enables breaking down silos and starting from common ways of working so there is more cohesiveness around centralized data sharing. There are some concerns from the domains about how do they maintain control to ensure compliant usage. As the team learn how to put their data onto centralized infrastructure, Immanuel shared that they are simultaneously working on how they will hand more control back to domains. EMD is in the initial stages of their data maturity journey but they are mapping out how they plan to move forward with next steps. They are focused on giving data producers the visibility to how their data is used so the data domain owners can feel comfortable. And Immanuel gave a good insight to those starting their data mesh journey: understanding the end-to-end data supply chain is really hard when you are just establishing that supply chain. And understanding that supply chain, how data is consumed downstream, is very important to giving the domains the visibility they need to feel comfortable sharing more and more of their data. Some are calling this data on the threshold - data might be data on the outside but isn't yet.Immanuel and team are starting their data mesh journey by bringing a significant amount of data into a central data lake and then watching for data consumption patterns emerge. Then, when there is a use case that is worthwhile, that will get promoted to being data product worthy. Then they work backward to find the owners so they can ensure the upstream data production is actually managed as a product. Now, since data challenges aren't flagged to a centralized team, the data can be fixed where it should be fixed - upstream, at the source systems.Based on that approach of getting access to data outside of data products, Immanuel mentioned how this could bring domains to the table sooner in a data mesh implementation. In his view, it is often quite expensive to get a domain on board and capable of sharing data like a product. So, if you require a specific, data consumer-driven use case or use cases before investing in that domain enough that they can share data, it can mean you only look for very large return use cases. Or that the initial cost of bringing a domain on to sharing on the mesh falls disproportionately on your early data products. In Immanuel's approach, the initial cost of sharing is much lower, and then use cases emerge to further justify work. So more domains share sooner. But it has the drawback of the domain not sharing their data intentionally upfront so it might not have as much of the domain context.Immanuel mentioned that you can't centralize ownership of data quality and access and expect to scale. You really need to figure out how you distribute your data ownership appropriately. And that you can't rely on a data engineer in every domain, so how do you lower the bar to sharing?Immanuel's approach to the big picture is to set a target picture and a north star but adjusting the expected target picture along the way. If you aren't flexible and aren't taking in new information and adjusting accordingly, are you really ready for the flexibility required to do data mesh?So how is EMD approaching their data strategy? Per Immanuel, they started with a company-wide data strategy - again, setting that high-level target picture. Then, they started to measure data maturity across each domain. They had to answer should they move ahead with domains that are already high data maturity or try to level up the capabilities of less mature domains so they can participate in a data sharing economy. They decided to focus on bringing all domains up to a certain maturity level - if you don't, it can mean issues scaling your approaches, per Immanuel. An example is that if one domain is doing MLOps with 10s of ML models in production and another domain is running everything off Excel and Access - or worse, PowerPoint - their needs may be completely different. The things you learn and ways of working you get from the very data mature team just won't translate well to immature domains so every domain will need specialized help. That just isn't scalable.Immanuel mentioned how data governance can often create mixed feelings. He said that good data governance is like brakes in your car - brakes are there to allow you to go fast safely. Governance is not about overseeing every bit of data usage, it's about speeding up access and usage of data. Governance should be an enabling factor in a best-case scenario. And that is why federated governance can be so powerful - we give the control to the people most worried about data usage and give them the tooling/knowledge to own most of that governance.EMD created a general data literacy campaign, making everyone aware of and on the same page about definitions for a lot of core concepts around data, analytics, use cases, etc. - making them all aware of the vocabulary. This was just the first step though. For Immanuel, he has seen data literacy success come from programs that take people by the hand regarding data and make them use the systems - the workflows and mechanisms - especially around governance. Hence, they created a 10 week program for focusing on using data. He said it is looking successful because it makes things so much more tangible. People can understand the entire flow of data through the system and then they have a better idea of what they could do. It's only just wrapping up its first cohort of people but the attendees seem very excited about it.In Immanuel's view, people are naturally curious around data. The issue with using data has been lack of tools and access to data in domains - sharing and leveraging data wasn't viewed as part of the typical job in most domains and it wasn't part of most people's KPIs or reviews. It is important to give them the right tools and the right incentives so people can and want to explore data and be curious. Pushing reports at people doesn't engage curiosity. Who is this new data and analytics world for? For Immanuel, it's for the people who are already data curious but aren't leveraging data nearly as much and/or as scalably as they could be - we need to give them the tools to make working with data more scalable and sharable. Then, data becomes a topic that is tangible for everyone in the business - can we start replacing Excel and PowerPoint but still make it simple for people to explore the data?Per Immanuel, part of moving towards scalable analytics requires us to unlock the one-off insight generation, make it so we can democratize the generated insights. There are too many instances of people generating good and useful insights that are just lost, only seen by that single person. And/or only seen that one time. How do we make it so there is an easy, happy path to sharing insights that are long-lived?When asked about the initial ROI on data mesh and the big data literacy campaign to-date, Immanuel pointed to the main value thus far has been giving people the capability and encouragement to explore data. Exploration has allowed people to understand the organization and they've found the most reused data - and then focused their data work efforts on the places people are using the most. That prevents time spent on data products that aren't valued by consumers.In wrapping up, a question Immanuel thinks it's important to ask: how do you define a happy place for your org and for each domain? No journey to a happy place will look alike. And no happy place will look alike either. What does a good state along the way look like? We don't need to be in a rush to get to the finish line.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 hereAll 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

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 hereEpisode 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.If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/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

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 hereEpisode 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.Jean-Michel's LinkedIn: https://www.linkedin.com/in/jmcoeur/In this episode, Scott interviewed Jean-Michel Coeur, who is the Head of the Data Practice at the consulting company Sourced Group. Jean-Michel has developed a simple three question framework that works well with people asking for data, especially business counterparts. The questions typically lead to collaboration instead of confrontation and gets data consumers to share what they want to accomplish with the data instead of what is their request. It feels more like a friendly chat than an interrogation or "prove to me why this is worth my time". He also recommends following up each question with "the reason I am asking is..." to explain specifically you aren't pushing back, merely information gathering.The three questions:Do you know what this is for?Do you know who is going to use it?Do you know how they are going to use it?Jean-Michel developed his three question framework after watching people struggle for years to properly request data and/or properly understand the use case of data consumers, often delivering solutions that did not meet business needs, wasting everyone's time. Oftentimes, the technical person wouldn't ask the right questions or they couldn't even get to the end data consumer so they didn't really understand the reasons for the data ask.For Jean-Michel, the first question - Do you know what this is for? - helps to set the tone. It is not "why do you want this?", which often makes people defensive. He tells the person making the ask that with more context, his team can better understand how to make what they deliver better. And sometimes, the person making the request will realize they aren't really sure what it will be used for and can go back to the end user. A key is to not be a gatekeeper to the data, both in reality and perception.The second question - Do you know who is going to use it? - starts to drive towards who will consume the data output and how - the use case is pretty important for delivering valuable data after all. For Jean-Michel, asking it in this way can often empower the person making the data request to lead the journey rather than undercutting them to get to the end user. It makes them part of the team. This is far better than the reaction he got previously when asking "who is the end user and what do they want?" The final question - Do you know how they are going to use it? - means you can own the data user experience all the way through to the end consumption. Oftentimes, people deliver just the data into a warehouse or similar but if that is used in a dashboard, the dashboard is the user experience. This final question also helps data producers to suggest additional value-add features or to push back on some ill-defined requirements. E.g. "real-time" rarely actually means real-time. And Jean-Michel recommends understanding what you are delivering well enough to be able to answer the question of "okay, what does this mean?" After all, data projects/products are meant to deliver value and the value is informing business decisions with data.And again, a crucial part of the conversation to add after each question is an explanation of why you are asking. This isn't pushback, it's information gathering. It's how product marketing and product management are done! If you come at these questions from an empathetic angle, you all have a better chance of a positive outcome.The output from the three questions is also immensely helpful to the data producing team. It ensures there is a real use case with real business value. It validates there is really an intention to use the data - otherwise Jean-Michel will push back. And it sets up a collaborative approach where the data producing team can make good suggestions for additional value.Jean-Michel talked about the fallacy of the data 'Field of Dreams' of "if you build it, they will come." The users will come. The value will come. Instead, work with intentionality. Any data you produce to share should be useful to someone. If you aren't sure, have the conversation with potential users. But just storing data has a cost and are you really going to be able to enrich it enough to make it useful in the future?One thing Jean-Michel thinks many companies get wrong is that when building a data platform, there is a window of opportunity and many data infrastructure teams want to build everything themselves, pushing out your time to returns. The tendency to be tech-oriented often comes at the expense of user experience as well. Data infrastructure teams need to think about the primary reason for a data platform: collecting and producing data.For Jean-Michel, the concept of a data product owner in data mesh might not extend far enough. If you are producing data for consumers, you should own the full user experience. If people are consuming from reports, you should own that report. Same for a dashboard. We have to be careful to not leave those less data literate behind while helping them up their data skills.Jean-Michel wrapped the conversation by saying every time you are asked to deliver data, be prepared to answer the "so what" question from a data consumer/stakeholder. Be prepared with something to answer. You are a partner to the business, not just a "data report monkey" so add that value and build the relationship with your business counterpart.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 hereAll 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

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 hereEpisode 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.If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/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

In this episode, Scott interviewed Ole Olesen-Bagneux, an Enterprise Architect who focuses on data at GN and the author of an upcoming book on data catalogs with O'Reilly. The two main topics were: 1) how can we better understand and handle data domains, and 2) searching for data rather than just in data.

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 hereEpisode 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.If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/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

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 hereEpisode 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.Shane's LinkedIn: https://www.linkedin.com/in/shagility/Shane's Twitter: @shagility / https://twitter.com/shagilityAgileData.io website: https://agiledata.io/AgileData Way of Working: https://wow.agiledata.io/Shane's Podcasts: https://agiledata.io/podcasts/In this episode, Scott interviewed Shane Gibson, CPO/Co-Founder of AgileData.io and Agile Data Coach. A few takeaways from Shane to start:- Agile methodology is about finding patterns that might work, trying them out and deciding to iterate or toss out the pattern. It's going to be hard to directly apply software engineering patterns to data but we should look for inspiration there and then tweak them.- Any time you look at a pattern you might want to adopt or evaluate if a pattern is working for you, ask yourself: will this/does this empower the team to work more effectively?- Applying patterns is a bit of a squishy business. Get comfortable that you won't be able to exactly measure if something is working. But also have an end goal in mind for adopting a pattern - what are you trying to achieve and is this pattern likely to help you achieve that?- Share your patterns to not only help others but to get feedback and maybe ideas to iterate your pattern further.Shane's last 8 years have been about taking Agile practices and patterns and applying them to data as an Agile Data Coach. And those patterns required a lot of tweaks to make them work for data. A big learning from that work is that when applying patterns in Agile in general, and specifically in data, each organization - even each team - needs to test and tweak/iterate on patterns. And that patterns can start valuable, lose value, and then become valuable again. Shane gave the example of daily standups drive collaboration as a forcing function but then lose value when that collaboration becomes a standard team practice. If there is a disruption to the team where collaboration is no longer standard practice, daily standups could get value again. So how do we apply these Agile concepts to data?Currently, Shane sees no real patterns emerging in the data mesh space - it is quite early as patterns often take 5-8 years to develop and data mesh is maybe 12 months in to even moderately broad adoption and is such a wide practice area, there are many practice areas that patterns will need to cover. But, that lack of patterns makes it quite hard for even those who want to be on the leading edge of implementing data mesh instead of the true bleeding edge - having to invent everything yourself is taxing work! So we need companies to really take existing patterns, iterate on them, and then tell the world what worked and what didn't. If people aren't sharing patterns, that's going to make it hard to adopt data mesh for many organizations.Shane believes that it will likely be pretty hard for many organizations - or at least many parts of large organizations - to give application developers in the domain the responsibility of creating data products. If your domains aren't already quite technically capable in building software products, it's going to be very hard for them to really handle data needs. So looking at domains that are using large, out-of-the-box enterprise platforms or SaaS solutions instead of rolling their own software, will they really have the capability to manage data as a product? If their domains don't have the most complex of data, maybe? But if they do, are they really mature enough to handle it? A very valid question.To really be agile, using Agile methodologies, you need to first adopt the Agile mindset and not just patterns and practices, per Shane. Agile is really about experimenting with a pattern and either iterating to make it better or throwing it out. It's not about being precious. As mentioned earlier, you should also throw out patterns that were effective and aren't helping you any more. You need to do the same at the team and organizational level if you are going to successfully implement something like data mesh. Your teams and your organization are like a living, changing, evolving organism - treat them as such.A very important point Shane made is data mesh isn't solution - it needs to at most be a way of approaching your data and analytical challenges of organization but with a true purpose in mind. The purpose isn't implementing data mesh. The purpose is a business objective or challenge and data mesh is helping you tackle that. Also, data mesh is not the right solution for many organizations, especially smaller ones or ones that don't have highly complex data needs - those organizations should review data mesh and understand the principles and work towards them but your real challenge isn't the centralized team being a bottleneck so don't take on the pain of decentralizing to be hip and trendy.For those who haven't really dealt with Agile, a "fun" potential learning, per Shane, is that there isn't really a great pattern for measuring if a certain pattern is working. Proving how well something is working is pretty impossible so a large part of it is feel - we chose this pattern to improve collaboration. Do we believe our collaboration has improved? If yes, great, let's try to iterate and improve a bit more. If no or our collaboration has even gone down, get rid of it!Per Shane, when evaluating if you are effective in your Agile methodology, ask: does the organization empower this team to work effectively? You will probably need to look at this on a team by team basis and repeatedly ask this question over time. Trying to scale Agile to fit all teams in an organization is often an anti-pattern. And if you are in a hierarchical company, adopting Agile patterns alone is probably not going to change the way you work in the long-run, you need to break the hierarchies in some way.For Shane, there is a big question that data mesh has yet to answer: can we really move the data production and ownership to the application developers? He thinks if we look at DevOps and how developers took on the necessary work for testing and CI/CD, we can. But then the even bigger question is how. How can we map the language of what needs to get done to the software engineering semantics?For Shane, the idea of a proof of concept - PoC - is just broken. We need to rethink it entirely, especially for data mesh. What are you really trying to prove out? He believes there are typically two types of PoCs and most default to Type 1 when potential beneficiaries expect the output of Type 2. In Type 1 PoCs, you are out to prove a high-level hypothesis that has lots of uncertainty. It's about experimentation and doing it in a "quick and dirty" way that is not ready for production. But the output of Type 1 is all about proving out the hypothesis - not a production-ready result. Type 2 is a minimum viable product or minimum valuable product - what can we strip away from our end goal to get to something that can be used and is - mostly - productionalizeable. Literally what is the minimum that is viable? It is about proving the capability to deliver and delivering something of value sooner. So ask yourself, what are you really trying to prove in your PoC?Shane finished on three points:- Empower your teams to change the way they work- Stop vendor and methodology washing data mesh- Regarding data mesh, share what patterns you are trying to adopt, why you chose them, and what is working/not working. Data mesh can only evolve to something really great if we work together and share more information.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 hereAll 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

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 hereEpisode 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.If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/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

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 hereEpisode 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 hereVincent's LinkedIn: https://www.linkedin.com/in/koconder/In this episode, Scott interviewed Vincent Koc, Head of Data at the merchant platform company hipages.To start with some big takeaways from Vincent:If you aren't comfortable with an agile mindset and ambiguity, bleeding edge probably isn't for you - and that's okay!You and your organization need to be comfortable with failing, learning, and then iteratingTo get data mesh - or really any big change initiative in data - right you should focus on change management much more than you probably thinkIt ends up being the secret sauce or crucial lacking factor much more often than the techThink problem-specific, not technology specificIt's easy to over-engineer the problem - technologists want to technologyIn general, consistency is key to achieving widespread success in dataOne domain having a major success won't lead to broader org-wide success if you don't look to leverage reusability factors to make consistency across other domains easy - a bunch of great but non-consistent solutions doesn't add up to a valuable whole pictureFor Vincent, every organization considering data mesh should ask if it is really the correct approach for them. Data mesh really isn't for a large subset of organizations, whether that is right now or even ever. If your organization doesn't have an appetite for change, it's going to be very tough to move towards data mesh. If you want to implement data mesh, he recommends embracing an agile methodology e.g. fast feedback and trial and error.When thinking about splitting your data monolith into domains, Vincent recommends taking a lot of learnings from what works well in the microservices realm. You shouldn't decompose everything all at once - that just creates chaos. You can split out larger domains one by one and then figure out if you need to split them further when there is more value in doing so. Peel them off instead of a big bang approach.Vincent believes that, in general, ~20% of your teams will consume ~80% of your data team's time and energy. There are a few ways to work with those teams to reduce that but it is also somewhat a fact of reality. Whether that is because those domains are more prominent, noisy, well loved, or for many other reasons. That data work disparity often leads to those areas being more data mature.When discussing disparate data maturity, Vincent talked about the need to drive all domains that will participate in something like data mesh to at least a common base level of maturity. You have to have a relatively mature domain to be at what he referred to as "mesh-level capability". Domains that aren't at that capability will still need to rely more heavily on centralized data teams and capabilities as they improve their data maturity. And it's okay to work with them closely to up their maturity level - just telling them to catch up is probably not going to work, there will need to be a bit of hand-holding.Vincent believes embedding data analysts - whether you call them data analysts, analytics engineers, or something else - into domains is crucial, especially if you are going to attempt to implement data mesh. They serve as the custodians of the data for the domain, whether that is data shared with others via a data product like in data mesh or for data the domain regularly consumes and uses from the domain and external sources. One point Vincent thinks is crucial to moving forward in data mesh is that those data custodians need to help disseminate data knowledge to software engineers and the organization needs to build tools and frameworks to make it easier for software engineers to own and manage data.When asked about the balance between long and short-term planning, Vincent talked about with an agile methodology, you need to "cater to today" and not get overly focused on the long-term exact plan/roadmap. Things will change. Set yourself on a good path, set that North Star, and keep your ears and eyes open for the signals you need to change your plan. E.g. look at what a domain could become with the right direction and set it on that path to positive evolution as best as possible. But don't overly define the path.Vincent talked about how crucial - and often overlooked or ignored - good change management is for data organizations. Now more than ever due to how fast the world and the data landscape is changing. It's crucial to break down changes into terms and/or actions that all constituents can understand. The organizational is much more important than the technology in most respects. To drive buy-in , Vincent has seen giving people agency over their data work well. Giving domains the trust AND the tools/frameworks/resources to manage their data gets those business leaders/domain owners to come to the table quite often. But you can't just give them the responsibility without the additional help.Vincent discussed some past approaches that he would do differently now. He focused too much on the technology and telling others exactly how something should work or look instead of working with them to drive to the outcome and let them figure out the right path - while helping them along the way. Give them the big picture and talk to the outcome rather than the technology. To do that, Vincent talked about building out a pattern but not the whole picture; give them a defined enough idea of a good outcome but not overly defined. And build in the easy path or golden path boiler plates where it makes sense through templates but with extensibility - if things are too rigid, people will thrash against that. It is quite easy to over-engineer solutions - think problem-specific, not technology-specific.Specific to data mesh, Vincent sees one of the big remaining questions out there is how to actually automate and decentralize governance, especial things like access control. There isn't much good specifics on how to set up security as code in a scalable way. And we need to think about security as a sliding scale of risk.Vincent shared a few words of wisdom near the conclusion for data leaders. The first was how easy it is to see something like data mesh, get very excited, and try to do a whole lot of changes at once. Making mass changes causes instability - instead, think about where you can be more targeted in support of the long-term big picture. Don't boil the ocean. The second was get comfortable with ambiguity and think if your organization is aligned to accepting ambiguity - if you aren't comfortable with ambiguity, stay away from bleeding edge. It's called bleeding for a reason. You need the ability to try/test, fail, learn, and then iterate towards a better solution. If failure isn't allowed and maybe even celebrated, the bleeding edge is probably for braver souls.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 hereAll 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

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 hereEpisode 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.If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/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