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.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/Sponsored by NextData, Zhamak's company that is helping ease data product creation.For more great content from Zhamak, check out her book on data mesh, a book she collaborated on, her LinkedIn, and her Twitter. 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 hereData Mesh Radio 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.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.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. You can download their Data Mesh for Dummies e-book (info gated) here.Karin's LinkedIn: https://www.linkedin.com/in/karin-hakansson/In this episode, Scott interviewed Karin Håkansson, Data Governance Lead consulting on a large data mesh implementation. To be clear, Karin was only representing her own views on the episode.If there is one theme that resonated throughout the conversation, it was have more and deeper conversations with your data governance teams. Don't make assumptions and as a data governance team, don't make decrees - explain what you are trying to accomplish and why. And look to help where possible instead of telling people how to do things.Some key takeaways/thoughts from Karin's point of view:Data governance teams need to get closer to both data producers and consumers; but when doing that, emphasize it isn't about control or oversight. You are there to help.Data producers and consumers need to share with the governance team about their pains and challenges - the governance team in most orgs is there to help. So get specific about where you need help. Emphasis on specific!To get closer to data producers and/or consumers, identify a few obvious data problem areas and just reach out to those involved/impacted. Focus on asking not telling when digging into the pain points. And involve all stakeholders in assessing potential solutions to get them bought in to the eventual solution. A control-based data governance approach doesn't add value to your data. We need new ways of working in data governance focused on adding value, not adding roadblocks.Data mesh creates an environment where we need to look at things differently. And it provides the excuse to look at them differently too. Challenge your base assumptions.If your organization isn't open to finding and implementing new ways of working, it will be challenging - at best - to implement data mesh. Really ask if you are ready for the change before implementing it.Data governance teams need to focus on finding long-term solutions and balancing those with temporary fixes. Be extremely clear about what is a temporary fix and why it's temporary and must be replaced.Always keep people informed as to progress - even if it is "no progress". Humans aren't good with uncertainty.Data governance teams can easily be overwhelmed if you don't develop good ways to prioritize. Find the most important - not necessarily the most obvious - pain points and assess the value of fixing them.Karin started the conversation sharing her background - before being "pulled" into the world of data governance - as a software engineer, data engineer, and more. She's always worked with data but only recently started focusing on data governance. Her prior background has given her the perspective needed to understand problems from the perspective of both data producers and consumers and how to best help them as the data governance team.So, with that perspective, Karin is focused on finding new ways to get closer to both the data producers and consumers - but focusing on how that closer relationship serves as a helping hand, not in an oversight or control standpoint. And now seeing things from the data governance team's perspective, she and her team are there to be helpful and add value.When asked how she recommends getting closer to data producers and consumers, Karin said finding a somewhat obvious data challenge - where are people complaining loudly? - and initiate a conversation as someone who might be able to help. And when you do get to speak with the stakeholders, focus on listening - ask, don't tell. Really dig into the pain points instead of trying to jump to a solution as quickly as possible. Usually the pain points are pretty well known. Start from a blameless perspective - choices were made and we need to fix the situation, not assign blame. And by involving the business people in the conversation - especially in assessing the solutions - they are more bought in to the outcome because they helped pick it. In data mesh, we have to do data governance a bit differently according to Karin. No longer the ever watchful control tower - or Sauron's Eye -, we need to find ways to make data governance agile and flexible - Laura Madsen focused on this as well in her episode. A data governance approach based on control won't actually add value to your data - and why have governance if it isn't adding value? Historically, a lot of data governance teams have focused on creating a standard way of working instead of standard outcomes. Governance people need to involve stakeholders in determining ideal outcomes, not have a checklist-type approach. Data producers and consumers running into issues should be able to go to the governance team for help; and they should ask what the governance team is trying to achieve and they might find better ways of working together. For Karin, data mesh creates an environment where we need to - and have an excuse to - look at things differently. We must challenge our base assumptions and, where necessary, look for new ways of working. But we also have lots of existing approaches that will work as well. We need to evaluate and be open to change when it is useful. Before embarking on data mesh or evaluating a major change in ways of working, you should ask if you are really ready for that change.While the implementation Karin is working on hasn't deployed a considerable number of data products, what she's seen so far relative to data product ownership is promising. When they are really giving people full trust in owning their data, she believes they will step up. But you need to make sure they understand the new responsibilities, the new potential roles, and the value the data products bring to the organization. And drive more buy-in by helping them find additional value in understanding their internal data consumers - it might lead to additional insights for their own domains.In wrapping up, Karin shared her thoughts on implementing temporary fixes - it's very easy for a data governance team to run around trying to do temporary fixes but it won't scale. Temporary fixes can have value but you must look for longer-term solutions to replace them. And be explicit with stakeholders about what is and what isn't temporary. As you build towards long-term solutions, always keep your stakeholders up-to-date on progress, even if that is "no progress". Humans don't do well with uncertainty. Data governance teams can become easily overwhelmed - you can't do it all. You must find a good way to prioritize - find the most important pain points and assess the value of fixing them. And really consider value, not just how much pain it seems to cause.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. You can download their Data Mesh for Dummies e-book (info gated) here.Scott's LinkedIn: https://www.linkedin.com/in/scottmztaylor/Scott's Website: https://www.metametaconsulting.com/Scott's Book: https://technicspub.com/data-storytelling/ (save 20% off with code DATAWHISPERER)Scott's YouTube playlist: https://www.youtube.com/playlist?list=PLashWxBySOAOKUtvn2NTBQeENJTLB8NoSIn this episode, Scott interviewed Scott Taylor AKA the Data Whisperer.From here forwards, "Scott T" will be used to represent Scott Taylor to differentiate from your host. It's also important to note Scott T differentiates 'data management' from 'analytics', so things like data governance and infrastructure fall under data management.Some key takeaways/thoughts from Scott T's point of view:To actually reliably successfully obtain funding for data management initiatives, you need to articulate the value of the work to the business - why does this matter? Storytelling is key.The quickest way to lose your shot at securing funding for data initiatives is to focus on the how instead of the why. Most execs do not care at all how it gets done. They hired you, the data leader, to handle that.To get funding, focus your messaging on tying your data strategy and proposed data initiatives to the business strategy. Why does this matter - how will this drive the business strategy forward?Be prepared for cynicism from the business side - many have heard about how this or that data/technology initiative will be the silver bullet for far too long.Digital transformation is an enormous opportunity to change how your organization deals with data. Use that as a good point of leverage for funding your data management - it's a necessary foundation for a digital enterprise.'Story' is about constructing a narrative and 'telling' is about effectively communicating. So storytelling is about effectively communicating what is the target outcome and why will this drive value.Data storytelling is an art, not a science. You need practice to get good at it. Don't make your 'practice' be overly high stakes. Talk to a lot of folks on your side to hone your talking points. You don't publish the first draft of a book do you? Find your editors.Focus on empathy and listening to find your audience's aspirations and pain points. Then tie your messaging about your data initiatives to those aspirations and pain points.When you get to a yes, stop talking. Is your point to get the yes or is it to tell them all you planned to tell them?Scott T shared a bit about his history and seeing the same patterns repeatedly, especially the need effectively communicate to get funding for data initiatives. To actually obtain funding for those data management initiatives, you need to articulate the value to the business of the work. And many data people do that pretty darn poorly if at all.Where do things typically go wrong in getting funding for data management? Per Scott T, it's when the person asking for funding focuses the conversation on the how - e.g. how exactly are we going to implement data governance? Generally, the audience cares only about the why. Why is this important? They want to trust you to execute on the how. The how is crucial, but that's why they hired you - to take care of the how.So Scott T recommends again starting from the why. Show them how this data management initiative will enable the business strategy. Because why have a data strategy if it doesn't drive the business strategy? Scott T has seen a number of times where data folks don't focus on how the data strategy ties to the business strategy and the perception - and often the reality - is that the data folks don't really understand what the business does and/or what drives the business results. That's obviously going to hurt chances of getting funding.So what actually is data storytelling and how does it work? According to Scott T, there is the storytelling with data - which is not his focus - and storytelling about data, that data management side. Breaking it down into 3 component parts. Data - you are talking about data initiatives. Story - constructing a narrative. Telling - how you actually communicate what you are doing and why. It's an art not a science unfortunately but gets much better with practice. You need to get your audience emotionally attached to the outcome to get them bought in to funding it. This isn't a movie or a novel, you don't get a chance at exposition - it's a pitch, get their attention. And be prepared for - and welcome - the interruption. It means they are at least engaged if not bought in just yet. Your objective is to not get through all your slides because they were too interested.To prepare your pitch for your data initiatives, Scott T recommends you really focus on what the decision makers are talking about - both their aspirations and their pain points. Then look to tie your data initiatives to those. What are they trying to do and where are they trying to take the business? How can your initiative get them there faster/better/cheaper/etc.? What are the problems they are having? Talk to those exact pain points and how your data initiative addresses them. What are the strategic intentions of the organization? This will take a fair bit of empathy and learning how to really listen and then, again, practice to tie your pitch back to their aspirations and pain points.Scott T shared his 3 'V's of data storytelling - playing off the 3 'V's of big data -: vocabulary, voice, and vision. You need to combine all three to effectively tell your story. Don't talk in data language, use the language of the business. Make it an interactive conversation, not you talking at them. Show them why this matters and why doing your initiative will drive business results. Again, your data strategy must be about the business strategy.Scott T finished on his mantra: Truth before meaning.Quick tidbits from Scott T:Be prepared for cynicism from the business side - many have heard about how this or that data/technology initiative will be the silver bullet for far too long and they haven't delivered.Digital transformation is an enormous opportunity to change how your organization deals with data. It's a major potential accelerant for the business. Use that as a good point of leverage to pitch your data initiatives.There are 4 ways data can add value according to Scott T. 1) grow the business, 2) improve the business, 3) protect the business, and 4) sustain the business. Be clear on which ones your initiative focuses on.There are a number of sales and marketing techniques people can learn to become effective at data storytelling. You want to take your audience from "what are you talking about" to "we can't live without this". But it takes practice.Data management is the less attractive side of data and analytics but it's the foundation. You can't build a stable building, a stable home without a good foundation. When you get to a yes, stop talking. Is your point to get the yes or is it to tell them all you wanted or planned to tell them?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/Inverse Conway Maneuver Definition: https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuverSponsored by NextData, Zhamak's company that is helping ease data product creation.For more great content from Zhamak, check out her book on data mesh, a book she collaborated on, her LinkedIn, and her Twitter. 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 hereData Mesh Radio 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.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. You can download their Data Mesh for Dummies e-book (info gated) here.Glovo's meetup group: https://www.meetup.com/glovo-tech-talks/Javo's LinkedIn: https://www.linkedin.com/in/javiergrandag/Javo's Twitter: @JavierGrandaG / https://twitter.com/JavierGrandaGPablo's LinkedIn: https://www.linkedin.com/in/pabloginerabad/In this episode, Scott interviewed Pablo Giner Abad, Global Director of Data and Javier "Javo" Granda, Senior Data Manager at Glovo.From here forward in this write-up, P&J will refer to Javo and Pablo rather than trying to specifically call out who said which part.Some key takeaways/thoughts from P&J's point of view:It's okay to not fit the exact or complete picture of data mesh in your early journey. Focus on what matters to your org and implementation and focus on learning over trying to be perfect. Iteration is possible and not too costly with data mesh. That's sort of one of the main points of data mesh.When selecting your first use case, look for high value and low dependencies. The less cross-team coordination work needed to actually get to an initial end data product that has value, the better. And buy-in is much easier if the producers are one of the consumers too :)When starting out, really look at how thin of a slice you can get away with for your MVP. Be prepared to make some hard compromises. Make them with your eyes open. It's tech debt but taken on consciously.Focus on solving your problems of today instead of trying to solve all your future problems. Fixing the challenges of today will set you up to fix the challenges of 6 months from now in 6 months.Focus on reducing cycle times to creating and iterating on data products more than you probably think you should. It's easy to get focused on delivering new data products instead of the capabilities to deliver new data products but that will cost you more and more as your data mesh implementation matures.An important quote to remember re product thinking: "If you aren't embarrassed by the first version of your product, you shipped too late." Your data products don't need to be perfect when launched.Just using your domain mapping from your operational/DDD side as your data domain map is likely to lead to some big challenges. Look to how your data flows to figure out good data domain mapping.Misaligned domain maps between the operational side and data side can also cause issues because a team may need to own the data domain but they don't necessarily own the operational system or domain.Glovo's biggest data pain point pre data mesh was that data quality was often not great and people spent huge amounts of time trying to check the data. If that's a challenge at your org, you can probably get funding to fix it.If data trust is a key pain point, when you make compromises early, do not compromise on quality - or at least very clear communication on what quality means. That is the only real way to gain back people's trust - actually provide them high quality, trustable data.Domain ownership is likely to be the most challenging data mesh principle in many organizations. Partially because it is the one that is most centered on change management.It's easy for a central data team to fall into prioritization by loudest escalations. When moving to data mesh, make sure you don't fall into the same trap anywhere. Make conscious decisions based on value not on loudness.It will be important to define your minimum viable data product. Is that the data shaped into a format consumers can use? Does that mean if target users are not that data literate, ownership extends into the visualization tooling? Hard to say what is right for every organization.Only produce a data product if there is a known use case. But once a data product is created, owners should think about how they might serve additional users.There needs to be more specific examples of what people's early platform builds look like. It's really tough to think about every capability and what might fit where.P&J started out the conversation sharing about Glovo's history with data - they have always had a lot of data and been data heavy but how they handled data was not very structured; they didn't focus much on the data architecture. They treated the data warehouse like a data lake, dumping things in with little to no data modelling. People didn't trust the data so they spent huge amounts of time checking data quality - and the company made some crucial decisions on data that wasn't all that great. Their data architectural choices were creating more and more bottlenecks as well according to P&J because everything was reliant on the central team to build and fix. They clearly couldn't scale to meet the company's needs. They built out the tech to try to support needs remove bottlenecks based on technical throughput/scale but the central team itself was never going to scale to meet their needs. Per P&J, in a way, their problematic setup was helpful for data mesh buy-in because they had so much tech debt, it was easier to convince everyone they needed to move to something different rather than try to incrementally improve. Escalation by who screamed loudest just wasn't working and the central data team was falling more and more behind. There was a strong demand for understandable reliability - what was the actual quality level? - and clear ownership of data.Rather than trying for a short-term fix, they looked to build their long-term data strategy according to P&J. Where did they want to go with data. Data mesh came at the right time and gave them the structure they needed to start really identifying their issues and setting their forward vision. They knew they needed the agnostic platform to serve the broader company instead of point solutions. They wanted to really apply product thinking to data. Federated governance and domain ownership of data were more new to them so it has been harder to really figure those out.P&J shared their initial plans which fits a common theme in Data Mesh Radio episodes: make a thin slice of every aspect they'd need - but make some hard compromises. They knew they needed a platform that could at least read and process data. Their first few data products were more shared ownership between the domains and the central data teams. Etc. It's okay to not fit the complete picture of data mesh when you get going. The business leaders didn't really care exactly how it got done, only that it got done according to P&J. So they chose security and quality as their main focuses. Quality was very crucial to regain data consumer trust so they created tests to show what were the expectations and that the data products were actually meeting those expectations. Security was basically to protect PII - they didn't need anything too complicated so they only built to what they needed.On picking their first use case, P&J and team looked for a use case that had high value and low dependencies. The more dependencies, the more possible complications and ways to fail. So they chose customer interactions in the app - what were people actually doing in their app? Previously, to get at the data, it was very difficult because of many complicated combinations of data. The producers for that first use case really didn't have to do too much, the data was already being created in a format that was close to usable. And the producers were also the consumers, which obviously made it much easier to drive buy-in.At Glovo, every data set, every data quantum must have a clear owner but they did save a lot of that change management pain until later. They didn't force the data producers to really own their data products and had the central data team really as the owner or at least co-owner. They are now pushing that ownership on to the producers and there is a fair amount of friction. P&J brought up the quote from Reid Hoffman, who founded LinkedIn: "If you aren't embarrassed by the first version of your product, you shipped too late." So what is a minimum viable data product at Glovo? It is a data set, a group of tables, that has some amount of enrichment and structured to be used by the target data consumers. But they found that business leaders didn't really care about data products as units of business value until they connected the visualization tooling. So if it's not really usable by the target customer, is it really product-ready? How far into how data consumers use the data products does ownership extend?As other guests have mentioned, P&J agree you should only produce a data product if there is a known need. But prior to data mesh, teams were only serving the needs of the teams closest to them in the organization. Now, data producers are thinking about who all could use the data and finding interesting new consumers, uncovering new potential use cases.When asked what they wish they had been told when they started their data mesh journey, P&J shared a lot. One is to focus on the problems you have now and set yourself up to focus on the problems six months down the road when you are six months down the road. This was especially an issue with the platform team not serving what was needed now to try to build out the capabilities to support future use cases instead of the current use cases. Another is to focus a lot on capabilities - Glovo was focused on delivering data products but they wish they had focused on reducing cycle times to creating new data products. Another few: building cross-functional teams is crucial but always challenging; you need to be prepared to communicate more frequently than you probably expect and repeat yourself often. And lastly domain ownership will likely be a challenge in many cases.P&J discussed how the data team "inherited" the existing domain map and they are still struggling somewhat with mapping out their data domains and how they differ to their operational domains. Just following the operational domains caused a number of challenges as it often didn't align with how data was flowing through their systems for analytical use. Mapping out your data flows is crucial to establish the right data domain ownership. But then shifting data ownership to other domains is also a challenge. Not an easy thing to solve unfortunately.Domain ownership is causing a lot of issues currently - data ownership is typically not an expected responsibility for domains per P&J. Changing ownership from outside the operational domain to the team - because it is in their data domain, is also very challenging. They are struggling to really define each data domain and why these data domains are needed instead of just using the operational domains. So P&J are asking for more people to create content around domain ownership.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. You can download their Data Mesh for Dummies e-book (info gated) here.Darshana's LinkedIn: https://www.linkedin.com/in/darshana-thakker/In this episode, Scott interviewed Darshana Thakker, Architecture Director at BCG Platinion.Some key takeaways/thoughts from Darshana's point of view:Data can be the enabler to achieving your business goals but only if you actually tie your data work to your business strategy and goals.Speaking data jargon when talking to the business stakeholders makes it hard to actually communicate. Focus on speaking to business outcomes and business value.When selecting your first use case(s) for data mesh, evaluate domains on four different metrics: business value, capabilities, eagerness, and feasibility. There isn't a golden formula but it's likely some domains/use cases will rise to the top pretty quickly. Look to - as best as you can - quantify the incremental business value from something like data mesh. That can be at the micro level - the single use case - or the macro level. But getting specific instead of "let's be data-driven" will lead to better buy-in and partnering with the business side.You need to prepare to evolve your architecture. You can't have things set in stone. But you also can't just throw things against the wall and see what sticks. You need a balance between overly rigid and overly flexible.If your centralized data function isn't a bottleneck, isn't the cause of your data challenges, data mesh probably isn't right for your organization - or at least it doesn't directly address your challenges. Time between identifying useful data and making it reliably available is a good place to look to measure if the centralized team is your bottleneck.A good buy-in driving question for data mesh - or any data initiative - is "what's the cost of doing nothing?" Will you miss opportunities? Lose market share? How much are you "paying" on your existing tech debt? If we don't move, what is the cost to our future business prospects?When looking at buy-in, you need to drive from the top down - so you can actually make necessary large-scale org-wide changes - and bottom up - so you are working well with the people doing the actual implementations. Data mesh feels a lot like the Agile movement in that people expect it to be a silver bullet instead of a framework for thinking - and re-thinking - about how you approach your work.As also recommended by previous guests, look to a vertical thin slice for your data mesh MVP. Make sure you include all necessary high-level capabilities - think the four data mesh principles - but don't boil the ocean, pick a manageable use case.Keep technologists from focusing on the tech instead of the outcome - why would we use this and what is the business value? And what is the cost to launch and maintain it? Is it actually worth it?If you are prioritizing you technology backlog, it's like "serving food to customers they didn't order" - you are putting together technology solutions that aren't what they want. Darshana started the conversation admitting to being a technologist at heart - but argued we can't become over enamored with technology in data. Focus on the business outcomes! If you are prioritizing your technology backlog, it's like "serving food to customers they didn't order" - you are putting together technology solutions that aren't what they want or need. We have to move away from the concept that technology will solve your problems - it's very easy to listen to the vendor BS because people don't want to do the hard parts of solving data challenges. And the truth is, every situation is different and we can't copy-paste solutions. But that means signing up for hard work :)To keep yourself from not going down the tech-focused rabbit hole, Darshana recommends asking more layers of "why" to people selecting technology. Okay, you want to use the latest and greatest tech - why? Why is this better than another solution? Why do we need to solve the issues it supposedly addresses? Why can't we use what we already have? This can questioning can drive technologists to use common vocabulary between tech and business by focusing on why are we actually doing work - what is the target business outcome? Every data team should be asking "what are you building for the business leaders?" Because if you can't answer that, are you actually adding value to the business?A good question Darshana believes every company should ask - what are you trying to achieve when working with your data, especially something like data mesh? Is it just having the cleanest data possible? Or are you focused on serving customers better? Data can be the enabler to achieving your business goals but only if you actually tie your data work to your business strategy and goals.For data mesh, it is typically the CTOs and/or CIOs that are the biggest advocates and thought partners to the teams driving implementations according to Darshana. But, you can't just move data mesh forward without buy-in from other execs. You need budget - whether that is directly from the CFO or from the head of a business unit. To get that budget, you need to talk about what would doing something like data mesh do for the business. You need to consider how to actually quantify the benefit to them - is the first use case going to drive better revenues, lower costs, etc.? But also, what are the added benefits of being more agile and scalable with data? Can data mesh lead to better talent retention too? Talk about unlocking additional use cases and capturing opportunities far quicker. Asking the business leader to "imagine a world where…" is probably not going to go well so get as specific as you can - easier said than done of course. When working with the business to get buy-in for something like data mesh, Darshana recommends answering the question - before it's asked if possible - "what's the value of doing this?" Again, if you can get specific, that's great. Talk about total return - what are the upfront costs and the ongoing costs compared to return? But you can also ask "what's the cost of doing nothing?" Is that lost market share, lost opportunities, etc.? You can get the business counterparts to tell you what they are concerned about and you can help them address concerns with data. You can also point out the ongoing costs of your legacy stack / existing tech debt - you are incurring increasing costs just to keep it running.When asked about driving buy-in for data mesh whether that should be from top-down or bottom-up, Darshana answered "both". You need the top level support to be able to actually change the organization, upskill people, create new roles, etc. You need a holistic view of your entire implementation or you are likely to build something overly use case specific. But if you don't have domains - especially the people in those domains doing the work - understanding and bought-in to the changes needed to do data mesh well, it won't go well. So you need to drive buy-in from top-down and bottom-up simultaneously. Sorry, no short cuts :)In thinking about data mesh, Darshana has seen one big failure mode many overlook: many don't consider the ongoing costs of running something like data mesh. That's part of why it isn't for smaller organizations. Data mesh will probably result in higher costs than value for many organizations. It's hard to measure if your centralized data team is actually causing your data woes - every company has data woes, but it's more likely your centralized team is an issue if it takes a considerable amount of time from identifying data that would be good for a specific use case and then actually making it reliably available. Another potential challenge is around your "data transparency" - is your data well documented, understandable, etc.? If the responsibility for that is falling on your central team - who can't really have the context necessary to fully document the data in most cases - data mesh might be a good approach to consider.Another failure mode Darshana has seen for data mesh is not having a mindset focused on evolving architecture. You should focus on the themes and principles and not the exact architecture. Especially because it will change. You just can't future-proof your platform - build it to evolve. You will incur tech debt, but with this approach it is a conscious decision to take on that tech debt. But you also do not want to go too far to the other end of the spectrum - you don't want to set things in stone but you also want to have some intentionality. A 'just try and see what happens and then react' type method won't go well in data mesh…For actually getting going with data mesh, Darshana recommends an MVP via vertical thin slice. If this sounds familiar, it is becoming a recurring concept from many guests. To do your MVP for data mesh, you want to make sure you are not taking on too much, hence the thin slice. But you also want to make sure you incorporate all the high-level necessities of a data mesh implementation - so you can't just skip governance for example. You want to go after a small enough use case to not boil the ocean but also work on testing every necessary capability to go wide once you have built out your platform and figured out your repeatable ways of working. And it's okay to not get it perfect - the cost of change is far lower in data mesh - just drive towards value quickly.As for where to start on a data mesh implementation, Darshana recommends looking at all your key domains and evaluating them on four different metrics: business value, capabilities, eagerness, and feasibility. Business value is about how valuable are the use cases the domain might participate in - and you want to think about net return and how quickly that return will likely happen. Capabilities is about how capable are the domains of actually delivering on a use case or use cases that will drive good business value. You absolutely need a central team supporting them with certain capabilities but a low data maturity domain with complex use cases is not a great place to start. As past guests have also mentioned, sometimes you need to focus on the domains where they are eager to participate instead of trying to fight tooth-and-nail. And lastly is the feasibility of the actual use cases - can they actually be accomplished? The business value may be through the roof but will it take 18 months to get a use case out the door? Will you have to invent new technology to handle it? There isn't a golden formula but you should look at these four criteria when making a selection for your initial data mesh use cases and domains. Other Tidbits:Speaking data jargon when talking to the business stakeholders makes it hard to actually communicate. Focus on speaking to business outcomes and business value. They don't care if it is data mesh, data fabric, data unicorn farts, etc.For Darshana, data mesh feels a lot like the Agile movement in that people expect it to be a silver bullet instead of a framework for thinking - and re-thinking - about how you approach your work.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