Is Master Data Management (MDM) dead?

Speaker 1: This is Catalog & Cocktails, presented by data.world.

Tim Gasper: Hello, everyone. Welcome to Catalog & Cocktails, presented by data.world. It's your honest, no BS, non- salesy conversation about enterprise data management with tasty beverage in hand. My name is Tim Gasper, longtime data nerd, product guy, customer guy, joined by Juan.

Juan Sequeda: Hey, everybody. I'm Juan Sequeda, the principal scientist at data.world. And as always, it's Wednesday, it is middle of the week, end of the day, and time to just have a drink and relax. Let's chat about data, have an honest, no BS conversation about data. Today, our guest is Malcolm Hawker, who is the head of data strategy at Prophecy. The really cool thing about Malcolm is that he's seen it from so many different angles. He's a former Gartner analyst, he's been on the buyer and user side, he's now on the vendor side. So, he has all these different perspective. And he also has a podcast called CDO Matters. Malcolm, how are you doing?

Malcolm Hawker: I am doing well. Aloha! I should say" Ola," since you're in Mexico. And hey, Tim, from frozen Austin.

Juan Sequeda: You are right now in sunny-

Malcolm Hawker: I'm on the east coast of Florida. They call it here the Space Coast. I get to watch Elon launching his missiles into the sky regularly.

Tim Gasper: Nice.

Juan Sequeda: At least, we're all here. Great. And Tim, you have power. Hopefully, it stays like that.

Tim Gasper: I have power for now, yeah. We got frozen rain for the last 36 hours happening in Austin, Texas. Fingers crossed, we're good to go. This is a live show everyone, so we roll with the punches. Malcolm, good to have you on the show. This is great.

Malcolm Hawker: Thank you.

Tim Gasper: And CDO Matters is great as well, so we're excited to do a little bit of collaborating here.

Malcolm Hawker: Much appreciated. Yeah, I did the promo and you really can't escape it even though that's a fake background. I was telling the story that I do actually own that sign. We paid a lot of money for a neon sign, thinking I'd be the next Joe Rogan. As it turns out, LED lights don't flicker. They don't emit light consistently. They actually flicker just like in animation. They literally have a frame rate. Digital cameras have a frame rate, and if they're different and they're out of sync, it just creates this horrible problem. It just messes with all the pictures. This is the best I could do. I had to take a photo of my awesome light and Photoshopped it into a fake background. That's the story behind that.

Tim Gasper: But it is real. It exists. It's just not inaudible.

Malcolm Hawker: It is real, yes. I have it on the floor down here, right behind me, but yeah.

Juan Sequeda: All right, let's kick it off with our tell and toast stuff. What are we drinking and what are we toasting for today? Malcolm, kick us off.

Malcolm Hawker: I'm not being very exotic. I have a LaCroix water. I was telling Juan I am the president of my local homeowners' association and I have to be on the straight and narrow for a meeting later tonight. If I wasn't having to do a HOA meeting later tonight, I would probably be having a lovely Belgian ale. I love Belgian beer. The heavier and stronger, the better. I'm Canadian and there's just something in me that calls me to this, the big beefy... Like the triples and the quads, I love that so much.

Tim Gasper: Nice. What's your favorite Belgian?

Malcolm Hawker: Oh my gosh, the list is really long. Old standby, I really like Chimay. You can't go wrong with Chimay. I mean, just-

Juan Sequeda: Delirium Tremens is mine. I think that's just the best-

Malcolm Hawker: Tremens is good, yeah. And there's a few different varieties of Tremens. I like it. There's a lot. They're really, really hard to find, particularly here in my little beach town. But even a Duvel, I even like a Duvel. But yeah, the list is long. My favorite is probably actually not Belgian, it's Canadian. It's called La Fin du Monde.

Juan Sequeda: Yes, that is phenomenal.

Tim Gasper: I've had that. That is a great beer.

Malcolm Hawker: Warning. After two of those, you should be seriously reconsidering your option for a third because if you do, then you're on a one- way path. That's it. Like the Bombay doors are open, target is locked and acquired. You are going to woozy town.

Tim Gasper: It will be La Fin du Monde for you.

Juan Sequeda: inaudible A Gulden Draak, that was-

Malcolm Hawker: That's a good one too, yeah. Yeah, that's good.

Tim Gasper: A good one.

Juan Sequeda: We can talk a lot about Belgian beers here now but I don't know, I'm just having a nice, classic Favela. I am right now in my other place in Playa del Carmen, so it's just keeping it simple and classic.

Tim Gasper: It's appropriate.

Juan Sequeda: How about you, Tim?

Tim Gasper: I'm drinking Antica vermouth with Campari on ice. It's like a Manhattan without the whiskey, so a little bit bitter and a little lighter.

Juan Sequeda: And what are we toasting for?

Malcolm Hawker: I'm toasting that it's 80 degrees and sunny outside. I lived in Austin for 20 years and I know what it's like when there's ice, so I'm toasting that it's sunny on the beach.

Tim Gasper: All cheers to that and wishing that it was 80 here and sunny as well.

Juan Sequeda: Cheers to that.

Malcolm Hawker: I'll cheers to that.

Juan Sequeda: I have 85 here. It's a little bit humid but nice and sunny. So, cheers.

Malcolm Hawker: The sacrifices we make.

Tim Gasper: Wow.

Juan Sequeda: I was in New York this morning, so I'm not here yet.

Malcolm Hawker: Oh wow.

Juan Sequeda: Anyways, we can talk about that later. But all right, warmup question. What's something in the world that is popular or trending that really needs to fade away and rest in peace or die?

Malcolm Hawker: Die is a strong word, it's so final. But I can even fine- tune it, I would say in the data world. And in much deference to some really, really smart people who focus on these things and as important as I believe user enablement and user training is, I really think that as a concept, maybe as a phrase. I will say this, as a phrase, data literacy really needs to go away. And not because I'm opposed to having people who know how to use data and not because I'm opposed to training, and data is a tool and what tool and what circumstances. Those things are important and they need to be trained but I have some problems with data literacy as really, as a concept and as a phrase. The underlying premise of data literacy is that the thing, not all things but the thing that is holding organizations back from getting value from data is inherently what's a skills gap right there. There's a gap in the skills of your users of the data and you need to close the skills gap. That may be true but if you assume that always, you're overlooking a few key things. The most important one being the fact that your product may be faulty, right? Your data quality may be low. There may be lots of other things that you are putting into your product that are holding the organization back from realizing benefit of that product. But if you just assume, " It's a skills gap. They just don't get it. You can lead a horse to water." I've heard all these things as a Gartner analyst, by the way. I've heard, " You can lead a horse to the water. You can make the world's greatest dashboards. I can't force them to use it. Must be a data literacy problem, and let's embark on an expensive data literacy program." So yes, training is important, enablement is important. Go to market, I would argue, if you want to take it from a product management perspective. Incredibly important. But just always assuming that the underlying cause is a skills gap, I think, can create divisions between product creators and product consumers that is really toxic.

