Beyond Theory: Data Mesh in Action

Video Synopsis

• Lessons Learned From Implementing Data Mesh
• Data Mesh vs. Data Products
• Working With Customers Implementing Data Mesh
• Working With Other Platforms
• Identifying Facts
• Advising Where to Start

Transcript

Note: This transcript was created using speech recognition software. While it has been reviewed by human transcribers, it may contain errors.

Nik Acheson:

All right. And then we also obviously have with us Zhamak and Paolo. So thank you for coming. Super excited and actually humbled to be not just facilitating the conversation, but even sitting here with you, going back and I know even Zhamak, it’s been a few years even since your book came out. And the one thing I incessantly even hear from our customers is, hey, what’s happened, right? Why don’t I take that book and put it into practice? And Paolo, you and I talked for a couple hours at Big Data London even a few months ago and really talking about the journey that you’ve been on with a number of customers as well. So I’ll let obviously both of you do your intro. So you want to start Paolo, yourself?

Paolo Platter:

Yeah, sure. I’m Paolo Platter, CTO and co-founder of Agile Lab. I spent my entire career in data management, supporting large enterprise. And now since three years, I’m driving the creation of WitBooster, that is a data experience platform that help you to cross the standardize and enforce practices like data mesh in large organizations.

Nik Acheson:

Zhamak?

Zhamak Dehghani:

Hi, everyone. I’m Zhamak, the CEO founder of NextData. As of now, we’re working on a platform for containerizing and orchestrating this concept of data product that was introduced by data mesh. Prior to that, I’m known for creating the concepts of data mesh. And I’ve been in the tech industry for 20 something years, playing a variety of roles from a programmer to an architect, and now here, a founder.

Lessons Learned From Implementing Data Mesh

Nik Acheson:

Awesome. And I think all of us really love an extemporaneous orientation. So I would even say if there’s things that pop up in the comments, Zhamak or Paolo, if you want to pull those even forward, if you want to frankly even interrupt and dive deeper into some of these topics, let’s do it. So don’t feel like I’m just driving. We can all do it together. So I’d say let’s start right off. As I mentioned, Zhamak, it’s been a few years since your book. We talk about data mesh in practice. I’m curious, from your perspective, there’s been a lot of implementations. I’ve been on the other side with successes, failures, and even back to successes again. And I think in practice, what have you learned? And obviously, I know both of you start your own company, but where do you also see, frankly, gaps in that ecosystem? And what are you excited about as you’re seeing emerge?

Zhamak Dehghani:

Sure. I think the most evident learning, at least for me, it’s been that the challenges that data mesh brought to surface resonated widely with the industry, regardless of what buzzword we use and what is trendy to use today’s data mesh or data fabric or whatever it is. I think the fact that the traditional operating model of data management for AI and analytics had really reached their limits. And that traditional, we can talk about what that traditional operating model is, but essentially, pipelining data into centralized compute storage and then layer it with some access so that we can use it. That kind of pipeline centralized model is not something people ask for. So I think the learning has been there’s been immense amounts of interest in an approach that is more decentrally oriented. It’s oriented around distribution of data ownership in organization in step with how organizations grow and how organizations are, frankly, structured. So I think that is kind of something that is evident. There’s a lot of talk around if organizations are doing it, right? So we have learned, at least in my experience, from large organizations like Department of Defense of U.S., one of the largest enterprises in the world, to, you know, HelloFresh or maybe scale ups where they have that problem of complexity. 

