 So as Arthiv mentioned, right, this is something that has gotten a lot between the last few months and the last two years. And like before I talk about what data mesh is, I just want to talk about why why data mesh came into the picture as well. So these are some of the numbers from a survey that was done by new Antige partners. This is around the time when Jamax article came around data mesh. And it kind of shows that the number of firms who are investing like more than $500 million in like big data and AI initiatives that grew by more than 60%. Right. The investment was growing. But on the other hand, the number of firms who were saying, Hey, it's either the big data or AI initiatives are not giving any results or they are yet and proven or they're it's too early. That as well was increasing. So it increased up to like 40%. So what this was showing us was a lot of data initiatives are failing and a lot of measures need like trying to create a data driven culture or unable to treat data as a business asset or competing on data and analytics. Right. And a lot of common failure symptoms for the data initiatives. I just want to briefly talk about those was a lot of times it was just failure to bootstrap. So a lot of data initiatives are technology driven rather than use case driven, which led to like months of design discussions and technology evaluation without adding much value to the business. And they even fail to bootstrap. If they did start the other places there, which they failed was while scaling. And it was either due to scaling for the sources aspects of the consumers, the variety, the diversity of sources they have to handle. And especially as the platforms and initiatives are scale. That's where the problems were coming up. Last but not the least is like failure to materialize data driven value. Right. So one initiative start to solve a particular use case that didn't happen. So another initiative started and so on so forth. So basically what they were getting started for that material that value was not being delivered. And there was not any culture change or odd change beyond those pockets of our indeed up there in the organization. So I'll also want to briefly touch upon the paradigms that are out there in the industry. And they, for example, we started the data industry with the we started with warehouse data warehouses, right. And when we started seeing some issues with it, the data lake came into the picture and that was is one of the most popular platforms data leaks out there. Then the industry started moving towards cloud and it was nothing different. It's just that the warehouses or the on prem data lakes started moving to clouds started using cloud technologies. Now these paradigms do their work very well up to a certain level. I think the problem starts to come up when we talk about scaling or when we are trying to scale according to a demand. And that's where challenges start coming with these paradigms. It could be there's like a disconnect between the domain experts who are producing the data and the consumers. There's like big gap getting created between the data producers and consumers, which eventually leads to all those failure symptoms that we talked about, especially if you're scaling. And that's with that in context, that's where data mesh comes into the picture. And it's so it's a decentralized socio technical approach. And the major part is it's for managing and accessing analytical data at scale. So that's really important aspects. It data mesh brings about that thinking that it's trying to change that thinking that when you're thinking about data initiatives, moving from just thinking about systems and tech perspective to more business or value driven thinking. It's also trying to bring together the org structure as well as the tech architecture to solve those problems that we were seeing in the paradigms that I just talked about, trying to close the gap between the domain experts, bringing the producers and consumers closer and also it helps it makes it easier to scale, especially on demand. So that's where data mesh comes into the picture. And the foundation of that is these four core principles, which I'll briefly touch upon the first being domain ownership, which talks about that the data that's being produced, the ownership of it, the responsibility of it is more is towards the domain that are producing it or towards the business units in the organizations that are actually producing that data because those are eventually the domain experts. The second one talks about data as a product. Now this talks about bringing in product thinking when you're thinking of data, how would the different data, what kind could be the different kinds of data products, what use case they are solving, how would they be interacting with each other? And that's where this principle talks about. The third one is cells of data infrastructure. It's basically all the capabilities that the data infrastructure should provide, plus being cells of as well, one of the important points to implement these principles as well. So for example, we're trying to, this talks about having as much automation as possible. The idea being that the developers or the business analysts who are working on creating the data as a product are more focused on the business use cases rather than thinking of infrastructure. They already have those things being provided by the platform or the cell server data platform. The fourth principle, I think that relates the most to what we just talked about is the federated computational governance. So this is kind of built into DataMesh itself. And this talks about how do we enforce the standards in the DataMesh ecosystem? How do we make sure that there is an interoperability between the data products? And the second aspect that it also talks about is it's federated. So the governance itself is there's a bottom up approach as well. So a lot of standards or a lot of ownership is at the domain level as well. And then there are some standards or ownership that needs to happen on the global level as well. So it's like at each and every level you have this governance model that works along with all other principles together and brings all of these concepts together as well. So that's in brief about DataMesh. I am not sure if I did justice to the topic. But yeah, that's I'll hand over to Aathif if he has more to add on any questions. I think so one of the key things that stood out to me is that this is like the social technical aspect. And that to me has been personally another very interesting concept of DataMesh where I feel like it's very different from like other paradigms already out there. So why do you feel like social technical or what does it mean to be social technical? Can you sort of explain more on that? Yeah, I'll definitely try my best. So yeah, so when we talk about DataMesh, it's not just talking about the tech and the tooling. That's that's the tech aspect that we generally talk about. The social aspect is a lot around the social structure, the org structure, how can we bring that culture into the organization itself for people to understand. So these principles, right, even if we talk about domain ownership and the governance, there is a lot of tooling behind the scenes, which is helping to enable that. But in the end, it's a lot of culture change for the organization as well. Going from a centralized structure where everyone, like there's a central team sitting and managing all the governance, to a more federated structure where there is one someone at a global, which is enforcing global standards, but then the whole governance model, which is trickling down at each state or product business unit domain on a domain level, which has a level of control on for their own domain, their own business units. They have that level of deciding standards for that particular domain. Of course, there are few standards that needs to be enforced globally. So that's there. Again, with the domain ownership, right, that concept of with the current paradigms, the concept of we're putting all the data at one place, and then there would be someone who is managing it or someone who will be going through it, analyzing it. And then it will go to the consumers that gap that to that thinking of the people who are producing the data, the experts, they are owning the data as well, the analytical data as well. And they'll be responsible for the quality. They'll, because they'll know best about what the data they're publishing. So that's kind of adding that social change or the social aspect as well, along with all the tooling, obviously, which the sales of data infrastructure talks about. It also talks about a lot of tooling, which might not already be there, but building those architectures or into place which enable these aspects. So that's I feel that's something new that DataMesh talks about. Sumita and Aditya, can I add just one first one? Just to, you know, illustrate this with an example, right? Now, I think Sumita did a great job of explaining the four principles and the social aspect, which is very, very important. And that's why we call it a social technical aspect, right? But think of this as an example, right? Just try to paint a picture. There's an operational team, say, which manages the order data within an e-commerce application, right? There is orders coming in. There are transactions coming in, customers making purchases. And there is a lot of tons and tons of order data getting generated. So say I'm part of that team, right? Now, in the historical world or the way we today perceive a lot of data ecosystems is that I am the team that's responsible for making sure that my system is available for the end customers, right? I am going to manage and make sure that the order transactions go through smooth and I'm happy with that, right? And what I used to do was I would take this order data and there is a nice big wall, right, within my organization, and I'm going to throw this data right over that wall, right? And on the other side of the wall, there is sitting another team which is the centralized team that Sumita and Arthit both mentioned about, right? And that team has the responsibility to make sense of what this data is about, right? And now imagine that within a large e-commerce organization, there are at least 50 such teams producing different types of data from different quarters of the organization and all doing the same activity, throwing their data over the wall. Now, I want to just imagine what is this central team going through, right? They don't understand what all this data is coming from. They don't understand what are the constraints and the quality standards that this data needs to adhere to. They don't understand what are the needs of the consumers on this specific data, right? So now their situation is at a very, you know, state of flux. Now, having said this, you know, these ecosystems, they used to work, right? Probably in small organizations where the needs were quite standard, where we knew that, okay, these are the five reports that we need to produce at, you know, every one week or every four, every one month and probably this used to scale. But then now, given the fact that we want to hypothesize on data, we want to be a data-driven organization and there is so much nimbleness that's required to, you know, expand the use cases that you want to address with data, that shift is required, right? Now, instead of saying that central team should do all the heavy lifting of understanding all the context of the entire organization, the social aspect of data mesh requires to shift this responsibility left, right? To the producers of the data that if I own the ordered data within the e-commerce domain, I should be the one who should understand what are the insights that my consumers would be interested in on top of my ordered data, right? So I take ownership of my data, not just from the operational, transactional world, but also from the analytical and insights goals. I think that's the shift that I think best explained in an example to just, you know, put a perspective that what is changing from the social aspect, if that helps. Yeah, I know that. I feel like that's a great response to that problem. Also, one of the things I've seen and I feel is the reason why a lot of organizations fail to make any use of their data or have a bad governance policies. A, you know, when they try to, for example, decouple everything and say governance is separate, technology is separate, right? Like you try to, like the governance are the set of people that will come in once the technology people do everything, right? And that doesn't work at all. But at the other end of the spectrum are also companies which are sort of saying, oh, let's just, you know, completely change the way we work and bring in these new tools and technologies and, you know, automate everything from the first go itself. And that doesn't work either, right? Because, like, it also depends on the people who are operating these tools because unless you build like a data culture over time, unless you embed governance and a lot of these things into the organization, right? Like you can't just change things overnight. So it needs to evolve very organically. And the tooling is highly dependent on the people that are, you know, driving these changes. Cool. So another interesting thing that you mentioned Vania is this notion of distributing responsibility, right? Like so there are no central teams. My team is responsible for its own, you know, for its own data. So a question I had on that was like, how do you feel that works out? Because, you know, if you delegate responsibility to everyone, right? How do you make sure that they're actually following your organizational policies? A lot of times what tends to happen is that people are not aware about standards and procedures or maybe the other thing that could happen is that maybe everyone has their own standards and procedures. So in that way, like how do you unite these people and, you know, basically enforce some level of governance for everyone? Yeah. So I will add in, Sumita, you can add in definitely after the response once. So if you look at the four principles that Sumita spoke about, right? One of the principles is domain ownership, which we spoke about, right? The paint, the picture that we tried to paint with the e-commerce order management data example right now. At the right end, we have the governance, which is the federated computational governance, right? That stands as one of the pillars of data mesh. And I think that's the beauty of it, right? That no change is possible unless we take a stab on people, process and technology, right? And that's where I guess the federated word comes from, that if we want to talk about, you know, a governance which is not centralized governance, right? That that is being enforced and mandated right from the top. What we are talking about is you still want to enable the team's autonomy to own their data, to understand what is the best way to represent their data. But then there still needs to be, you know, the facets of interoperability, right? You still need some guidelines on how should data interact with each other across the domain boundaries. And I think that's where the federation comes into effect, right? That it's about upholding the sovereignty of the teams, but at the same time establishing the guidelines again, I'm, I'm mentioning the word guidelines, not a mandate, right? Guidelines which say that what are the ways in which I would do my data modeling, right? Now if a customer is called Cust in one domain, I would like to call it Cust in the other domains as well so that there is a likely way in which I can join this data, right? Because we all know that value gets unlocked when you are able to play with data, join data, you know, aggregate data. And I think to enable all of these facets, you do need a lot of consideration on how do you model your data, right? What are those global identifiers that should be leveraged, you know, across the domains to, to mention or to address a given data point in a very unique way, right? So that data can be joined, right? So those guidelines can always be created by having representatives, you know, from all of these domains who understand the dualities of their domain, but at the same time can also represent how should the guideline be evolved, right? So there is no target state, Artifair, right? It's all an evolution and I think every organization is going to go through that learn and test culture where they identify what is the best push and pull between enabling the autonomy of the domains versus identifying sovereign guidelines, you know, with a group of people from, from various domains coming together to define them. If that makes sense, yeah. It's just to add to that as well, that the, since the principle specifically come to that the other word that computational that's there in the principle that, that actually talks about what you were saying, right? Who, who makes sure if there are some standards that need to be followed. So that's where the cells of infra talks about like you should have something which helps automate those policies or you can create those policies through the automation through the framework. It provides that framework so that you can create policies at a global level as well and that platform helps in enforcing those global level policies or standards that need to be there. Like something if, if for example, Vanya talks about that example. So there the customer becomes something that's really needed. If there's no odd, if the order is not against any customer, it doesn't make sense that data needs to be like flagged or it needs to be figured out what's wrong there. So for example, that's one of the standards that needs to be there globally. Everything is linked to a customer. So that's, that's where that comes into the picture. So to make sure that if there are policies or standards that need to be followed across all business units, there's a framework which can help create those policies automate those and implement those standards. Yeah. So what I'm hearing is as a summary, if I were to summarize like a conversation is to have governance has multiple layers. Right. There is a central layer that is responsible for baking in the automation and the policies and the guidelines. And then the individual layers are like the individual owners of the data extend that, you know, extend those policies using that central framework. Cool. So there's a question from the audience as well. Is this data governance approach dependent on the company teaching a certain data size or right from the start? So I think I'll take that question. Right. So I feel like if you're trying to do this once your company has reached a certain size, you know, you've already lost the game. Right. It means that now you suddenly have this big problem of how do you scale out that will limit you until you get the right practices in place. Right. So technically, according to me, a good governance approach is something where, you know, you go lean for sure, like you start out with the most minimal set of governance and policies that you feel are right for the organization. But at the same time, like you try to empower the people to understand these policies and also make sure that people, you know, you are building this culture of shared ownership as you go along, right, as you increase in size, not when you've reached a like a particular size at that point, like if you try to scale, it will take you time to just start introducing these ideas, these capabilities. Right. And it'll just slow you down.