Juan Sequeda: I love how this was supposed to be a funny question and you just dove in straight.

Malcolm Hawker: It's what I do.

Juan Sequeda: But I'm with you with the data literacy. I got a funny little thing to this is for me, my answer to this question is a different topic. inaudible music just needs to fade away. I'm tired of it. But all right, no. But sorry, I know. Tim, do you got a funny answer right now or-

Malcolm Hawker: I went too deep. It's supposed to be funny and light. I killed the mood, man. I'm sorry.

Tim Gasper: Oh no, it's all good.

Juan Sequeda: inaudible dark in rest in peace, right?

Tim Gasper: Yeah, it must be. I'll give a quick funny one. This obsession with Taylor Swift, that needs to go away. Everybody chill out. It's just Taylor Swift, it's no big deal.

Juan Sequeda: All right, now let's get in. Honest, no BS. Is MDM dead or should it be dead?

Malcolm Hawker: Absolutely not. I think we waste a lot of time thinking about this and asking this question. Because I think it's a natural response to one thing that may be dead, which is the idea of a single version of the truth, right? I just recorded a podcast with a super, super smart guy named Jeff Jonas, who is the CEO of a company called Senzing. They do inaudible-

Juan Sequeda: By the way, he's our guest next week.

Malcolm Hawker: No. Really?

Juan Sequeda: Yes.

Malcolm Hawker: Okay, promo. Okay, yeah. Anyway, what we're talking about, the death of a single version of the truth and the idea of a kind of top- down, centralized- thou- shalt approach to your customer. Master your product, master your location, master employee, master... Those models don't work anymore and they create an animosity, but again, between the producers and consumers of data. When you say things like, " This is the version of customer that you have to use. Whether or not it meets your business needs is irrelevant, here's what you have to use." And stakeholders rebel against that stuff. It results in things like the data mesh. It results in a whole bunch of other things where stakeholders are saying, " No. My context, my use case requires this version of the truth." And it's generally accurate because it's going to fit the need, it's going to help you meet the needs of your end consumers. So, there are multiple versions of the truth. We can absolutely, positively recognize this. We see this every day. It's how companies operate. The way finance looks at the world is different than the world market, different than the way that marketing looks at the world. And they're both correct. But getting back to... Juan, we'll talk about the history of MDM. People conflate these things, right? They say, " Oh, MDM. That's about single version of the truth. And that really doesn't fit business needs anymore, so MDM must be dead." It's most certainly not dead.

Juan Sequeda: Let's dive into this. Single version of the truth, I 100% percent agree with that. And actually, I would love to go talk to somebody right now who would say, " We disagree with this." It's something we should probably dig into. Why would you want to disagree? That's one thing. But before we dive into more things, how do we define MDM today? What is the definition of MDM? Because if it's not single version of the truth, what is MDM? What's your definition?

Malcolm Hawker: At a high- level, I actually made a post on LinkedIn about this yesterday that speaks to this at a very, very high level. MDM is about the people, processes, and technologies that allow organizations to maximize the value from their shared data assets. That last phrase, shared data assets, is absolutely positively critical. If you have data that is being widely shared cross- functionally, right? A data between sales and finance, between logistics or supply chain and product marketing. If data is being shared across those organizations, you need to have consistent governance and consistent management and consistent care in feeding of that data. Otherwise, how do you operate, right? How would you ever take a contract out of sales and have that contract be easily, seamlessly, deeply integrated into finance for RevRec, right? Data naturally moves across the organization between functional silos. MDM is the grease that allows the data to move seamlessly across those functions and allows it to have consistent meaning, consistent quality, consistent definition, consistent management. That's MDM.

Tim Gasper: That feels-

Juan Sequeda: You describe everything.

Tim Gasper: It feels broad. It feels like good data management. Is that what good master data management is? It's good data management?

Malcolm Hawker: The first time I ever met Juan in person, we were in Boston at the CDOIQ conference last year. Basically, I was waving my MDM flag, right? I'm an MDM guy. And Juan said, "It seems outdated. It seems like your father's Buick. I've only ever looked at MDM as like data integration on steroids." Is that the phrase you used, Juan? No, you didn't need to say that. It's something like that.

Juan Sequeda: No. The phrase I used which is what Tim said it for, " It's MDM, fancy data integration."

Tim Gasper: Fancy data integration.

Malcolm Hawker: Fancy data integration. Yeah, if you looked simply at MDM as a physical act of plumbing. Sure, the fancy... I guess, the fancy comes into things like consistent governance and consistent structure and consistent quality definitions. Basically, consistent governance. I guess, that could be the fancy part. Yeah, I guess so. Sure. But having consistent rules of the road is absolutely business critical, and having consistent rules of the road at multiple levels is critical. You're operating cross- functionally in the ways that I was talking about. But when you move up an organization, when you move up to value change at the top of the organization, and you're talking to a CEO and your CEO asks, " How many customers do we have?" There's only one answer, right? So yes, context matters. And that context can vary at a functional level, and it can even vary within the organization through the organizational hierarchy. Instead of saying a single version of the truth, I would say instead that every context will have a single version of the truth and you can have multiple contexts.

Tim Gasper: For a clear truth, context.

Juan Sequeda: Per context.

Malcolm Hawker: Yeah, and context is necessary. This is why we see graph playing a bigger role in MDM, in helping inform MDM decisions, helping inform MDM data models and the like. But it is ultimately all about context because that's how businesses run. They're functionally aligned and the functions are roughly aligned to context.

Juan Sequeda: This is an important point here, every context should have a single version of the truth in that context.

Malcolm Hawker: Yes.

Juan Sequeda: This is a good-

Malcolm Hawker: And if you don't, that's chaotic.

Juan Sequeda: But you have multiple contexts then probably, are you?