I think the second thing I’ve learned is that once there is a acute problem stated, people rush to solve it, right? You have to, as problem solvers, we have to rush to find a solution for it. And in that rush, you always go through this kind of hockey stick of things get worse to solve that problem before they get better. And in that phase of maybe things getting worse, we had to use technology that was available to us or technology that was already available and maybe had some incremental data machine improvements to kind of bring that idea to life. And in that process, what I’ve learned is that a lot of data machine implementations weren’t materially changing the way people were working. They weren’t materially having an impact on this distributed ownership of the data. There were mostly an incremental improvement within, for example, within the data team. You know, you have now a data catalog that people can subscribe their data, whatever quality or however it’s produced into it. So we’ve seen, I guess, some linear movements toward data mesh, but still fundamentally in the same pipeline, store, search, discover kind of operating model. And that makes people slightly disillusioned about, is this real? Can I really do it? Like, where is the gap with the technology? And I think that’s a good segue to talk about like where the gaps are. And I think to me, the gaps are not in the last mile of that operating model, but in the first mile. I mean, we need a new way of, you know, new technology that creates a new operating model for data sharing and data management. I think whatever gap finds that is going to make a big impact, right? That we don’t just try to inject data mesh into an existing operating model, into an existing catalog or an existing warehouse or an existing ETL tool, as opposed to saying, can we create a new experience with new technology that can fundamentally shift the operating model to have that peer to peer meshy kind of experience? I think that’s, for me, that’s the biggest gap. And that’s where that’s only possible, that catalyst is only possible to be impactful if it fundamentally helps, you know, data practitioners of many shapes or form within the domains of business to be able to participate responsibly in data sharing. And that’s a tall order, taking people from where they are today to become part of that data ecosystem. Anyway, that was a lot of words, but hopefully I…

Nik Acheson:

No, I think that’s, maybe I’ll have you go next then, Paolo, obviously, because you’re also creating a platform yourself, right? And kind of been through that, the multi phases of even those implementations with other enterprises. I’m curious, especially as you’ve been doing those implementations where you’ve seen some of those gaps where, obviously not even as you’re massively maturing your platform every week whenever we talk about it, but I’m curious, what have you learned? And then even on the other side is where do you really see that there needs to be another, you know, maturity path within that ecosystem?

Paolo Platter:

Yeah, I think we went through different phases. I’ve been in the data mesh story since early 2020. So at the beginning, I have seen early adopters jumping into it and trying to solve very, very fast the problems that, as Damak said, were arising by this decentralization of the paradigm. And they were jumping in just because of their intuition that they can get some benefit out of this pattern, not because there was some proof at that time. And those people really hit against a lot of walls and created a lot of awareness in the ecosystem. Then I think two years ago, there has been a period where there were a lot of skeptical people that were undermining the concept, even without trying to understand and trying to implement it. And a lot of other companies that were jumping into the data mesh, but completely destroying the concept and trying to adapt to their need and so on. And this created a lot of confusion. So I think undermined a lot the possible benefits coming out from the data mesh concept. 

I think now, I just came out from the Data Innovation Summit, is one of the largest conference in Europe regarding data management. And I have seen a lot of improvement in the understanding, in the awareness of companies, also in being realistic of what they can get out from the data mesh implementation, which are the benefits and so on. So I think it is now getting traction in the proper way. So with adopters that are really interested in the benefits of decentralization and are not anymore interested in just jumping in the story to do some marketing and so on. So I think we are in a far away better position than a couple of years ago. There has been also a huge effort by the community to establish proper principles and values with a lot of podcasts around tables. So it has been amazing. 

What I see for the future, I see two main things. From a practical standpoint, from a practical implementation standpoint, I think we still need to close some gap, for example, in data modeling and how do we model the data within data products? How do we connect the data coming from different business domains? There are a lot of theories and thinking about that is still not clear to many people. So we need to evangelize more about this. And the other aspect that I’m seeing is the rising of awareness in terms of what this data experience plane is. At the beginning, I’ve seen a lot of companies jumping in into creating a self-service platform that was just a bunch of infrastructure as code and CI/CD, but this is not the real meaning to me of a data experience platform. We really need to reduce the cognitive load. If we want to shift the responsibilities into the domains, we don’t want to add more complexity with configuration file infrastructure and as code, the Terraform, whatever. We really need to change and elevate the game that we want to propose to the business domain if we want to have a better adoption of data mesh within the organization. Otherwise, we are shifting responsibility, we are adding complexity, and this is not going to fly.

Data Mesh vs. Data Products

Nik Acheson:

Yeah, so I’ve done a data mesh and fabric. We’re not going to debate those today. I’ve done a couple implementations in my career, and one of the biggest things that even when I’m out with our customers helping design what their transitionary architecture looks like with some of these principles, the one space that folks continue to end up hitting later that we try to plan for, but frankly, I don’t see that the market technology-wise has caught up yet, which is definitely around that contracts part, really understanding what it looks like of the lifecycle of some of these data products, even differentiating obviously between enterprise products are obviously different than data products that people are generally — you treat each of those differently, right, and there’s a — and how you think about the maturity of those assets over time and how the consumption of that and whether it’s data drift, right, or model drift or schema drift and metadata drift and how all those things continue to mature over time. This is where I was really excited having, you know, Chad here speaking yesterday, and I know he’s writing the book right now on data contracts, and I see that getting a lot of momentum, but I still haven’t seen the community really rally around a clear solution for that yet. And I think the last one, too, is the — really, if you continue to think about not just governance in the enterprise, but as you’re even thinking about those extensibility of those entitlements outside, as we even see data products even being shared in other external organizations and how those get connected in. So those are ones I’m — if anybody has seen those, please throw them in the comments, because I would definitely love to check them out, but — Zhamak, are you going to add something?

Zhamak Dehghani:

Yeah, I think the problem, frankly, is more basic than that. I think one of the foundational concepts within data mesh was this kind of autonomous unit that would enable exchange of value, enable exchange of reliable, trustworthy data, will enable contracts, will enable traceability, and that concept was, you know, termed data product. But that concept has been taken, and because there hasn’t been any reference implementation of that, that we rallied around and said, “This is what it means,” and intentionally I left it with — you know, I defined it as a set of, like, eight characteristics, like, called them dApp units for short, and it’s in the book, but it’s, you know, it’s something that is discoverable, it’s something that is lively, it’s something that, you know, it encompasses all of the pieces that you need, such as your contracts and policies, and the runtime of the compute of data production, like, there’s a lot goes to define and bring that data product to life, and I think as an industry, we don’t have a reference implementation that then in itself can unleash innovation through coalition. 

Everybody has their own interpretation, like, even around the three of us, if we ask, “What is it?” We probably have three different — like, what does it actually look like? We’ll have three different definitions, you know, some people call views with metadata data products, some people call files data products, I call an application a data product, right? So there is different views on it, and I think, to me, that’s the catalyst, when I say there’s a catalyst missing for unlocking innovation and moving fast and materially make an impact, to me, that’s that. And until that comes to exist, we’re going to be, like, you know, jamming in contracts where? On top of what? So it’s just we don’t have places to attach these missing capabilities that you’re mentioning, like policy as code and governance and security. Where do we hang off these things? We don’t have that catalyst. So for me, that’s the piece that’s missing, that takes a lot of energy of me and my team right now to at least build one version of it, right?

Working With Customers Implementing Data Mesh

Nik Acheson:

So I’m going to give one more question before I get the topics that I know we’ll all have differing opinions on, and hopefully we get a little spicy, but Paola, I’m going to give you the next one to start off. I know, I think, Zhamak, I actually stole your quote from one of your other talks of, like, overambitious marketing. And Paola, you mentioned that a second ago. I can’t tell you how many times I get into rooms where I have to start there of, sure, if everyone wants to go from the basic definitions of a data product and discoverable, right? Every platform in the world can say they do data products, right? So you normally have to educate and kind of walk back, talk about a couple reference implementations and things we’ve seen, but I know, Paola, you, I think, of anybody that I’ve met have been very more, like, straight and narrow of, like, no, these are the clear principles. Here’s how we’re building against and advising harder to that. So I’m curious, how do you consult when you go in with your customers, navigating those same kind of problems of, yeah, I got six other vendors saying that we can do data mesh with them, too. Oh, by the way, three of them are a catalog company. This is spicy.

Paolo Platter:

So, yeah, my answer is always stick to the principles. So every good theory or architecture has some principle, and I think data mesh is founded on very good four principles. So when it comes to understand if a tool can deliver a data mesh or whatever other practice, I always ask, okay, how this tool is supporting the four principles. Is this tool helping a data domain to take real ownership on the data, design the domain boundaries and design the data product boundaries and help them to take ownership along the full life cycle of a data product? 

