Hi, I'm Tim Berglund with Confluent. Welcome to Data Mesh Module 2: Data Ownership By Domain. So, this is the first principle of Data Mesh, domain-driven decentralization or data ownership by domain. The objective of this principle is to ensure that data is owned by those who understand it best. So, this pattern is a reaction to what we've come to realize over years of practice of doing things the other way, that a centralized approach doesn't work at non-trivial scale. Okay. What that centralized approach does is cuts across domains, cuts across units of operational or business expertise, domain expertise by optimizing for a common set of technological skills. So people who know how to run the data warehouse, they're the data team. They might not know much about how particular parts of the business work because they're too busy trying to be good at data warehouses. So that's just the wrong direction. We think, you know, that we're cutting the wrong way. We should be cutting vertically, just as we've been saying for a few decades now, the way we ought to cut application functionality when it comes to application work. So that horizontal or centralized data management might work well for a small startup, but not for an enterprise. And probably the best way to understand this pattern is to think not about the pattern itself, but its anti-pattern, the central data warehouse like I was just saying. So let's go back to that. Typical data warehouse implementation, here, is that we've got lots of data sources spread across the company with, you know, varying levels of quality between them. There'll be many ETL jobs which are maybe running in different systems and pulling these data sets back to the central data warehouse and the data warehouse teams are often required to clean up and fix a lot of that data. If you've ever done this work or if you love someone who has, you know that like 95% of the work is cleaning and the actual extracting and loading is, you know, the remaining 5%, maybe it's the remaining 40% as these jokes go. But this central team doesn't really understand the data sets that well. Certainly less well than the domain teams where the data originates, the people who actually, you know, inserting those rows and databases are producing those messages to Kafka topics. Another challenge is that these source systems which are feeding data into the data warehouse don't behave particularly well. They haven't been built with responsible data sharing in mind. These are people, you know, imagine sort of getting beaten on to build application features. They're not thinking, gee, how can I make this data shareable? They're like, no, I just, I need to make, I have these, these story cards. I need to pull them off the wall and implement them. I need to get these things done and usually supporting analytics isn't a concern there. That's the thing that this horizontal data team will come in and translate your strange, extremely normalized application schema into something they can use. That just hasn't worked out well, is kind of the lesson. And the centralized approach is in contrast to the de-centralized approach of the Data Mesh. In a data mesh, ownership of a data asset is given to the local team that's most familiar with it and its structure and its purpose and its value. In this decentralized approach, there are many parties who are working together in a big enterprise, right? There's lots of teams building stuff and they all exchange data through the Mesh. And we'll talk about the nature of that exchange here. If you could just kind of, you know, imagine data moves from place to place for right now. Here, the parties that own the data and the responsibility to be a good steward of that data, those are both explicitly defined and known to the rest of the organization. And that owner is typically co-located in the part of the organization where that data originates. That's what we call the data's domain. Rather than being centralized as we did with a central data warehouse team. This is really what we mean when we describe Data Mesh as being decentralized. So a practical example: imagine Alice is working on the order's domain at the top here. We have Joe down in the inventory management at the bottom. Joe gets some bad order data from Alice. What does he do? Well, his first option is to try and fix that data locally for himself. And maybe he would do that. He, you know, he might be able to, he might not, but let's just say he does. The problem is that doing that just fixes the data for him. Also, he's coupling his inventory product to his local fixes that he's applied, which are themselves brittle. They have a risk of breaking if Alice decides to fix the problem at the source and his own fix might be brittle with respect to hers. You know, she corrects the error at the order service where it came from. So a better approach is for Alice to fix Joe's problem at the source, for the benefit, not just of Joe, but anybody else who might want to consume her data product. So in this way, everybody in the organization can benefit from this change. For that to work, though, there has to be a couple things. One, a process where Joe and Alice can communicate quickly. And two, Alice has to be a responsible member of the Data Mesh. So that means she's both willing and able to make changes like this quickly so her data in the Mesh is always of good quality. There have to be incentives in place for Alice to think that way. For her to think that this is a product that she's maintaining. So in summary, we can say that this approach ensures that the data doesn't diverge in different ways across the organization, Alice is always publishing, in a sense, the right thing. The main recommendation we can take from this principle, domain-driven decentralization, is to learn from domain-driven design, or DDD. You should use a standard language and nomenclature for data. You know, that stream of events really should create a shared narrative that business users can understand. And their various flows through the Mesh are comprehensible by those non-technical people. All right, this wraps up the first principle of the Data Mesh, which is called, again, domain-driven decentralization. In the next module, we'll dive into the second principle, treating data as a first-class product.