Malcolm Hawker: Right. The real challenge here for organizations is that you can acknowledge conceptually, theoretically. You can be listening to this right now and you can say, " Yeah, that makes total sense. Got it. Check. Every context will have its own version of the truth. Let's go do it." I think this is what people are doing with the data mesh. " Let's go do it. That sounds great. Domain centricity, that sounds fantastic." The challenge here for a lot of organizations, and this again comes back to negative press for MDM were at large. The challenge here is that when you go from one version of the truth, one record to rule them all, old school, old school MDM, that's one set of business rules that you have to manage. One set of quality standards, one master data model, one thing to get right from a governance perspective. When you state, " Now, we're going to have context centricity," then you go to N different sets of rules. And that jump, for a lot of organizations, from one set of rules that we have to agree on to multiple sets of rules that we all have to agree on and manage, by the way. With even including things like data stewards, with technology, with business process management, all of these things. To go from one to N is a huge jump for a lot of companies where generally, what we see across the board is that companies consistently, consistently lack sufficient focus on data governance. So they make the jump to data mesh and say, " Let's go to data mesh, complete domain centricity." Without the underlying framework and foundation of data governance, you're going to have a hard time because the answers are going to be different depending on the reports that you're looking at by domain. And maybe that's okay, but if you want to resolve those differences at higher levels of the organization, you better have the governance maturity in order to do it and a lot of companies don't. Then they go back and say, " MDM failed, so it must be MDM's problem that we don't have sufficient investment in governance, that we don't have sufficient focus on policies and procedures related to how we actually maintain and manage the data."

Juan Sequeda: You said something really key here, which is about you're starting... You have your old school way mentality or culture of that single version of the truth and moving towards a multiple version of the truth in different context. That's hard just from a cultural perspective. We were chatting before about the history of this. How did we get here? How did MDM start off? Because I think we need to understand our history to know where we come from and to know where we should be going.

Malcolm Hawker: To a certain degree, yeah. I think... Go way back. Let's go into our Siebel time machine. And I'm old enough to remember Siebel software and these single, monolithic ERP stacks that did everything 20 to 25 years ago. Where there was a single table for vendor, there was a single table for customer, there was a single table for product, for... You name it, right? There were single tables with these monolithic ERP suites. That created the mindset of a single version of the truth because when you have end- to- end one set of software, you don't have to join across multiple customer tables, multiple product tables. You just got one. It created a lot of mindset for older folks like me that this is how things work, right?

Juan Sequeda: So you started out with, " Here's this one application, the ERP, and-"

Malcolm Hawker: Yep.

Juan Sequeda: All the customer data is there. So whatever's in that system, that's the right data period because there's no customer data outside of it.

Malcolm Hawker: Yep. And it created these misguided notions of ownership, too. Data ownership, what does that even mean? Separate topic that we can talk about, right? I guess if I had my DM book, my data management book of knowledge. I opened the beloved DM book, an angels sang and it would say, " Here's what data ownership means." In theory. But in practice, " Okay, data ownership. Really?" Particularly for master data, particularly for that data that runs cross- functionally. You're going to say one person owns that? Good luck with that. Separate issue, but going back to the history. We started with these monolithic giant ERP stacks, and then along comes Salesforce, and along comes Oracle and a few others that enabled the democratization of IT. All of a sudden, these applications start springing up all over the place. But the classic example is, again Salesforce, where you had ERP data and you had CRM data and you needed to try to find a way to reconcile the two different views of customer. Which created a lot of weirdness and conflicts, and organizations says, " Finance owns the customer." Marketing owns the customer. Who owns the customer and when both do, they both do. But that really was where the need for MDM was born, at least as a unique software competency. One could argue that MDM has always existed as a discipline, as a way of managing data, managing those governance policies, managing workflow, managing stewardship, managing access rates and all those other things. You could argue that MDM is a discipline as it's always been there. But MDM is a technology, really. It was born out of the democratization of IT where all of a sudden, you had these different versions. Fast forward a little bit, the explosion of data warehouses and the explosion of BI analytics layers where even there, you could start to see some of these problems manifest about hitting a lack of a single version of the truth as it were. That's some of the history and why we have some of these baggage of misguided notions of who owns, misguided notions of single version of the truth. Misguided notions that all centralization is bad, because it's not. It certainly not. There are architectural reasons for having something centralized. I could go on but that's some of the quick history there.

Juan Sequeda: No, I appreciate going down to this history because it really helps us understand how we got here around this. I always say when it comes to centralization- decentralization, we need to go find a balance with this stuff. And I think the govern... We talk about data mesh, too. I think the aspect that we don't talk that much about, people are just figuring it out, is the governance side around it. Governance in this decentralized world, how should we start? Do you start to centralize then you go decentralize? What are the different patterns that you're seeing that either... This is where I'm fascinated about all the different perspectives that you have, right? From an analyst, from a vendor, from a buyer, user. What are the different options, trends that you're seeing and approaches when it comes to figuring out how to decentralize?

Malcolm Hawker: Yep. It's a really good question. If somebody asked me... I'm putting on my Gartner analyst hat. You can't see it. But I used to get this question all the time when I was a Gartner analyst, " Data governance, where do I start?" Right? " This seems scary, this seems big. I've downloaded a few different data governance frameworks including the demo of data governance framework, and there seems like an awful lot of work here. What do I do?" Right? " I've just been handed the data governance baton. What do I do?" The correct answer to that question is to take as much of an outcome- driven MDP approach that you can. The days of going and hiring Deloitte to figure it all out... You can still try to do that if you want, by the way. I've hired them all. I love Deloitte, I love Accenture, I love McKinsey, I love Tata Infosys, you name it. They're fantastic. If you want to go hire them to try to figure out governance, you better have some pretty deep pockets and you better be pretty patient because what they will do is take this bottoms- up approach to governance. They'll take a framework- driven approach to governance that you can't argue with. " By the way, this is a governance framework and these are all the things that you need to do." But they will take that bottoms- up approach and you'll be looking at months and months and months and months and months of requirements gathering, a policy definition of all these other things needed to put together an enterprisewide governance framework. That's my hand signal for enterprisewide governance framework. What I would say instead, taking a pragmatic, " I've been there. I've had my knees skinned up pretty bad by falling and failing at governance." What I would do instead is be incredibly outcome- driven. Go find one or two or three stakeholders in your organization that have acute pains that are caused by a lack of governance. Maybe you don't have a single consistent view of a customer within your marketing organization. The proverbial 360, right? What would a good outcome be from a better 360? Maybe not even a 360, maybe a 280. You go talk to your chief revenue officer and maybe she would tell you, " Then we would have better cross- sales and upsells." Or, " We would know if we were selling product A to customer A and product B to customer B. We'd know if there was a cross- sell opportunity there just by having some visibility across those different selling lanes." Hey, that sounds pretty good. What's the governance needed to enable that? What is the governance needed to enable more cross- selling or more upselling or some form of a single version of the truth? Instead of trying to solve for all aspects of a governance framework, just solve for the aspects needed to deliver on that outcome. And when you do that, people are going to be excited. People are going to be thrilled. They're like, " Oh my God, we had no idea that these opportunities existed across our lines of business to be cross- selling our products. Can I get more? Can I get some more of that?" " Yeah, we can do that, but we're going to need a little more funding and we're going to need a little more investment in stewardship. And maybe, we do need to engage some consultants." But outcome- driven, outcome- driven, outcome- driven if you are engaging consultants. There's nothing wrong with that. Put them in a box. Put them in a box, meaning have an outcome. Say, " I want to drive an outcome of 20% increased cross- sales through better governance of data. Deloitte, Accenture, McKenzie, whoever. Can you help me with that?" " Yes, we can. But instead, don't do the bottoms- up. Let them go run rampant. Figure it all out because you'll be there for years."

