Immuta CTO and Co-Founder Steve Touw sat down with Paul Rankin, Head of Data Management Platforms at Roche, and Sanjeev Mohan, Principal at SanjMo, for an in-depth discussion about data mesh architectures. Below is an edited transcript from a portion of their conversation. To listen to the full recording, click here.
Steve Touw: This is going to be pretty free flowing, open conversation. I’ll open it up to you guys. Why did data mesh become so popular? What is the current state, do you think?
Sanjeev Mohan: I can get us started on this. Interestingly, a little bit of background information for all of you – this question originally said, why is data mesh so popular? And Paul and I got together and said, well, it’s debatable. Is it really that popular, or not? So, we changed the question to why did it become so popular?
In my opinion, data mesh became so popular because we were battling with some really nasty issues as we were growing our user base for data. Since data became so critical for decision making, new use cases started coming up. We started running into a lot of bottlenecks where the time to value was really long.
So, three things that I think data mesh addresses so well and why it’s certainly erupted into the scene are:
- Agility – how quickly can we deliver value to the business?
- Trust – how do we build in the sense of accountability?
- And innovation – how quickly can we react to new business needs?
Before I talk about the current state, actually, I’m gonna stop here because I want to hear Paul’s take on it since he is actually in the driver’s seat building out a data mesh.
Paul Rankin: Thanks, Sanjeev. The journey for Roche probably started about three years ago. We went through a digital transformation, and part of it was clearly trying to move our data and analytics functions and our capabilities more towards this modern data stack, cloud-first journey.
My previous boss is also an expert in the field. He noticed that even just by moving everything to the cloud – so moving our warehouses, our data lakes, et cetera to the cloud – was actually not really going to help Roche accelerate into the digital world. Yes, it may give us a little bit more unlimited storage and maybe faster compute, but certainly it’s not going to solve a lot of problems that we were facing at that time in Roche – slow release cycles, bottlenecks, centralized monolithic teams that were very highly governed and quite disconnected to the actual data and the use cases on the ground.
He wanted to do something a little bit different, something that was a new take on delivering data analytics because Roche was a very decentralized organization when it came to analytics. You had lots of sections within the business which were traditionally known as the shadow IT organizations, but these were the guys that were actually doing really good work. They were delivering data insights very quickly because they knew exactly what the data was, what they needed from the data.
[My boss] was very conscious of that when we moved to this data mesh approach at Roche. I think this is why it was quite attractive to us, because we saw that it fit better to our culture. We were trying at Roche to force a very central monolithic analytics culture on a very decentralized company. And I think that it was quite attractive that we could now see that if we empower those these functions, these domains, if we really decentralize, if we empower in those domains to be accountable for their own data, for their own pipelines, for their own governance, in some way this whole different mindset and way of thinking is maybe the way forward for Roche. I think this is why it became so popular, not just in Roche, but for other companies as well.
SM: Yes, Paul, one thing I have found really interesting that he did was give a very human twist to this whole, if I may say, very academic concept – the four principles of data mesh. If I remember correctly, he renamed the four principles into heart, body, mind, and soul.
PR: Yeah. Correct.
SM: And that was actually a very smart way of connecting a very technical, theoretical concept into something that you could communicate easily. I know he did that within the industry and we all received it well, but did he do that within the organization to the management? Because to me, mindset and culture are so important for data mesh. I suppose extracting the technical complexities away and offering a little bit of a human touch is going to help.
PR: You’re trying to get the business to make such a drastic change – and let’s make no bones about it, this is a huge change in culture and ways of working. They say it’s socio-technical, but to me, it’s all social now. I mean, the technical part of it really is, when you get into it, very small.
We can fix the technical part fairly easily, compared to changing the mindset of an organization. What we’re asking is for everyone to have this product thinking mindset. And this is really difficult because people just don’t understand what it means. They’ve been used to just owning and delivering their little bit of data for their own department to reuse.
But now they have to have this enterprise product mindset where they publish their data, people are going to use it, and they need to make sure that it’s got all these trust metrics. They’ve got freshness metrics, completeness metrics attached to it, and they need to put a service on it. Really getting people to change this way is absolutely the most difficult thing.
SM: I’ve said this previously, and I’d say it again – technology is easy. Processes are hard. People are impossible.
ST: I agree. I’m wondering – the question being why did data mesh become so popular – do you think it’s related to the social part or the technical part? My personal feeling is that people get enamored with the technical part and not the social part, but I’d like to hear your thoughts on that.
SM: Technology, like I just said, it’s easy. It’s tangible. It’s easy to see. That’s why we gravitate toward it. I myself am guilty of that in technology. I love technology, but it’s the social part of it, the people and process part of it, that is really hard to do.
Imagine you are bringing in a new paradigm to people who are so entrenched in doing things in a certain way all their career. And now you say, for the modern time and needs, you need to change. For some people, it is job security to keep repeating what they’ve done. And now you say, rethink and redo. I mean, people will resist that.
Paul, I’d love to hear how was your experience in Roche?
PR: I think in Roche and other companies as well, over the years, businesses have always been fighting with IT. If IT tried to force different ways, different technologies, different practices on the business and say, this is how you do it, or you don’t get to do it unless we say so because we get the budget for this.
Businesses either suck it up or in some cases, they’ve gone rogue, on their own, with their own money, with their own budget. This has become easier and easier over the years because of the advent of the cloud, and they actually don’t need a central global IT department to provide infrastructure and governance.
I think that certainly a lot of the business functions within Roche have now realized this. Data mesh promises you complete control of your own destiny. You have all this. You can use what technology you want. You can use what platform you want. You can govern your data yourself. [Data mesh] was an enabler for them not to have to deal with IT.
IT has now changed their role into more of an enabler of capabilities, an accelerator of their data mesh journey. Rather than a mighty tower of governance, they are providing the tools and technologies that are really providing the accelerated path, the integrations, everything that [domain teams] don’t need to think about. They can focus on business value.
SM: I think two problems happened with data mesh. The first problem was when the concept of data mesh came out – it’s a concept. There were no guiding principles, which meant that I could do a data mesh, and you could do one, and somebody else could do it, and we could just call it a data mesh. So the lot of data mesh washing took place because there were no guidelines.
And that was by design. You know, when [Zhamak Dehghani] came out with these principles, she actually left the implementation details to the practitioners, which is great. That’s a great way to introduce a new concept, but I think it had unintended consequences.
The second problem that happened was that there was a lot of confusion as to other terms that came out. For example, Gartner introduced fabric. I think, all of last year, we were literally fighting on LinkedIn between data mesh versus data fabric, although they are two analogous ideas that don’t overlap. They’re two very different things. Data mesh is a concept, data fabric is an integration pattern, and you can do both together. But that led to unnecessary noise.
And I think businesses don’t really care. Businesses just have outcomes. They have KPIs, they have strategic initiatives and imperatives to deliver. They don’t care whether you call it data mesh or data fabric.
So I saw vendors jump onto the data mesh bandwagon then step away from it. And there was a lot of other confusion in the market. This year, the current state is, who cares what you call it? If the principles are good, if they’re applicable, let’s just go with that.