Then the second question is, is this product helping a company to define a standard for a data as a product? How do we standardize the interface of a data product without introducing technology lock-in? Okay, because otherwise it’s not evolvable. And is this tool capable to introduce computational policies in every phase of the data product life cycle? So at build time, deploy time, and run time, at change management time? And finally, how this tool is creating an experience that is fully self-service and governed from an infrastructure and application level standpoint. So if you are not able to answer to these four questions, basically it’s not fully supporting the data mesh. Maybe, and it is like this. So all the tools, catalog and many other tools, are part of the picture. I think everyone can play a role within a data mesh architecture. That is, being part of an architecture is not meaning that you are supporting the practice that is sitting behind that.

Nik Acheson:

Yeah. Zhamak?

Zhamak Dehghani:

Oh, I 100% agree with what kind of policy. The first principle, like approach a problem, solving any problem from first principle, is a good place to start.

Nik Acheson:

Yeah. So normally when I get into there, I take a somewhat different approach. I definitely give kudos and homage to both of you, to be clear. And as I say, if you want to continue to look at what maturity and how the thought process is still evolving, I definitely continue to point back to understand the core principles. But the second part I usually do is actually then shift it. And I think this is where we can start getting a little fussy, is how does a pragmatic implementation actually look like? And don’t give me a technical answer. What are you actually trying to solve? Where’s the pain point? Doing a little bit of value stream mapping and value stream engineering to be able to go, right? Because you can’t bring in four or five platforms every year for most of these teams. We just don’t even have the capacity for it, let alone funding for most organizations. So it’s about driving a maturity path. And I think that’s what makes it a little easier to go, I’m not going to debate whether this catalog company does mesh or not. What problem are we actually solving? How do we get there intentionally? And then how do we make sure that you’re making the right tradeoffs architecturally that allows you to continue to mature on a data mesh path and journey? 

Working With Other Platforms

So I’m curious, again, as both of you creating platforms to solve this, when you think moving on the practical side and what a maturity path looks like, how are you navigating that with even your prospects or customers, knowing they have X amount of other platforms and, right? I never say legacy anymore. I’ve learned to say operational, right? So that you have to operate within those operational systems and ecosystems.

Zhamak Dehghani:

I can take that first. So I absolutely agree. And in fact, I did, you know, five years plus, five plus years of consulting data mesh before I had called it data mesh to get here and to get to the point that said, okay, there is fundamentally a missing piece of technology to enable that maturity curve or traveling that maturity curve. I do agree that any, Martin Fowler has this wonderful quote, if I don’t butcher it, that a big bank change or something along those lines, a big bank change only produces a big bank. So every change has to be iterative. I do agree with all of that, but there is a big ask from organizations from where they are to where they need to be to materialize the real value and the benefits of data mesh that would require them to invest, either build their own platform and technology or build and buy and integrate a combination of all for them to get there. I think it’s in fact damaging to go into an organization and say, oh, you, you know, you, you don’t need to think about tools or technology. And I know it’s a lot of conversations around data mesh as I termed it as socio-technical were around socio part of it because organization change and people are the hardest part of any problem, right? But for people to change behavior, they need to see value fast and technology changes behavior or technology that our behavior changing. 

So I think that technical part needs to be part of that conversation. And at this point in time, realistically for if we don’t have that technical and socio both conversations, we either rely on some technology that is not behavioral changing or it’s not shifting the organization or we’re relying on organizational change that is not going to go anywhere because you don’t have enabling tools. So balancing those two and be realistic about the investment that is needed and the change that is needed is a difficult one to communicate as I had a conversation actually just this week with another large government body here in U.S. and they were saying we are, you know, we’re composed of many other government sub-bodies and naturally changing data lend itself to data mesh. And at the end of that conversation when I said, well, you have to solve this tech layers of technology and invest in it or build it or however you get there, that’s a necessary part of it. You kind of see that reality really hit the people and say, okay, maybe we need a hybrid model. Maybe we don’t need actually a data mesh. Like it’s actually somewhat overwhelming what change needs to happen. But if you think about any platform, it has to operate within the existing paradigm and I think there is a way to get there. There is a way to create technology and enabling platforms, whatever we call it, you know, the data product experience playing like in the book or whatever we call it, I think there is a space for technology that helps the individual contributors and data product developers, data product consumers, you know, either homemade or bought, doesn’t matter, integrating existing technology that’s out there.