Tim Gasper: So don't just start with, " Hey, come in here and solve..." Don't ask them to boil the ocean for you.

Malcolm Hawker: Yes.

Tim Gasper: Point them at a specific outcome. I love that. I think that's very good advice. I think that something that's interesting about this is we've talked about how to go about it, some of the history here, and then just this whole idea that MDM is dead, right? I think that the phrase master data management or MDM has fallen out of vogue. It's fallen out of the vocabulary a lot of data professionals. And I think folks will say things like, " I really need to get a better view of my customers." Or, " Oh man, I really wish that we could reconcile this product data," and things like that. But they never say it like, " Oh, master data management, I knew that," or something like that, right? Why is that? Do you think it's because these tools are... Because I think people have started to associate... I know I've fallen into this trap, too. Associate MDM more with an MDM tool, like the thing that Informatica sells that does MDM, that kind of thing.

Malcolm Hawker: Exactly.

Tim Gasper: Is that part of the reason?

Juan Sequeda: And I inaudible, I have always associated MDM... For me, this is the problem, too. MDM is that tool, which that tool actually is like just entity resolution, basically. It's like, " Oh, it's rules that you go do." So for me, MDM is like, " Here's the records of customers that we have created these rules and done. That's a fancy integration, go do that." But then it's much more than that tool, right?

Malcolm Hawker: Yeah.

Juan Sequeda: And it's not just about linking these two different records together. Not two, many other records.

Malcolm Hawker: Yeah. And from a critical capabilities perspective, again with the Gartner hat, MDM is beyond just entity resolution, although that is a key thing. But Tim, to your question of is MDM out of vogue? Yes, to a certain degree it is. I've been in so many presentations recently where what I hear are presentations related to challenges around MDM and people don't say it. I'll be the guy on the virtual conference and I'm literally screaming in the mic, "Say it. Say it. Say it." Because they keep saying, "Wow, you're a... Trusted, consistent, a place to get our customer data that we lack in our consistent governance and quality standards when it comes to key data that we share widely across the entire organization." And they're not saying MDM, right?

Juan Sequeda: I'm seeing right now, Rom has a comment right there. If you can show it, we can pull it up there. With the single version of the truth and for each context, how do we preserve the data integrity across independent or interconnected functions? Your point is, " That's MDM right there. There's the people and the process aspect to make sure that you have that integrity."

Malcolm Hawker: Yes. Rom, to answer your questions, from a policy perspective there would be consistent policies related to that shared data, right? Policies about who can create it, who can update it. That would be enforced in some data management hub like an MDM. Or yes, we could have conversations about a data fabric or a highly virtualized world, but there's still going to be some business rules there that need to be consistently applied as a backstop. I would say that as a backstop, but the rules are also applied within applications. This is something a lot of people I think don't get about MDM, is that they assume that MDM lives just in the data management world and it's beyond an outside transactional data and it's beyond outside applications that are managing transactional data. Far from the truth. MDM will live and breathe inside applications, meaning you're in a CRM and you're creating a new record for ACME Incorporated or Joe Smith. And there's a realtime call out to some MDM hub that is doing some Search- Before- Create to see, " Does this thing already exist or not?" That is doing realtime entity resolution against Joe Smith or gSmith@ gmail. com and on and on, to see if this is a valid record. Should we be creating this? Is the person that is trying to create this have the rights to do that? Rom, to answer your question, that's how you do it. That you try to stop the flow of garbage in at the time of create, wherever that create is happening. Whether it's in an application, whether it's in a data management system. But if you don't, there's also a backstop there where you can run processes against data in real time, daily batch, whatever doesn't matter, to find the anomalies that are naturally creeping into the system as it were. But yeah, Tim, out of vogue? Yes, I think it's kind of out of vogue. I've heard multiple situations where people just don't say it. And I think it's a result of a lot of people having maybe a little bit of scar tissue as it were with trying MDM and failing. The stories here, there's a lot of stories that failed MDM, right? Almost always comes down to lack of executive support and lack of a focus on data governance. It's never about a lack of technology. The technology argue late knock- knock is the easy part here. The hard part of the business processes is in the rules, particularly governance policies that go into managing that master data. So yeah, it's kind of fallen out of vogue because there are a lot of vendors out of there that see this and they realize it. Then they start selling shiny objects that basically tried to do MDM things, like a single version of the truth or a customer 360. You'll have like CRM vendors out there saying, " No, we can do that. Yeah, we can do that." And you've got data warehouse vendors out there saying, " We can enable data sharing. No problem." Right?

Juan Sequeda: Right.

Malcolm Hawker: And if you do data sharing, it's simply a mechanical exercise to provide access and permissions to data. If that's what data sharing is, great. But if you don't know how it was created, if you don't know the quality rules that went into it, if you don't know its lineage, if you don't know... If you don't know anything about that data and how it came to be, you're going to have a hard time getting any value out of it.

