#138 Getting Started with Data Mesh by Collaborating with the Business - Interview w/ Darshana Thakker

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

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

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

Episode list and links to all available episode transcripts here.

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

Transcript for this episode (link) provided by Starburst. See their Data Mesh Summit recordings here and their great data mesh resource center here. 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:

1. 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.
2. Speaking data jargon when talking to the business stakeholders makes it hard to actually communicate. Focus on speaking to business outcomes and business value.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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?
8. 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.
9. 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.
10. 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.
11. 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?
12. 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 here

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