Nik Acheson:

Yeah. So Paolo, I’m interested because I think you and I talked about this for almost a whole hour on the Big Data London floor as you were navigating your first, you know, a lot of your enterprise implementations. I’m curious from those conversations we had last September to now, how are you navigating that and how are you advising?

Paolo Platter:

I have a similar view on this. My experience as a consultant say that technology change is never ending in the proper way, even if it’s never delivering on promises. So my approach is always to shape the data mesh on top of existing technologies. Especially if they can provide some kind of, let’s say, self-service capability, something that nowadays is totally common. But the idea is to help them to shape a practice on top of existing technology, shape behaviors. But as Zamak said, in order to change a paradigm, you need to provide some value in exchange. So you cannot just force this change providing guideline and documentation and stuff like this. So my approach is let’s create guardrails that are really guiding the users in doing the right thing since the beginning with the existing technologies, but being compliant with the governance rules that we all together shape in the organization. And it’s super important that these guardrails are really effective and following the users along the whole path and the whole lifecycle. 

Where is the value of these guardrails? Because anyway, if we act as just gatekeepers, it’s not going to fly. So we really need to enable business domain to take accountability of their data. So the value that we can provide back is to make their life easier in creating data product without cognitive load, making it easy, making it easy to be compliant with all the governance duties that they need to face, have self-service deployment, and many things that we can build on top of existing technology. And this is about shaping a practice. This practice can be the data mesh, but it could be also just the data contract that you were mentioning before is a practice as well. So for me, it’s all about enabling the adoption of practice in large organizations where it is really complex to drive a multitude of people just delivering guidelines and documentation and stuff like this. So to do this, you need to integrate with the technology, you need to pilot the technology, you need to automate the technology, but I never suggest to change technologies just for the sake of data mesh adoption or data contract and so on.

Identifying Facts

Nik Acheson:

So one of the challenges that I’ve had multiple places I’ve worked at, and I actually had a really good heated real-world conversation just yesterday with another large customer of ours. And what we were navigating around was the problem was establishing and understanding what facts are. So I even had that problem in my career was one company I worked at, if we just asked the questions, what was sales in North America yesterday, oh, the answer was different and had an asterisk for every single person you asked and there was no single fact. And if we even think about things of bounded context, that crossed at customer domain and product domain and our financials and our forecasts. So it really did have an asterisk everywhere. And that answer only was able to evolve, frankly, because of one person owning it. But a lot of our customers that we talk to and where I advise, they’re really worried about opening up the democratization of data and creating data products and going, well, how do I still assure that I don’t now have 30 definitions. 

Now I got heated with it because I was like, I guarantee you today there’s probably 40 and you only know about five. So there’s a spectrum level visibility opportunity that you can have in this ecosystem. I think that moves a little bit to where I think I sit into the data mesh ecosystem, which is trying to meet folks where they are in a pragmatic way of moving versus maybe moving and shifting a little bit harder and pushing. I think each one of us falls differently on that spectrum. So I’m curious, as you think about facts and helping companies kind of get from where they are today to moving towards and then managing those facts over time, is that something that you’ve continued to run into or how have you navigated that with your customers or prospects? Maybe, Paolo, if you want to go first this time because I think you’ve put on the complete other side of the spectrum as me on that one.

Paolo Platter:

Yeah. This is super, the bounded context stuff in data management is one of the most difficult to adopt because people is not, data people are not used to model events that are generated by business processes. So they are not used to think in terms of business processes. Data people model entities that are data coming from the business process execution. Instead, who is coming from the domain-driven design, adopting different techniques like event storming and so on, is quite used to take at the beginning of the project and your data mesh initiative, take the time to shape the boundaries of your domains. But more importantly of your data products, because if you start to model your data ecosystem in an entity relationship way, it will be super hard to shape the boundaries of this data. Okay. But it’s a totally different approach. You need to start back from understanding the business process that is going to generate events and then on top of these events and fact, you need to build your data products. And when I was saying that we have a big lack in data modeling right now, I was referring to this. So there is a huge disconnection between how we should model the data in a data mesh oriented approach to stick with the bounded context, to have clear ownership boundaries in the data domains with what people are used to. So star schema, snowflake, vault, whatever it is, but this is about modeling entities and not modeling the events generated by business processes. So I always suggest to take your time, analyze again, your business process and try to shape the bounded context of your data products and what you want to build in a domain driven design because otherwise it will be very hard to find a boundary for domain ownership.