Tim Gasper: Yeah. There's such a proliferation of tools, techniques, and technologies now that it's pretty easy to make it seem like you can do these types of things, but it's hard to actually see... It's hard to actually articulate it. And especially think about data lakehouse type architectures that become quite popular now. There's a part of me that wonders if people haven't quite figured out how these valuable things... Just last week, we were talking about data modeling, right? How things like data modeling and master data management and data governance, how those things apply to these new paradigms where we've got all these cool capabilities like data sharing and we've got cool tool sets like DBT. But then how do these things fit into MDM, data governance, and things like that?

Malcolm Hawker: Yeah. Go look at Databricks, Snowflake. Go look at their websites. They will make you think, "The MDM, you don't need that. We can do that. We enable single version of the truth." And if you think that all you need to do, to do that, is to dump data into one bucket and to apply some consistent permissions to it... If you think that's what MDM is and that's all that MDM is, I guess so, but that's certainly not it. This is just like Groundhog Day all over again, right? And I'm having the good flashbacks which is, " We'll just drop it all into an HDFS cluster and your problems will be solved." " No worries. The data scientist will figure it all out and your poor data quality will just magically disappear." The fact that you've got five different versions of Jeff Smith in your database, " No problem. Those will all just somehow automatically go away when we throw it into inaudible or when we throw it into Databricks and applies in consistent permissions to it." That's laughable, right? No, it goes well, well, well beyond that. And at its core, what's needed is consistent governance and management of that data, not just ex post facto when you load it into some hub like an MDM or a Databricks or Snowflake or a CRM, but at the time of create as well. And that's what those systems don't do. But it's alluring to data people because you can say, " Yeah, why enabled a single version of the truth because I stood up Snowflake and my job is done, mission accomplished. Woohoo." But they'll go run a report against that data and you'll find five Jeff Smiths. And sorry if your name is Jeff Smith or something, you can get my point. Maybe I just go with Malcolm Hawker. If you get five... There's only three of me on the planet, so maybe a bad example, but you get my point.

Juan Sequeda: Getting ahead of ourselves here on the takeaways, but right now I'm seeing two things. One is that we continue to talk about MDM, in this conversation right now, and I'm realizing it is just best practices of managing data. That's what... And I think MDM has... Because it's existed for so long and I would argue that it has... It's not the bad inaudible, it's just the old thing that you associate with these old tools. I mean, that's it. MDM, you associate with tools. But in reality, MDM is more about this discipline. And that word, MDM, it's not... You don't think about the disciplines when you think about MDM. And part of me is like, " Okay, if it's a marketing thing, let's go rebrand it." I thought you mentioned this in one of your LinkedIn posts that it shouldn't be called MDM anymore. It should be called sharing data inaudible.

Malcolm Hawker: Shared data, yeah.

Juan Sequeda: Hold on. I think that's one aspect here is that this conversation has really evolved in to not look... It's not just MDM, it's really just best practices of managing data. And I think that's how you are defining what MDM is, that one-

Malcolm Hawker: Shared data, yeah. Not all data.

Juan Sequeda: But the second thing here is the technology. That as technologist, we end up with focusing on technology and the MDM definition of discipline of people, process, technology. We don't want to go to the people with the process stuff. We want to just jump into the... Dump things into this thing, into Databricks, inaudible and that then we'll go figure that out. That's the easy way out in... No. Then we want some magic wand automatically come up with ways, so we can automatically say if these things not only are... I mean, the same thing but like, " I actually can't access to this and stuff." Why are we so lazy? I understand we want to automate as much as we can, but there's just some stuff... I truly believe that there's just some stuff that we just need to put the effort into it. And if we don't, we'll just keep doing the same shit over and over again, over and over again, just Groundhog Day. And then we're going to have the same freaking discussion five years, 10 years, and so forth.

Malcolm Hawker: I tried the approach of, " Hey man, I just do the pipes. I don't do the water." I tried that many times. It doesn't work. And if you're a CDO making a decent chunk of money, good luck if you try that approach as well. It's not going to work, right? To point one, you got to go do the work, you got to go build the relationships, you got to go show the value. You have to earn the right to request fields be required. You have to go earn the right to request the business to act in a certain way. You have to earn the right to ask the business to do things a slightly different way. Just because you've been given a mandate by your CEO to go fix the data, doesn't mean that anybody has to listen to you. And typically, they don't. When they will listen to you is you go solve a problem, getting back to that customer 360 what I was just talking about. You can do that. You can drop a reasonably competent MDM, maybe even a CDP, maybe even semantic resolution software, maybe even... I won't go any farther than that. But you can go and solve that or a decent chunk of it, maybe not 100%. You're not going to get to a 360, maybe you only get to a 180. But maybe that's enough of a solution to drive some value for your sales organization. When you do that, you earn the right to go back to them and say, " Hey, listen. Here's what's possible. Can you see what's possible? I helped you drive$ 1 million of income revenue by uncovering some white space in your sales organization or cross- sell or upsell opportunities. I'd like to work with you some more and maybe buttoning down some of these processes here that are holding you back from doing even more great stuff. Are you interested?" Yes, anybody would be. But what I see over and over and over, and I saw this as a Gartner analyst, was honestly, a lot of self- aggrandizement that we've been given the mandate to go fix these things. We've been given the mandate to become more data- driven and lo and behold, I run the data organization. And those things are great, don't get me wrong. But that doesn't earn you the right to charge into people's offices and to say, " You need to do things differently. You need to change how you operate. You need to do all of these things to make our data better." Because chances are pretty good, they're already hitting their numbers, they're hitting their SLAs, they're wowing their customers, they're doing things well enough that your company's moving forward and growing. So, take a different approach. Be humble. Go in, find a way to drive value quickly. Keep things small. Then, have conversations about changing the way that we manage data or the changing the way that we onboard customers or making fields required that weren't required in the past and on and on and on. That's how we drive change.

Juan Sequeda: When you started off this conversation right now, this last part, you say you have to earn the right. And I'm like, yes, but part of me is... I mean, sometimes you just got to tell people we got to go do because that's why we have stop signs. That's why we got rule around these things, right? But I did not interrupt and I'm glad I didn't interrupt you because you went up and you wrapped it up safe, " But we got to be humble. You don't want to go barge into the office and tell me what to go do." Especially, when they're actually hitting their goals because... This is an excellent point. Like, " What do you mean I'm doing things wrong? Look at my numbers. I'm doing great." And then at that point, there's like, " Maybe in your world you're doing things great, but maybe not. It's affecting somebody else." Maybe, that can be the case. Or maybe you think it's great but it could... Great is the enemy of even better, right? Because we can do things better. So, that's a very interesting point and I think just again, be humble, be empathetic.

