Data Mesh Radio

Pink Xu, an expert in data products and data mesh, discusses the importance of measuring the impact and value of data products. They emphasize the need to standardize impact measurement, go beyond just financial impact, and consider short-term and long-term value. They also explore decision-making, data scores, and the challenges of measuring data product impact. Effective communication and involving teams in frameworks are highlighted, along with promoting data mesh understanding.

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. In this episode, Scott and Zhamak covered the misconception many have when she says "leave the data where it is" - it's about leaving the ownership with those who should have it, not leaving the data in the source system. If you only do source system, all you have is current state, so your data isn't even immutable or bi-temporal! They also discussed the need to be smarter about processing data - should it be at the source or should it be on query? There isn't a universal approach but we also shouldn't have to move the data around just to process it, bring the processing to the data. Lastly, we need systems to get smarter around efficient processing. We have far too much manual work on making data processing efficient.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.Andrew's LinkedIn: https://www.linkedin.com/in/andrewsharp27/Blog post "Data Mesh – Is this the evolutionary trigger to reinvigorate Data Governance?":https://www.theoaklandgroup.co.uk/data-mesh-is-this-the-evolutionary-trigger-to-reinvigorate-data-governance/In this episode, Scott interviewed Andrew Sharp, Data Governance Lead at the consulting company The Oakland Group based in Leeds in the United Kingdom.Some key takeaways/thoughts from Andrew's point of view:Data Governance changes that are necessary for data mesh are both a threat and an opportunity. Are you throwing away the good with the bad? Or can you reinvent your practices broadly to do governance better in general and clean out bad habits/approaches when moving to a federated model?!Controversial! Of the four pillars of data mesh, governance is the most challenging and least mature.There are no roadmaps to doing federated governance for data mesh well - and likely there can't really be a specific roadmap for all as every organization is different. People are just starting to find their way on how to do governance in data mesh well and people will need to explore for their organization.?Controversial? Data mesh will likely require a seismic - or maybe tectonic - shift in the way we approach data governance. That doesn't mean organizations have to completely change it all at once - that is overly high risk - but it probably won't work if we just try small shifts to our governance approach instead of small steps leading to a large movement.Many organizations are already not doing data governance very well. So adding in the complexity of data mesh and finding entirely new ways of working when the current state isn't great? That is going to add additional challenges for many organizations on their data mesh journey.Try to build momentum around positive organizational changes for governance. And make sure people are bought in to the test, learn, iterate model or change is going to be much more difficult than it needs to be, data mesh or not.Data ownership: people generally don't really understand why data ownership is important. But often, it's hard to get domains to truly take ownership. And many don't understand what good data ownership means/entails. It's necessary to explain why they are the best owner and what owning data means.There's already a shortage of people who are actually data governance capable and that's likely to get worse as data mesh creates more demand. It remains to be seen if we need embedded governance professionals in each domain or if making existing people in the domain governance capable will work - basically, full time roles or capabilities/responsibilities as part of other roles, we don't know which will win.Existing data governance professionals will need to learn and adapt to keep pace in a data mesh world. Governance won't be exactly how it has been for years but there are lots of opportunities for governance capable people who also understand more technical aspects. You can teach the required tech aspects to willing governance people but they have to be willing.?Controversial? There has been a shift - sometimes a large shift - towards more technical aspects in many people's governance roles. But that is likely more of a pendulum swing instead of permanent shift to more tech than non-technical. Scott note: Focusing on the technical and not all the other aspects will result in VERY subpar value realization of your data. It's where data engineering often goes wrong.?Controversial? There is a misconception that the central data governance team goes away completely when everything is federated - data mesh or not. But that's more purely decentralized. The reality will be somewhere in between full central control and fully decentralized - and that balance, we still have to discover what works best.In physics, there is distribution of load. Instead of one central team doing all the heavy lifting, you distribute it out to far more people and they each have a smaller load to lift. The central team shifts to focusing on the coordination and bigger picture. Just because you've been lifting heavy as a central team and can do it doesn't mean you should!It's a valid and common strategy to not rush into data mesh. Many are testing and learning at a smaller scale rather than jumping in with both feet. They are testing, learning, iterating, and then reflecting. There isn't some arbitrary time table for doing the large scale changes like data mesh requires.Andrew started the conversation off with a potentially controversial - but probably often agreed with - statement: of the four pillars of data mesh, federated computational governance is the most challenging and is the least mature in ways of working/patterns. Organizations are starting to learn and make their way forward but it's still a major challenge. Be prepared to explore and find the right path for you and your organization.According to Andrew, most organizations are already not doing that well with data governance in the traditional sense so trying to figure out how to do it in a federated approach will be tough. And in data mesh, the computational aspect of federated computational governance means things are automatically applied where appropriate. That's very hard to do when you know exactly what needs to be done so it will be doubly hard in data mesh where we are still figuring it out. But changing your data governance approach can be an opportunity, not just a threat to existing status quo. How can we leverage the change we are doing to governance to be better than we ever were before? Far easier said than done but it's not only challenges.To do data governance right in data mesh, Andrew believes it is more likely to require a major shift to generally how the industry approaches data governance; organizations will need to make big changes - over time - rather than just a few tweaks to better align with data mesh. But, it is very early days and that all remains to be seen, just a prediction. Scott note: I strongly agree with this belief. I think people are looking for ways to not invest effort in aspects of data mesh but I think many have noted the automated/scalable governance work pays significant dividends as your implementation goes wider.But, Andrew wanted to stress that while we need major shifts, it's almost more like tectonic shifts than seismic shifts which often result the volcanic eruptions and earthquakes. Large but not moving quite as quickly - the big bang change approach to governance is overly risky. Why put all your eggs in one basket rather than try incremental improvements? Data mesh is all about trying, getting feedback, and iterating to improvement and governance shouldn't be any different. Build up the momentum around your changes and work with people to communicate where you are headed and why.When discussing evolution of data governance and sort of traditional data governance roles and people that have been working in governance for a long time versus new people moving into the space, Andrew believes it is crucial for those doing the traditional type of data governance to grow and adapt their skills, especially technically. Will roles require additional responsibilities? Will domains have embedded data governance-focused people as their main role? Or will most of data governance at the domain level be split to responsibilities handled by roles not exclusively focused on governance? He doesn't expect widespread redundancies but do prepare for some changes. That said, it can be very much of a pendulum action instead of a shift that stays - so potentially look for an overly technical focus for a year or two before it settles into a better equilibrium."Turkeys voting for Christmas" is a phrase Andrew used relative to perception of the work many governance teams are doing in data mesh. Essentially, if turkey is a traditional Christmas dinner, are these governance teams that are helping lead the work to federate governance eliminating their own roles? He doesn't believe so and Scott STRONGLY does not believe so. Look at federated government - it isn't fully decentralized, that is just silos. Data silos are bad. So you need central coordination points and planners. Where the balance falls for governance responsibilities remains to be seen.Historically, the central governance team has been doing all the heavy lifting because they are the ones trained to do so according to Andrew. But if we use a fishing analogy, we can see why central teams are happy to participate - if we have to fish and provide food for everyone in the organization, that's a LOT of fish you need to bring in. Instead, give them rods, teach them to fish. You can still focus on the big value fish - e.g. going and catching a swordfish or a tuna - but by breaking the work load down into manageable chunks, everyone can move faster and focus on creating more value where they have the best context. The less coordination we need across teams, the less unnecessary friction there is.Other quick tidbits:Most understand why data ownership is crucial. But many domains are not willing - or not capable - to take real ownership of data immediately. So gradual capability building and ownership handover is probably necessary.The role of data governance professionals in data mesh is still in flux. Will there be embedded roles in domains or will it merely be skillsets as part of broader roles? Either way, there is likely to be a significant shortage of highly capable data governance people while the need for those people is greater in data mesh than traditional approaches.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.Vlad's LinkedIn: https://www.linkedin.com/in/vladikk/Vlad's book Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy: https://www.oreilly.com/library/view/learning-domain-driven-design/9781098100124/Before we jump in, the phrase DDD is used a LOT in this episode. It stands for Domain Driven Design. We've had past episodes on it but I want to make that clear. It's also important to note, there are some very specific terms used in DDD and it is easy to get overwhelmed. Look for the meaning and ignore the terms - we are designing how things work together, whether business capability, software systems, or general data flows.There's also the importance of the difference between published language and ubiquitous language in DDD. Essentially, the ubiquitous language is the language of the domain and the published language is the language used to share information from the domain externally to other domains. So ubiquitous is internal facing between the business and software engineers in the domain and the published language is external facing to the rest of the organization.In this episode, Scott interviewed Vlad Khononov, Author of Learning Domain Driven Design (DDD) through O'Reilly, Senior Cloud Architect at DoIT International, and independent consultant on DDD and distributed systems.Some key takeaways/thoughts from Vlad's point of view:DDD is a big topic to learn - you don't have to learn every aspect to take good value from it.Make the implicit explicit. The more something is explicit, the easier it is to manage and manage people's understanding of it.It's important that the published language doesn't change as often as the underlying implementation model within the domain. But we also absolutely need to be able to evolve our published language. In data historically, we have trained consumers to believe we won't evolve the published language and have tied that too closely to the implementation model.?Controversial?: The concept of a domain in data mesh is very different from in Domain Driven Design (DDD). In DDD, you can really only identify business boundaries but in data mesh (or DDD for data), you can actually have an impact on - and potentially change - those boundaries.Iteration is a key aspect of DDD. It's not about getting it perfect, it's about getting to okay fast and improving. Learning to do that in data will be tough but important.It's crucial to understand the difference between the ubiquitous language - the language of the domain used inside the domain - and the published language - the language/interfaces used to communicate across domain boundaries. In data mesh, data products should be in the published language to make them useful outside of the domain.DDD helps you to learn more about the business domain and provides patterns to help design software systems. But it's 'biggest benefit' is that it provides a bridge between the business needs of the domain and the software systems.The reason organizations exist is not to ship software. They exist to execute on a goal - typically driving shareholder value - and software is merely a vehicle to that. Think about data the same way.A key aspect of domain driven design is communication across boundaries, whether machine or human to human. So finding and defining those boundaries becomes key to prevent - or at least manage - business friction.In DDD, it's important to not mix up domains and business capabilities. Domains are about finding coherent sets of use cases for software systems. Business capabilities is the hierarchical structure many think of when speaking about domains.A model is a cornerstone concept in DDD - it's how we look to solve a problem in software rather than try to reflect the real world in software. It's crucial in DDD to get the software engineers to speak in the language of the domain - the 'ubiquitous language' - in order to design systems to appropriately solve the business problem. In data mesh, we need to learn to embed the business context in the data we share in a similar approach of finding a language of the domain but balance that with the published language.In DDD, it's okay to have one implementation shared via multiple published languages, especially as different versions when the implementation model changes. We have to figure out how that versioning works with data, especially when the change is outside the hands of the producing domain - e.g. purchasing external data sets that then change.In DDD, it's okay to have more specific integration contracts for implementations for the job at hand instead of one "jack of all trades" integration contract. In data, this could be multiple views of the same general information instead of a single data model to share all aspects.To get to a good published language in DDD, ask the people consuming from your domain, the counterparty in your integration contract. It makes sense in data mesh too to ask people what they want. Take that feedback and look for general purpose ways of structuring and sharing data but you have partners, you don't have to design everything yourself.The anti-corruption layer in DDD is important - it is created by someone consuming from other domains and is a protection against ineffective models - specifically something that would contradict their internal model. In data mesh, this is made all the more important if we don't have shared taxonomies.Pain isn't necessarily bad. In our bodies, it's a signal something is wrong. In software, friction/pain signals are often ignored but shouldn't be. In data, we need to get WAY more explicit about when pain comes up and where it's actually coming from.Vlad started off with a simple Domain Driven Design (DDD) definition: "Software design should be a function of the system's business domain." But it once took him writing a 90 page book to really unpack what that meant. Domain driven design feels simple until you start to really dive deep and you realize 5m meant five miles, not five meters.So why do we care about DDD? Per Vlad, DDD helps you learn more about your business domain, identify its requirements and strategic needs, and identify what makes a software system you are developing valuable. DDD also provides a set of design patterns and architectural styles to design your software solutions. Putting those two together, it bridges the divide between the business requirements and the actual design of the software solutions so your software solutions are designed to explicitly meet the direct needs of the business rather than through layers of abstractions and miscommunication. For Vlad, the term domain is very complicated because it means a very specific thing in domain driven design but is often used interchangeably to mean what DDD would potentially call a subdomain but probably more correctly a bounded context. As an example, in episode 133, Ammara Gafoor mentioned her client has 21 domains across 100K+ people but in episode 130 with JGP, he used 'domain' to mean a team of 3-6 people. So getting specific around what the term domain actually means is important. In DDD, it's also important to note that subdomains will not cover all aspects of a domain because certain parts do not have software systems covering them. A key aspect of DDD is finding your boundaries between the subdomains which are essentially sets of interrelated use cases.A business capabilities model is actually what most people are thinking of when discussing DDD subdomains according to Vlad. He noted in an email "The business capabilities model is a more precise way to map a business domain than DDD's subdomains. It gives much more insight, though usually the subdomains model provides just enough insight needed for designing software systems." This is where you can have a hierarchy so Marketing may be a tier 1 business capability and that might be broken down into Digital Marketing versus Brand Marketing versus etc. And then Digital Marketing might be broken into Lead Generation and Demand Generation. Or by Paid versus Organic. Or many other ways. So, DDD is again about finding the boundaries between your use cases or a coherent set of use cases that work together. Those boundaries are used to drive the software system design decisions, how things work together, what architecture to use, etc.Vlad believes the concept of a domain in software is very different from the domain in data mesh. Essentially, when attempting to do DDD for data, we misuse the term domain to mean line of business or business domain. In DDD, the boundaries that the team can decide on is how the software components work together across boundaries but they cannot really change the business capability boundaries or the subdomain boundaries. But in data, you have the ability to actually change the business capability boundaries and how things are grouped into bounded contexts, to impact the flows instead of simply identifying them.We can't really reflect the real world perfectly in software - or even all that closely - according to Vlad. So instead, DDD uses the concept of a model, where the model is designed to solve a problem. The model should contain the minimum knowledge to solve that business problem - this significantly limits scope, which means preventing needless complexity.A key aspect of DDD - which translates extremely well to DDD for data / data mesh - is finding the ubiquitous language. You must get to a level of communication where the software engineers can understand the domain well enough to speak in the language of the domain to the subject matter experts (SMEs) - typically referred to simply as 'the business'. Scott note: In data mesh, data product developers will need to speak in the ubiquitous language of the domain to understand how to share the domain's context with the rest of the organization. It remains to be seen how much data products should be specifically in the language of the domain versus the language of the broader organization AKA the published language in DDD.Vlad discussed how important iteration is in DDD - it's not about getting it perfect the first time, it's about getting something out there and improving upon it as you learn more and as the world and domains/subdomains evolve. This applies well in data mesh because iteration and open sharing are crucial to getting to a data driven culture. However, in DDD, evolution of models creates friction. The way the systems were integrated is now changing so that is why there is a published language - essentially the integration language for how domains/subdomains communicate across boundaries. This is decoupled from the business systems so the business systems within the domain can evolve without it impacting how others interact with the domain. In data, the data warehouse has typically been quite tightly coupled so changes are extremely painful or in the case of the data lake, it is often raw data with no real published language or version controlling. This is a big friction point data mesh aims to address but exactly how companies address it will be varied and we are still figuring it out as a collective industry.In DDD, Vlad doesn't like the concept of a single integration contract for all purposes - this is that mythical unicorn type approach where it's good enough for every scenario. Instead, he recommends communicating with the other party in your integration contract to find what works for them. It means less work for the producer and the consumer 1) has a say so more buy-in and 2) gets what they want. Of course, this can mean more overhead so look to balance that. For data mesh, it remains to be seen if this will create too much overhead - a big issue in data is overly specifically engineered solutions leading to little reuse so we must balance usability for your key consumers with usability by all while considering overhead.Vlad then went into some of the patterns for actually sharing information in DDD if you'd like to dig deeper.An anti-corruption layer in DDD provides protection for domains consuming information from potentially ineffective models to your use case according to Vlad. That doesn't mean the integration contracts themselves are ineffective but it might mean that some terminology difference - we always use the example of what does customer mean - that would invalidate some of the work you are doing because it contradicts your own internal model/use case. It's crucial to understand how to implement these protections for data consumers but in data mesh, data consumers should also make sure producers understand when things are ineffective or counter to their internal model. It doesn't mean things will necessarily change but it makes the friction point public/explicit, resulting in better understanding at the least. For Vlad, pain in software can be good. It helps us to at least identify where there is friction and try to address it. But many teams try to ignore pain in software. It's a signal your boundaries are ineffective. That can be simply because things have changed and they were effective before, not a sign you had it wrong. But being on the lookout for where change will be effective and value-add is crucial to doing DDD right.It's important to keep an eye on what we are sharing by thinking about what could be more effective as well in DDD according to Vlad. As we learn more about a domain, or as the real world changes, we can share better information. So change can be a value-add. We obviously want to balance that with constant change but if you can more effectively share information, do it. We have written language now, we didn't 15K years ago. So we are far better at sharing information. When you develop a better way, look to implement it.Vlad finished by saying it's okay to dip your toe in the water relative to DDD. You don't have to learn everything and have an all or nothing approach. You can take parts of it and slowly adapt your ways of working. Important for data mesh too - you can take pieces and it's not going to be perfect, just keep making progress and don't delude yourself of the work yet to be done.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.Alexa's LinkedIn: https://www.linkedin.com/in/alexandrawestlake/Alexa's Medium: https://medium.com/@westlakealexaIn this episode, Scott interviewed Alexa Westlake, Senior Data Analyst at Okta. To be clear though, she was only representing her own views.Some key takeaways/thoughts from Alexa's point of view:Data can be transformational but it is expensive to do the work. "Without literacy, all your analytics is is expensive." So do the data literacy work to make your data work actually valuable.?Controversial?: Don't focus your transformation initiatives around a negative, focus on a goal/aspiration. It is hard to maintain momentum around pain, especially as it starts to ease with early wins. While pain points can pique attention, shared goals and collective outcomes will keep people bought in and motivated.?Controversial?: Data is "not going to make or break you [in every case], it is there to help you be better, it is there to help you unlock your full potential." Use it to sharpen your competitive advantage.As you scale your organization, if you do not prioritize data - the way you manage the people, processes, and tech around data - you will generate a ton of friction. It will create a "feedback loop of pain.""Never jump and hope." You need to make sure you have the support to get your initiatives going and then maintain momentum.!Important!: Data work is often not the number one priority for the stakeholders you serve. Understand that and keep close enough to make sure you are working on analytics to support their top priorities.Alignment is one of the hardest things to do organizationally and is far more crucial in data work than most believe. Be prepared to repeat yourself - repeatedly.The sunk cost fallacy very often results in throwing good money after bad in data, especially platform work. Look for signs you need to shift when the investment rises and the return continues to fall.People, especially in analytics related initiatives, often don't know exactly 'where the pain is coming from'. Work with them to understand their pain but that the data team and/or data work is not some magic wand that is waved and it's all better. It's tough but valuable work.It can be hard to get executive sponsorship to generate new data explicitly for analytics, but not doing that results in only analyzing the information you already have. How can we incorporate information capture into part of the business processes? What data is valuable - and reasonable/ethical - to generate?Get more specific when talking about data quality. "The data is bad" is essentially meaningless. Really drive towards specifics and then get people on the same page on measurement/monitoring of quality.It's easy to focus on the data you have instead of the insights you can generate. When talking to business stakeholders, how often do they care about the data versus what it means? Focus on communicating in what matters, not the speeds and feeds aspects of data.A lot of data tech debt / challenges in data come from decision makers not understanding their internal data ecosystems. Adding urgency to that often results in band-aid solutions that degrade quickly.You can't turn the ship too quickly. Trying to bet all your data transformation on one aspect or a big bang won't work. Look for small wins to build momentum.It's pretty easy to burn out your data team - make sure to give them interesting, important, and valued work.Communicate with the business about what matters. As a data person, that usually means more listening than speaking so you can figure out what matters to them. Applicable Scott phrase (to vendors): no one cares what you want to tell them, they care about what they want to hear about.When asking people generally what do they think of data, Alexa has seen many fall into one of two camps: either data is transformational or data is expensive. And in truth, both are probably right. There is massive investment in data but most organizations are still struggling to scale."The data is bad" is such a common refrain across the industry but Alexa believes that is like data without context - essentially meaningless. What aspect is bad? What makes it bad versus good? Why is it bad? Do we need better collection processes in place? Do we need more expertise in transforming and analyzing data? And when answering those questions, it's often very difficult to figure out what are the overarching problems that you can tackle instead of building point solutions.Alexa has seen it can be a bit of a scary proposition to try to get exec sponsorship to generate new data specifically for the purpose of analytics. So most companies start with what data they have today, and don't get overly ambitious, at least until they are proving they can deal with what they have now well. But, at the same time, many fall victim to the sunk cost fallacy of 'we've spent a bunch on this platform already, we have to focus on scaling it out', often throwing good money after bad. You can't just constantly change your platform but ignoring problems simply because the decision was already made is a recipe for disaster.According to Alexa, a lot of the challenges in data come from the decision makers not really understanding their internal data ecosystems so we need to make it easier for execs to make better decisions. That ML model might have 40+ pipelines in some form or fashion that feed into it, of course it's likely to degrade. And there is often an urgency to solve the problem of today with a solution that addresses that challenge today for that specific use case - fighting the symptoms instead of tackling the cause of issues.While something like data mesh - or any other large scale data transformation initiative - is a big change, Alexa believes we shouldn't make that a giant leap instead of small steps. You have to get to small wins as you're turning the ship to keep earning the right to steer the ship. And you shouldn't revolve the entire transformation around a negative, a pain point. If you do, you'll end up focusing on the pain too much instead of the goal - it's hard to sustain focus and drive around pain. Look to focus on the motivation behind why you are doing data transformation work but also what are the incremental results.A few ways to burnout your data team Alexa mentioned: not providing them work they feel is meaningful; putting low priority on data work in general but especially on the interesting insight generation; data not being part of the critical path to business success. Essentially, if people aren't working on interesting, important, and valued work, they will leave.Alexa believes it's crucial to focus on your communication when working with the business - they aren't well versed in data terminology or often even data concepts. So focus on communicating to them what matters and why instead of using data jargon. Most decision makers make so many decisions across many contexts, work to make it as easy as possible for them."Never jump and hope," Alexa said about measuring and maintaining momentum. To do data work right, you can't be an order-taker - taking the requirements, going away to build, and then presenting the 'thing' at the end and it's done. Get closer to the decision makers, understand what their expectations and needs are. Are they shifting? Are they expecting too much? Have the constant flow of information bi-directionally to make sure you are still doing valuable - and valued! - work.There is often a lot of pain around data for business stakeholders but they typically can't directly identify the exact source of the pain in Alexa's experience. Collaborate with them to figure out the actual pain so you aren't treating symptoms. And work with them to explain that just like in medicine, exercise, diet, etc., there isn't a miracle cure or improvement. Data work takes time. Explain why it will take time and drive to what actually matters to address. The common example is 'what does real-time mean for you and what value does real-time drive?' It's often '2 hours is fine, just sick of 24 hour delay.'For Alexa, it's very easy to try to build out governance centrally because it maintains a feeling - if not a reality - of control. The reaction of most humans to the unknown is fear. But you can make slow improvements to build trust and momentum - as Laura Madsen also talked about in her episode. If you don't invest the time to empower and enable your employees around data, you won't get good returns from it.To do any data work, but especially something like data mesh, right you need champions in the domains to help. Both to help you move things forward but also that constant communication loop as the world - and thus requirements - changes. Focus on them being your partner and treating them like a customer of your product.It's very easy to fall into the trap of putting too much emphasis on the data work, according to Alexa. It is not likely to make or break your organization but it can be a significant competitive advantage. Data can unlock your value potential and sharpen your competitive advantage.Quick tidbits:"Without literacy, all your analytics is is expensive."Alignment is one of the hardest things to do organizationally and is far more crucial in data work than most believe. Be prepared to repeat yourself over and over.It's easy - and often fun - for data people to focus on the raw data you have instead of the insights you can generate. When talking to business stakeholders, how often do they care about the data itself versus what it means? Focus on communicating in what matters, not the speeds and feeds aspects of data.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/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.What tech is already available that could be used for data mesh? There are so many amazing approaches and technologies in data but they've been used for the pipeline approach only. We need to think more like developers - not accepting the grunt work or death by a thousand cuts of data - and take a hard look at what we've done historically in data and what should be replaced.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