Nik Acheson:

Zhamak?

Zhamak Dehghani:

I’m probably somewhere between Nick embracing chaos and give visibility, which is, I think that’s reality. We’ve got to embrace the chaos and build a system that is actually designed to bring equilibrium to chaotic systems, more in that camp than a structure. I wish we could work the way Paolo just described. People don’t have the time and patience and the world is very messy, but I would love to take actually the example that you just mentioned, like five different sales, end of the month sales results, and we don’t know even which one’s correct and why we have five different ones. If you look at the maybe one hypothesis is why we are arriving in that scenario is because we probably have different channels where the sales are coming through. You have your online sales and you have your outlet sales or different ways sales get in, and then you have different ad-hocly developed at different point in time, organic pipelines that are calculating based on their understanding of the sales or the pockets of sales. They know they’re calculating, perhaps even the calculations are different, or perhaps how the sales are being consolidated different. You have code and various sources of data arriving at different numbers for a different set of consumers because they probably build one dashboard for some executive and some other pipeline was developed for something else. 

I would say when we actually think about how we should now, as a technology provider for a minute, put the vendor hat on, how we should go from this brownfield mess of code and data sitting around to something that Paul is describing, a bit more designed and organized. I think for us, the processes and what we recommend is you’ve got to first bootstrap your mesh, cold bootstrap your mesh from the stuff you have. That’s the reality. That’s brownfield. Everybody’s dealing with brownfield data. To bootstrap your mesh, then there’s probably some automation and that’s implementation detail for us. You have to just give visibility to the things that you have and have people, people are always involved, have people to have ownership of the pieces that you just now discovered and bootstrapped as part of your mesh from existing assets, so then you end up giving visibility. Oh, it looks like we have two people on this side of the organization designing this sales data product, which is different from this other sales data product and then once you have that visibility, you can then say, okay, it looks like, and here I think really AI is to me, the exciting part of applying AI to data mesh is this area, discovery of the stuff that we have and we can’t make sense of it, but it’s harder for people to make sense of it. From there, then you can decide, okay, it looks like we only need one aggregate sales data product and these two other ones are redundant and this other one, we can combine and then that layer, that bounded context as a downstream or on top of, or in place of this stuff that you have. But no matter how well we try, how well we, whether to bootstrap and design after or design upfront, we end up back into that chaotic system, we will have three new sales data products. So I’m sorry, coughing, I have a cold. So I think we need to have a system, whatever system we provide to manage the mesh, it has to embrace that chaos and fundamentally it has to be able to discover and recover.

Advising Where to Start

Nik Acheson:

Yeah. So let’s, let’s pull on that thread a little bit and I’ll say like, let’s make it a little more real, right? So if we think about it in practice, one of the, one of the questions I normally get after I do a presentation is, well, where do I start? And I think this goes back to where I go, well, one, don’t start on the technology side of like, well, how do I fund this? Right. How do I bring this in? And normally I, I generally see a pattern on the initiative side that normally gets funded more than others. But then on the other side, it’s like, where’s also the pain. And I gave the example of the sales in North America yesterday or today, because that’s where we started in one company I was at. And it was very easy to fund because the K-10 can’t be wrong, right? And then the finance space, it’s easier to find a domain owner and create a stewardship program and talk about facts and the evolution of those facts, because again, the K-10 can’t be wrong, right? So I generally have always started there when I think tech forward, because it’s easier to go, especially if there’s been an event where some of our metrics were wrong at end of quarter, right? And then luckily in one case, the street didn’t catch it. 