Malcolm Hawker: Yeah. Actually, one of the greatest things about attending the CDOIQ conference last summer wasn't just the fact that you were there. That was actually a common theme in a lot of presentations that I saw among CDOs, which is, " Hey, listen. Be humble here. Yes, you've been given a mandate. Yes, data is the new oil. Yes, data is critically important. Yes, it can transform your organization. But again, we need to be humble and we need to defer to our stakeholders in how to run the business the best way because that's their mandate. Your mandate is to how to manage the data the best way." So I couldn't agree more, I guess. I mean, I'm agreeing with myself but yeah.

Juan Sequeda: Okay, let's continue. Let's take a little bit of a side note here, something that you brought up. I'm here looking at our notes here, the side note. What was the side note we had? I missed it. Tim, remind me.

Tim Gasper: The side note?

Juan Sequeda: Oh, the data ownership.

Tim Gasper: Data ownership, yes.

Juan Sequeda: What data ownership mean. This is an interesting...

Malcolm Hawker: When I was a Gartner analyst, I really focused on data ownership being a function of two things, governance and policy definition. The rules of the road, getting back to your stop sign metaphor, right? The rules of the road. Who can create a record? Who can update a record? How long is the record? What are rules for data quality? When is it accurate, incorrect, blah, blah, blah? Policies related to data, incredibly important. Who owns that? And then who owns the execution and implementation of those policies? If you want to create a government, example here, there are elected officials that pass the laws and then there are police that enforce the laws. In the data world, we have the exact same thing. When it comes to some datasets, particularly widely shared data like MDM, and I didn't get into the MDM name change thing. We should talk about that, side note. When you're talking about data that is widely shared... Product, asset, location, material. You name it, the list is long. When you look across both of those axes, those lenses, right? Policy definition, policy enforcement. Who defines policies? It's going to be multiple people by definition. It has to be because everybody has a stake in customer, everybody has a stake in product, and they're all going to have their two cents to offer in the rules for managing that data. So inherently, collaborative exercise. If you are talking maybe from more through the lens of a data mesh... Yes, I just said it. And maybe you have complete domain centricity where you have aligned as an organization to say, " Okay, these sets of rules are going to be defined within this domain and I'm not going to go to even talk to anybody else." Perhaps, but I would argue even at a cross- functional level, you still need to define those rules. And that process is not, to me, adequately defined in federated computational governance. Separate issue. But defining the rules, it's generally going to be a collaborative exercise. And if you have to manage your data and do anything cross- functionally, it will be a collaborative exercise. There's more than one people involved in setting those rules. Enforcement of rules, same thing. You can have data quality rules enforced within an application, within a CRM tool, within an ERP, within an ETL process. There are rules that are being... You were applying a data governance rule. You are enforcing one the minute you model data, right? The minute you create a join, that I would argue that's a rule. How are these things related? What are the underlying rules sitting there? Again, that can be people in IT, that can be people in marketing, can be people in finance. Lots of people are enforcing those rules. The idea that there's one owner, owner, owner, owner of any of that data, to me, is like, " What?" I mean, I get it from kind of a racy perspective and it's convenient. We like to say, "You're going to own the data and be accountable for it." But if you can't control what people are doing in sales or marketing or in IT, if you have no control over both of those lenses, both policy definition or policy enforcement. If you cannot control either of those, you're going to have a really hard time as a data owner. Now, the only exception might be where you exist in this very, very insular organization where maybe you've got a monolithic ERP where data only lives in one application and serves maybe one or two tables and a limited set of reports. Where you have a small organization where you can maybe have one person be that owner? Maybe. But in most large organizations that I know, the data ownership is inherently a collaborative exercise, and to think otherwise is not productive.

Tim Gasper: Just to double- click on that real quick before we go to our lightning round here. What do you like better to describe folks that are helping to define and collaborate around shared rules? Are these data governance people?

Malcolm Hawker: Yeah.

Tim Gasper: Are they stewards? Are they... Laura Madsen talks about data ambassadors. What do you think are... What is the right way to think about this?

Malcolm Hawker: They're all of the above. I guess, I can say interview Laura Madsen next.

Tim Gasper: He's already been...

Malcolm Hawker: Oh, because I enjoy talking to Laura. Anybody that says in the first line of their book, " I hate data governance," when the book is about data governance, that's somebody you think you need to be talking to.

Tim Gasper: It's a sign it's a good book.

Malcolm Hawker: Yeah, it's exactly right. Whether you call it a data ambassador, whether you call it a data steward, lead steward, what you're talking about are data governance organizations. You can call it a data governance committee, you can have domain experts, you can have process experts, you can have IT experts, but they're all going to be sitting in some form of data governance committee. And I know me even saying the word committee is going to trigger some antibody responses with a lot of people because committees, that must be bad. But I don't know any other way to do it, right? When you're talking about collaborating on rules for data that everybody needs in order to run their business, I don't know another way to do it. So, short answer is what you're talking about are data governance committees ultimately. Ultimately. The right way to do it is to have that committee be owned, shared, aligned organizationally. Those committees aligned on the business side with IT representation, right? With people from IT being there, making sure the feasibility studies and helping make sure that IT can support what the business wants to do from a rule perspective. Where you would potentially have some kind of lead steward from an IT perspective who knows systems, who knows integration points, who knows data flows and the architecture. But ultimately, data governance committee should, in a perfect world, live within business units. And the only way you're going to do that, by the way, the only way you're ever going to convince the business to invest in that stuff is to show the value that I was talking about before. It's only going to be the only way. Otherwise, what you see and what I've seen a zillion times is some edict will come from above. We need to do data governance. Let's form a committee, and it lasts for about six to eight months. And then the director who was appointed to go to those meetings, stops going, tells their manager to go on their behalf. And herein starts the data governance death spiral.

Juan Sequeda: I wonder how many people listening have gone through that or seen that exact scenario that you described.

Malcolm Hawker: Way too many times, I'm sure. Unfortunately.

Juan Sequeda: All right. Malcolm, this has been... We can keep talking. We're still have a couple more things to go do, but let's go through our lightning round which is presented by data.world. I'm going to kick it off. Question number one, is MDM a part of data governance?

Malcolm Hawker: Yes.

Juan Sequeda: All right.

Malcolm Hawker: It's a lightning round. I assume single word can.

Juan Sequeda: Yeah. inaudible

Malcolm Hawker: Yes, it is. You can do governance without MDM but you can't do MDM without governance.

Juan Sequeda: All right.

Tim Gasper: Second question. You've mentioned data mesh a couple of times, and I got the sense that when you had to say it, it made you flinch a little bit. Does data mesh include some concept around MDM in its framework based on what you know? Or do you feel like it excludes it?

Malcolm Hawker: Based on what I've read, it necessarily has to. Although the word MDM is never used in Zhamak's book. What's described, what I read and this may be just me being an MDM hammer and assuming everything is an MDM nail, and I recognize that I have some bias there because MDM pays my mortgage. But I assume that it necessarily has to be. I've asked Zhamak in a couple of different environments, " How do you solve for cross- functional uses of data? How do you resolve differences in data definitions or quality standards that may exist between report A and report B across two different functions? How do you resolve those?" The answer that I hear back is something that sounds an awful lot like MDM.

Tim Gasper: That part of the diagram, that's the umbrella on top. The standards and the interoperability.

Malcolm Hawker: Right.

Tim Gasper: It's like, " Hey, that feels a lot like MDM," right?

Malcolm Hawker: And it's funny. When I learned Zhamak was going off to do her own thing... What's the name of her new term?

Juan Sequeda: Next data.

Malcolm Hawker: Next data, yeah. When I heard that she was going off in doing that, and I assumed that it was going to be some equivalent of a semantic layer to address some of the cross- functional limitations and some of the complexities that arise through cross- functional uses of data, that's what I thought that she would be working on. So, I'm excited to see what it's actually going to be.

Juan Sequeda: All right, next-

Malcolm Hawker: And by the way, the answer to the last question applies to the data fabric as well. The data fabric requires some sort of magic logic layer that is this combination of semantics, AI, ML, automagic smart data integration, fancy integrations, MDM data governance. That is just this amorphous blob of hand waves right now. And by the way, I'm a huge believer in data fabric and I think that there could be something there. I believe that data, we can get to a point where technologies can allow data to inform its own classification and use. That's my definition of the data fabric where data can inform its own classification and use. I think that we can get there but we got a ways to go, for sure. And a lot of it has to do with that layer that is doing integrations, that is investigating active metadata to understand when transactions are correct or when they failed, and all these other things that data fabric needs to do. I'm a believer, but we get a long way to go before that technology is mature enough.

Juan Sequeda: Next question, this is... Let's see. Will MDM as a tool or technology go away because it gets embedded in some other tools?

Malcolm Hawker: Yeah. Let's get back to the previous mini rant about the data fabric, right? In a future world, 10 plus years down the road, I think that MDM as a software could look very different but you're still going to need something that manages some form of shared business and governance rules related to that data, right? The short answer here is no, it's not going to go away as long as we recognize the truth is a contextually- bound phenomenon. If we recognize that and if we also agree that an enterprise view of anything is its own version of a truth, then you need to be able to reconcile the view of the CEO and the view at those functional levels. And how you do that requires business logic to be maintained, whether that logic is being driven and managed by some sort of AI bot or whether it's being managed by somebody configuring a rule into an MDM platform. That need is never going to go away.

Tim Gasper: I like that. That's an interesting view. I also like your comment that, " An enterprise view of something is its own truth." I think that is actually a profound observation. People think that the finding of the truth, it's actually a truth in and of itself. All right, last lightning round question for you. You talked about shared data management, SDM. Is that the replacement for MDM?

Malcolm Hawker: Thanks for coming to tie it back, Tim, and for coming back. One of the great things about LinkedIn is that you can still have really productive and professional conversations about really hard things. I had come up in my head... I've been trying to figure out, " Okay, if it's not master data, what is it?" And by the way, the reaction here for master data is... I don't like changing words, right? I don't like inventing new words for old things. I will fight about data observability being a new thing because I don't think it is. But we create a new word there because we like to create new words, because we like to sell things as vendors. I don't want to create new words, but when it comes to MDM, there are people who associate the use of the word master with darker times in our history. And it's not for me and people in my definite demographic to say whether that's right or that's wrong. It just it's to acknowledge it. And the question then becomes, " Okay, is that something that needs to facilitate a change to the name?" I don't know, but I asked the question on LinkedIn and the answers have been pretty interesting. I came up with the idea that MDM should be replaced by shared data, data sharing. Because if you look at the definition of MDM whether it's Gartner's definition, Forster's definition, anybody's definition, data sharing is intrinsic to that definition. But what I've found in the responses there has been really, really great and just wonderful, educated, thoughtful responses on LinkedIn. What I figured out was that all master data is shared data, but all shared data is not master data. And that's a hole in the logic. It should be able to go both ways. So whatever we replace it with, if there is something to replace it with, it needs to be able to go both ways. I don't know what the answer is. Maybe we stay with master data. Maybe it's innocuous enough. I don't know, but I do know that the room over here to my right is not my master bedroom. It's my primary bedroom.

Tim Gasper: There you go. I think it's a great opportunity to think about how the language could change here because I think it is outdated and outmoded, right? And I think that I love the idea of shared data, I think that's a great concept. And hopefully, that conversation continues with those who are listening. And also, you know what? Data mesh is so 2022. It's time for... What's the hot phrase of 2023? I love words. Let's get new words.

Malcolm Hawker: What's the hot phrase of 2023?

Tim Gasper: Yeah.

Malcolm Hawker: Making new words? Oh gosh. I don't know. This may be my kryptonite.

Tim Gasper: Shared data sounds like a good candidate.

Malcolm Hawker: I love it, man. Shared data, yeah.

Tim Gasper: Or maybe it's automagical amorphous handwaving blob as somebody on LinkedIn here say.

Malcolm Hawker: Automagic automorph-

Tim Gasper: They want to buy that.

Malcolm Hawker: Yes, handwaving data fabric semantic layer or data mesh semantic layer. I don't know. I'm bullish on data sharing. I have been giving presentations recently on how to enable data sharing through blockchain, and blockchain has come out of favor over the last couple of years. And I think you can blame saying Bankman freed and other forces partially for that. But I don't think it's going away. I think that blockchain will come roaring back at the end of this year as we approach another having cycle in Bitcoin and if people are... Crypto people don't know exactly what I just said, but most probably won't. I think there's a place for blockchain in the future, so I think blockchain may be the kind of the phrase resurrected in 2020.