But it’s about maturing then to say, how does this never happen again? And what principles can we put into place and allows now to apply the technology principles and the technologies to then say, okay, here’s how, here’s a better way to start approaching it. And then I say on the other side is the initiatives is customer 360 and supply chain are normally the two spaces, frankly, that always have funding, right? And thinking about how do you give a next best product recommendation or next best message, or I shouldn’t give a product recommendation if I don’t know what’s in my four walls and my supply chain, or I shouldn’t give a recommendation for a loan if a consumer wouldn’t even qualify for it. So I think that’s the space where it allows you to then continue to mature out and back to your point is you can then mature the data domains as well tied to that, whether you work out on initiative or you work back into organizational. It allows an easier path to align and then to the business outcomes tied to driving that new technology architecture. So I’ll say, Zhamak, if you want to start here, and then I think Paola, you can probably push me on everything I just said. How do you think about that? And where do you see some of those trends, whereas you’re going in saying, hey, here’s where I would start, or here’s where we see more companies start?

Zhamak Dehghani:

Yeah, that’s a really good point. And I can share my experience both as a consultant before Nix Data, and of course, as my current role as the kind of the technology provider side. I think a lot of initiatives I had seen before, where maybe they were part of that first generation of buzz around data mesh that Paola referred to, were initiatives that came from a platform team. They came from the centralized data team, as in they saw maybe an out from this dire situation of being responsible for all of organizations’ data, and under a lot of work pressure, and everybody feeding the data in, doesn’t care, everybody requesting data, putting pressure on them, and is unhappy. And they thought, OK, now this is a way out of this situation. But unfortunately, I see still a lot of initiatives that are part of a revamping transformation, call it data democratization. There’s like a global organizational-wide data democratization transformation is happening with the technology group having most of the budget or starting that. Unfortunately, bad news, from my experience, those initiatives are not the most successful ones, because as you just rightly said, they’re not directly connected or traced back to the burning business KPIs and the bottom line that the company and the business domains care about. And often, the partnership with the business domains is not built in early on. Sometimes it is built early on, and I think Roche is a great example of that, that particular business domain collaboration with maybe centralized property can kind of move fast and show that business value, and that business domain could be manufacturing. It really differs. It’s not all just customer product. I don’t see that pattern. Personally, I haven’t seen it. But I have definitely seen the anti-pattern of starting from centralized data team. In fact, as a company, we’re always very careful with those initiatives, even though they’re very mighty and very ambitious and exciting, the success rate is low to serve and to serve the domains. 

Nik Acheson:

Yeah. I always push to bring in a business partner every time I go in with a data team or a centralized team. So let’s pull somebody in and make it real. So I know we’re getting close on time, and I think we could probably talk for days on these topics. Paolo, I want to give you last word, too, if you want to add anything there as well, or feel free to push.

Paolo Platter:

Yeah. This is one of the hardest dilemma in data mesh. I think use case– so the success of a data mesh initiative depends on the adoption. So it’s all about adoption because it’s a platform business model. So you need to generate the network effect. It’s not possible to build a data product without having other data products in the mesh. So the idea is to take tactical actions to speed up the adoption, at least in the initial phases. I have seen some specific condition working very well, for example, in ESG, because right now ESG is a very hot topic. They have budget, and they require data from many other domains in a company. So this is a good opportunity, for example, to redistribute a bit of budget on other domains and help them to jump into the data mesh. So especially in the first phases of the data mesh implementation, you need to push a lot on adoption. And then I agree with Zhamak, anyway, you need to keep under control the depth that you are creating, starting from the brownfield and pushing on tactical actions, but you need to have some self-healing in your platform to keep the depth under control and be sure that everybody understands that we need to reenter this depth. Anyway, it’s very difficult to fund an entire data mesh initiative just relying on the budget of one, two, three use cases, because anyway, a data mesh initiative needs to create the platform, change the governance model, create a lot of automations, and so on. So it’s quite unrealistic to start a data mesh just relying on a couple of use cases. You need to find the right balance. And in some way, anyway, the data mesh itself must be funded for a certain percentage.

Nik Acheson:

Awesome. Well, I think we’re at time. Not only do I get excited about continuing these conversations in the future, but obviously we work pretty close together as companies as well with both of you. So I would say anyone out there looking to continue to learn about data mesh and, again, real-world implementations, dive into the details, obviously we’re always here to help. So thank you. Thank you. And thank you for joining.