Juan Sequeda: I wonder when you'll do an episode on blockchain and then... Okay.

Malcolm Hawker: Let's do it.

Juan Sequeda: One day, we'll see.

Tim Gasper: I can't believe we haven't yet. inaudible

Juan Sequeda: I know. We'll probably have inaudible. All right, let's go. Tim, take us away with your takeaways or idea.

Tim Gasper: All right. Malcolm, you said MDM is not dead but the idea of a single source of truth may be dead, right? When you force a single source-

Malcolm Hawker: Single source is alive. Single version, source of version.

Tim Gasper: Ah, single version of the truth. But the idea of a single version of the truth may be dead. And when you're forcing this single version of the truth, it forces some unnatural things. And really, MDM is people, process, and technology to maximize the value of shared data assets.

Malcolm Hawker: Yep.

Tim Gasper: I thought that was a really great summarization there. Is MDM fancy data integration? Yeah, you can't just relegate it to the plumbing aspects. It's really got to be broader. It's the consistent rules of the road at multiple levels. Context matters. There's a truth that is contextual for that given context and when you move from the single version of the truth to context centricity, you have multiple sets of rules. Companies consistently have a lack of sufficient focus on governance, and that's a big aspect here. You went through the history of MDM and really gave us a nice foundation on thinking about why we got here, why we have this obsession with getting to that single customer table, that single product table. But really, the reality is more complicated than that. When you're really approaching decentralization, don't become too obsessed with boiling the ocean because that historical obsession can lead you to, " Hey, I got to boil the ocean." Take as much of an MVP approach as possible. I thought that was really great advice. Juan, what about you? What were your big takeaways?

Juan Sequeda: A couple here is I love the whole... We got to stop the flow of garbage in, right? MDM is everywhere, so even if you're going to add a new record like inaudible system today. They're already checking into some MDM system to make sure it does this. Do we need to have a new record? This is already there, right? And the whole, we cannot expect the magic wand just dump this into a Snowflake. It's just going to go work out. We're just repeating ourselves, like dump it into Hadoop from whatever. You also said, " You have to earn the right to ask fields to be required. Earn the right to go ask the business to change the ways of doing. Be humble about this. Don't just barge into the office and tell them to change their things, especially when they've been doing things already great. They've been hitting all their numbers." That's a really, really important observation there. Then on the data ops, data ownership we're talking about, it's a collaborative exercise. Maybe you said something... Another very valuable thing here is when the moment you create a join, you are in a way creating a rule saying, " I'm going to combine these two different tables and these two different tables can come from different places. I may have different more contexts around that stuff." By joining that, you are already enforcing some set of rules. What are those rules? Who are these people who are behind all that stuff? And it's convenient to have an owner but if data crosses so many boundaries, you can't be accountable for things that you don't control. This is why ownership is really collaborative process and you want to have the process experts, the domain experts, the data experts. Yeah, we don't like the word committee but let's be honest, you want to have some sort of a committee, a meetings or whatever where they're all happy to collaborate and IT is their representation because it's very cross- functional. All right. How did we do? Anything we missed?

Malcolm Hawker: That was awesome.

Juan Sequeda: All right. See, this was you. We're just paying attention to that.

Malcolm Hawker: That was awesome. Nailed it.

Juan Sequeda: All right. To wrap up, back to you for three questions. One, what's your advice? Two, who should we invite next? And three, what resources do you follow? People, blogs, conferences.

Malcolm Hawker: The one nugget of advice, don't boil the ocean. Take an MVP/ agile outcome- driven approach to anything you want to do. That includes implementing a data catalog, implementing a data governance tool, implementing... And even an integration tool. Just be outcome- driven, outcome- driven, outcome- driven. And if you cannot explain what you're doing in business terms, meaning increased revenue, decreased cost or mitigated risk, you need to step back. You need to step back and be able to answer that question in a way that the business cares about. That's number one. Who to invite next? I'm struggling with this one. Have you had inaudible?

Juan Sequeda: Yep.

Malcolm Hawker: Okay. Because I'm sure you've had everybody on. What about a blockchain expert? I will keep it generic there. I think you should have somebody who is a blockchain expert to speak about the advances that are happening in blockchain and how blockchain could be used to solve for data management use cases.

Juan Sequeda: Okay. That's a nice-

Malcolm Hawker: I think there's something there. Resources, boy oh boy. There's no shortage of online resources, right? There's great podcasts like yours. There's so many data management podcasts. I live and breathed on LinkedIn. And honestly, it's great and it's very much a community. It's very much you get what you put in, you get out. If you're not contributing and if you're not active in community and you're not providing feedback and insights, then you're not going to get that much out of it. But if you're actively participating, LinkedIn is fantastic. I am prone to be reading about things at higher levels. So, I love books about macroeconomics. Two that really stick out to me is... One is called The End of the World Is... The end of the world as we know it and it's not... Anyway, the guy's name is Peter Zeihan. He's a demographer. He speaks about the ending of globalization. Reading a book right now from Ray Dalio on global currencies and the rise and fall of empires related to currency management and currency manipulation. I love to up- level it. When I'm not talking about data and governance and catalogs and quality, I love to up- level it to higher level things. Peter Zeihan's book is... I can't believe I'm forgetting the name, but it's fantastic. It's about the demise of globalization and the impacts that will have on your business, things like re- shoring and bringing production capabilities back. I would definitely, absolutely recommend Peter Zeihan's book.

Juan Sequeda: These are phenomenal recommendations. Thank you so much. All right, before we say goodbye, just quick reminder. Next week, we have Jeff Jonas, who actually we were talking about him already. He's a former IBM fellow. He's a CEO of Sensing and just one of the world's experts on entity resolution. We're going to have a phenomenal conversation next week. And with that, Malcolm, thank you so much. And as always, thanks to data.world who lets us do this every Wednesday, have some drinks and go chat about data. Malcolm, cheers and see you soon.

Malcolm Hawker: Cheer. Thanks guys. I appreciate it.

Speaker 1: This is Catalog & Cocktails. A special thanks to data.world for supporting the show, Karli Burghoff for producing, Jon Loyens and Bryon Jacob for the show music. And thank you to the entire Catalog & Cocktails fan base. Don't forget to subscribe, read and review, wherever you're listening to your podcast.