 Hello and welcome, my name is Shannon Kemp and I'm the Executive Editor for Data Diversity. We would like to thank you for joining today's Data Diversity Webinar, Data Governance Strategies. The latest installment in a monthly series called Data Ed Online with Dr. Peter Akin brought to you in partnership with Data Blueprint. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. If you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the upper right for that feature. For questions, we will be collecting them by the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share our highlights or questions by Twitter using hashtag Data Ed. To answer the most commonly asked questions, as always, we will send a follow-up email to all registrants within two business days containing links to the slides. And yes, the other question we always get is we are recording and we'll likewise send a link to the recording of this session, as well as any additional information requested throughout the webinar. Now let me introduce to you our speaker for today, Dr. Peter Akin. Peter is an internationally recognized data management thought leader. Many of you already know him or have seen him at conferences worldwide. He has more than 30 years experience and has received many awards for his outstanding contributions to the profession. Peter is also the founding director of Data Blueprint, and he has written dozens of articles and eight books. Most recent is Monetizing Data Management. Peter is experienced with more than 500 data management practices in 20 countries and consistently named as a top data management expert. Some of the most important and largest organizations in the world have sought out his and Data Blueprint's expertise. Peter has spent multi-year immersions with groups such as the U.S. Department of Defense, Nokia, Wells Fargo, and the Commonwealth of Virginia and Walmart. He often appears at conferences and is constantly traveling. Peter, where are you today? Hello, Shannon. I'm on my way to the airport today, but I'm stopping off at a local Richmond, Virginia company, and I'm meeting with the data governance group here. So it's a pleasure to see everybody, and welcome everybody here. But of course, I'm on my way to see you. We're all gathering in San Diego next week for the big annual data governance, excuse me, Enterprise Data World Conference. I get them all confused occasionally. So today, we're going to talk about our strategies around data governance. And this is really geared towards helping people kind of take a step back. Believe it or not, we've been doing data governance long enough now that we actually can see people rebooting their efforts. So they've tried it for a while, sometimes it worked, sometimes it didn't. Or they think they're doing well, but they want to know what they can do better with the next round of it on that. So that's what really we're gearing towards on this. Now, as data management professionals, we believe that data is the most powerful and yet underutilized and poorly managed organizational data asset that exists. Data is in fact our only non-deflatable, non-degrading, durable strategic asset. And what that means is that people tend to think of it and say, oh, good, and if you Google this phrase, you'll see that data actually wins when it's compared to these other assets. But too many people still don't have a real good idea, and I'm just back from a trip to Saudi Arabia where they really like this phrase, data is the new oil. If you Google that, there are five million hits that you'll get on it. The problem is we don't think about what happens to the oil after we use it. We put it in our cars and it goes. That's good. I like to change it a little bit and say data is the new soil. So just change one letter, but you plant stuff in it and it will grow. And of course, the Saudis would thoroughly about this. By the way, trick question, the Saudis import sand into Saudi Arabia. Why? We'll come back to that. On the other hand, if it's chocolate you want, that's okay too. Whatever you can do to get people to pay attention to it, we're real happy because we do feel that it is an underrepresented asset. And collectively then what we're trying to do is get everybody to have stronger data management capabilities within their organization to provide solutions that their organization is ready to embrace. Again, one of the pieces that I like to outline at this point is to say, have you ever given a 16-year-old kid that just has a month of driving experience the keys to a Tesla? And the answer is no. Nobody in their right mind would do that because it's not a good match for where the technology is. And finally, reestablish the partnerships that exist. I see data people as being a bridge between where the business is and where IT is. And oftentimes in organizations they're at loggerheads. We'd like to help fix that and come back to it the other way around. So let's talk a little bit about what managing data with guidance is. And I'll pick on our friends at Target. Anybody here in the room have to change their charge card out because of Target? A couple of heads nodding here and there. It's usually about a third of each room that had to do it. Now that wasn't managing data with guidance very well. They kind of looked at it as a commodity. And I'm not going to dwell on Target. I've got another whole program that I do that goes into the origins of that in real depth. But we'll put up an even more provocative issue. Most people are familiar with Astrid Madison, even if they don't want to admit it. And we'll forget about the fact that there were only 12,000 purported women on the site and 47 million males. And that one quarter of the city of Ottawa, Canada, was in fact registered there. Ottawa being the Washington D.C. of Canada, if you can imagine such a thing. But let's add one more piece to the mix. And that is a third breach that we've had that's called the OPM, Office of Personnel Management. Now the Office of Personnel Management keeps track of people who have a clearance in the United States, people who are entrusted with government secrets, people who we kind of like to, you know, keep care of their data. My point here is that each of these were problematic on their own, but collectively, if we have somebody that has a security clearance who happened to be registered on Astrid Madison, and if you go to the Target data breach and see that you can now have their daily habits because Target knew what your daily commute was, what websites you visited, what stores you visited in addition to Target, wow, this is the biggest combination threat to national security that we've ever had. And the problem is we weren't managing that data very well. In fact, I can go a step further than that and say that the data that was stored in the OPM breach should never have been put online in the first place. And the only reason it was was because the person who made the decision to do that was unqualified. Now that happened in the time when we didn't know what a data governance professional was. Again, I'm looking at a room of them here, and I know there's several hundred of you out there online that are also qualified data governance professionals. Before, we didn't know, but that data that was stuck in the OPM has personal data, okay? There are copies of famous people's, we call it SF-16 forms that are out there where you've disclosed things that you've done in the past. The problem is now you're subject to blackmail. And of course, we don't want to have that. This information never should have been put online, and the person who made the decision to put it online was fundamentally unqualified to make that particular decision. Now as a result, what happened with some Target instances that their CIO resigned abruptly, and then the CEO left, and finally after that, they came after the board of directors. And when the board of directors gets targeted by people, forgive the pun there for Target, right, they start to realize that the decisions they're either making or not making have some very significant consequences. So we're starting to get awareness of this, and if it's at the board of directors level, that's actually a huge step force. So why is game governance important? Well, it costs organizations millions each year in productivity, in redundant siloed efforts, in poorly thought out hardware and software purchases in delayed decision making using inadequate information. I had lunch today with a fellow who works for a manufacturing company around here, and he said, I need a faster server. And we looked at what he was looking at, and it would help him to have a faster server. Let's not get it wrong. But the real problem is not his server, it's the fact that he spends 80% of his time munging the data. There's a very technical term for you. Munging the data just means we're trying to get it into a format where we can actually make use of it in that context. And if we're going to spend 80% of our time munging the data, faster server is only part of the solution. The rest of it goes into other components. What this really means is that organizations are enlarging reactive instead of proactive postures. And finally, there's not an organization I've worked with over the years that I couldn't cut 20% to 40% of their IT budgets through improved data management practices. And when you look at the size of IT budgets today, that's something that people take an interest in. Now I'll put this one out there, too. I've always asked people if they would let me work on a percentage, because I'd just like to take a little tiny amount of, say, a penny for every dollar, and we'll actually still all be very, very happy at this. The real problem, though, is that because of the relative newness of our profession, we've really seen only some companies get significant savings out of this. So one in 10 organizations actually achieves a positive return on investment. 30%, as I'm showing here, achieves some return on their investment, and 70% of the organizations achieve little or no return on investment in this area, which is sad, because these are good people trying to do the right things, but it is very, very difficult to do. Now, you'll notice that data governance sits at the heart of our data management body of knowledge or abbreviating it with our really bad shorthand, the dimbok. We can use some help with marketing. Anybody who wants to volunteer, we will take your help gladly in that. But the key, of course, being centered to this, it does say that it draws together all the other disciplines around this. By the way, I spoke to the newness of the profession. This dimbok diagram has only been around since 2009. So before that, when people were talking about data management, people sort of had this idea that it was like the elephant, depending on what part of the elephant you feel, in the dark, okay, you're going to come away with a different perspective on it. So Damon, a national organization I was president of for a couple of years, I'm now a past president, published this standard out there that says this is what it means to be a data manager in today's environment. And this is the IPO diagram. IPO is Input Process Output Diagram. I'm not going to go through it in detail, but it does serve as a map of what we're trying to cover. The inputs, obviously, the suppliers, the participants. We've got some very specific activities that we'll talk about, some tool sets down underneath, and then the outputs are deliverables that have to go to consumers. And of course, we would like to have some measures around this as well, because if we don't measure it, we can't tell whether we're doing it better or worse than before. Now, the overview of what we're going to talk about today is to start with strategy. If we don't start with strategy, then we're kind of directionless. The Chinese have a saying, if you don't know where you're going, any road will take you there. It's kind of important. But everybody understands that organizations have a strategy. Therefore, the IT department has a strategy, and data department should also have a strategy around that. Then we'll look at what strategy involves, which is choosing. Strategy is, fundamentally, a choice-oriented activity. And we'll see how that relates to data governance. And again, I'll give a couple of definitions. The definitions, quite frankly, up front aren't terrific. We'll get to those. It is important, though, to figure out not what data governance is, but what it means to your organization at this point in time. And that's a much more relevant question, because organizations look at things in the dictionary and say, yes, that's the answer, whatever it is. But that doesn't necessarily mean they understand how it applies to your organization. And that's really what we're going to talk about, is making it that way and coming up with what are the requirements for effective data governance. We'll look at some specific components. And I like to start out with frameworks in that. There's many to choose from. The idea is that this can help you jumpstart your efforts into there. We'll look at some very specific building blocks and some checklists that will move us towards that. And we'll talk about some worse practices as well. The way that you make this real, however, for organizations is with stories. And it sounds trite, but if you haven't got something that people can relate to in their day-to-day activities, they kind of look at what you're doing in data governance as somebody else's problem. And so that's what we're going to try to do, is bring that to home with a couple of quick stories. As always with these presentations, I have about 100 slides and here's a bunch of reference slides that I will go through very quickly. And again, those are for your reference to take away and hopefully inspire some other conversations of their organization. So when you look at strategy, strategy is always focused on the why. And Simon Sinek did a great TED talk on this, where he says people are pretty good at describing what. And we understand what we do and how we do it. The how is another part we're okay at. We're not as good at what as we are, but we're not really good at doing why. So he's actually taken this one 12-minute TED talk and expanded it into a couple of books and a speaking tour and all sorts of other things. It's well worthwhile to get on the web and watch his little inspirational talk that he has about why. And why then relates us back to strategy. Strategy is a relatively new term. Until about 1950, nobody used the word strategy. And it was primarily in a military context. But a good definition that we like is a pattern in a stream of decisions. Notice that's a pretty easy thing to get. So for example, UPS, and I'll just pick on them for a second because most people know the story. You'll never see a UPS driver do what when they're driving. That's just turn less, exactly right. So not that it's a bad thing, but the preference for UPS is to make right-hand turns because that helps them with strategy, safety, economy, and all sorts of other navigational aids. And for UPS drivers, they just get this pattern in a stream of decisions. So let's look at a specific example on this. And this is how do I beat somebody else when they are bigger than us? Now, the context here is the blue arrow is Napoleon as he's trying to fight against the British in the red and the Prussians in the black. You'll notice their forces were much larger than his. And this idea, how do I beat them, was answered by divide and conquer. So how does that work? Well, I'll narrate over the top of it here. This is an old film that you can go out, pick up on the web here. And you can see, again, Napoleon fighting against the British and the Prussians here. Now, what he's attempting to do is say, how do I win against a larger force? Well, the idea is, turn that off. The idea is, of course, I can't. There's no way that you can go beat up the bigger guy on the bat. That'll feel no better to do that. But what Napoleon did understand was, when you hit an army hard, the army tends to retreat in one direction. And the answer is, along their supply lines. So you'll notice the Prussian, sorry, in black over there, were treated towards Leeds and the British were supplied out of Ostend. So when he hit them in the middle, they each were treated towards their supply lines. By doing that, they were divided and his troops were then quickly hit the Prussians and then turn around and hit the British. This is simple. This is something that troops can understand and follow. Again, a pattern in a stream of decisions. So a wonderful little example of that, and that may be a little hard for some people in terms of, wow, war examples and things like that. So everybody knows Wayne Gretzky. What is Wayne Gretzky's definition of strategy? He escapes to where he thinks the puck will be. After all, if you're chasing the puck around the ice rink, what's going to happen? You're always going to be playing catch-up. You will never be relevant in that. So he would go stand by the goal and wait for somebody to serve it to him. Boom. He's the highest-going player out there in that. So we've got an idea of strategy. Strategy should be simple enough that everybody in the entire organization gets it. By the way, I'll give you one more piece of strategy here. Walmart's strategy is something you all know. It's four words. Every day, low price. Wow. Strategy? Yes. Every Walmart associate knows that. Every Walmart supplier knows it. And every customer actually knows it, too. Now, whether it's the right strategy for them or not, that's up to their corporate governance piece. And of course, that's what corporate governance is about. We would never use the word governance without making sure that corporately we were governed. It's one of the things that organizations get in trouble occasionally about. So pay attention to corporate governance. If we're going to have corporate governance, we also need IT governance. We're not going to just buy things willy-villy in IT and have them go in. And it's pretty straightforward in terms of IT. We're going to acquire things in our organization that help further our strategy, whatever our corporate strategy is. So now let's look at why this can become problematic at an IT project level. And the reason for that is because many IT organizations are chopped up into smaller groups. Again, they have a set of goals and objectives that are transmitted to the groups. They say, this is our strategy. But if you've ever played the game of telephone, you know that when you start at one end of the room, the message doesn't always end up coming through the other side. And consequently, IT projects don't always well reflect strategy for that same reason. So when we look across organizations, we find out that if the strategy at the project level exists, these singular philosophies aren't perceived as such at the project level. And that becomes problematic where organizations actually get very confused. I worked for one organization that had actually several hundred IT projects going on at the same time. And I said, wow, how do you know they're all focused on strategy? I said, oh, because we're really good. I said, well, that's a good answer, but it probably, I'm going to guess, had a lot of variance, a little bit of wobble in that organization as far as where that all came out. So most people then start out with organizational strategy and then an IT strategy, and think the data strategy should be derived from that. And that makes sense, and I'd rather have that than nothing. But if we think about it, it's not really the right way to do it. So let me just give you a quick story. At Data Blueprint, we get a lot of calls. We call them over-to-transom calls. Just somebody picks up the phone from the website and says, hey, can you come talk to us about this? And we want you to develop a data strategy for us. So we said, well, we'd be happy to do so. What is your IT or your business strategy? And they said, we don't know. We don't care. It's just a deliverable. We need to put something on the shelf. So just tell us how much it is. Give us the binder and we'll call it done. We don't like to work on those kind of projects. It's just not really a lot of value added. And so we told them to call us back and they actually got off the phone and within about six weeks, the IT director called us back and said, hey, I understand you talked to our data people. They didn't want to tell you what our IT strategy was. I'll do it if you sign a nondisclosure agreement. Sure, no problem. Their IT strategy was SAP. Now, I don't mean to tick on SAP. SAP is a fine piece of software, but it is not an IT strategy. And so we again said, no, sorry, wrong answer. Go back and try again. Literally got a call another six weeks later from the monitoring director of the organization who said, okay, more nondisclosures. Our business strategy is hell. Once again, you know, as you can imagine, that didn't turn out to be an engagement that we ended up engaging them on. And we said, you know, you need to do a little better than that in order to do it. But what really happened is that if you derive your data strategy from your IT strategy, you've already seen that strategy can get confused at the IT project level. So this is wrong. And this is the way I'd prefer to see it done. And in fact, I'd actually like to see a dependency thrown in here too. And that the IT strategy is developed before the, excuse me, the data strategy is developed before the IT strategy. It's okay to do them concurrently, but what happens most of the time is that they are developed sequentially. IT strategy and then data strategy, don't get me wrong, I'd rather have a data strategy than not have a data strategy. But I'd really like to see this data strategy derived from the business objectives that need to occur there. Rather than from the IT objectives, it's much easier to tie the business pieces back into that strategy. So you'll end up with this. This is a great diagram that my colleague John Lattley put together, which is what he calls the alignment gap. When you look at organizations, and he's got a great tutorial that he does on this that you can see some time online, where he'll go through the K-1 filings, for example, of the organization, and see what the strategic objectives are. That's one of the things you tell the Securities and Exchange Commission how to do. And then you look at the IT projects. It's very hard to match the IT projects and the actual achievement of the objectives. How is an e-mail system actually going to help the organizational strategy unless communication is a huge component of what it is that you do? So it's an area that we see a lot of organizations could do better in. I've got a couple of supplemental slides here. I'm not going to dive into them, but the Capability and Maturity Model People and the PMMI Institute have put together a couple of these things for you as well to take a look at. So strategy is about making difficult choices. Let's look now at a couple of definitions of data governance. The first one out here is not terribly exciting. Formal orchestration of people, process and technology to enable organizations to develop data as an asset. I'm not going to read all of these because the problem is, again, we get down to this, and even our NIMBOK exercise, the very last one, which is the one that we in DAMA officially own, the exercise of authority and control over the management of data assets. Okay, good. But when you're on an elevator and the boss looks over at you and says, oh, Angie, you work for me. You do what for me, right? You got 20 floors to make a good elevator pitch or else what happens? They might remember Angie, and that's about it, right? Does Angie have a good answer or a bad answer? So I like to instead do it a little bit differently, and I'm going to give you a dill bird on this as well. I don't usually do dill birds on the webinar, but this one's so good. The committee, we're going to call it the Data Governance Committee, just add that in there. Decided that the File Naming Convention was the date and the order of months, a year, wrong, right away. And then a space in the temperature of the airport and a half size of the nearest squirrel. To be perfectly honest, it was a long meeting, and we probably didn't do our best work towards the end. If you can't figure out what you're doing in your Data Governance Meeting, it's already off track, right? There's got to be a purpose that you're trying to do. So I like to say Data Governance is managing data with guidance. After all, you wouldn't want to manage data without guidance. It's a great place to start. Now, the question then becomes, what type of guidance? Well, that's where you as the professionals come into play. You understand your organization, and you're the best people that can craft the organizational definition. Managing data with guidance is a great place to start. But what it really is, is getting some individuals, do some social engineering, get some individuals who are influential, okay, whose opinion matters. To form a body, you need to have a charter of some sort, where you get somebody to sign off on something, who will evangelize, advocate, not dictate, rule, and enforce, increasing the scope and rigor of data-centric development practices. That's really what it comes down to. Now, I can say this, I'm in Richmond, and it's a well-known story that Capital One has overdone their Data Governance. Remember that story, patients? You know, they went a little too far out on one. So when big governance people come into the room, they go, ooh, you guys slow us down, and they make them leave. They were doing their Data Governance. It's a good thing. They got overly bureaucratic, overly heavy-handed with the process, and it turned out not to be the best thing. The most important aspect of all this is to use things that make sense to people. So we worked for a healthcare company at one point, and they had this great phrase. They said, getting access to data around here is like that Catherine Zeta-Jones scene, where she's having to get through all those lasers. You may or may not remember the movie. I'll do it one more time just so you can see it. She's practicing stealing something. She's getting to a little set of laser beams on it. But to get the metaphor, this was what they felt getting data was like in this organization. So it made sense for them to adopt this as a model for their organization, and the thing that they definitely wanted to solve. This was their problem of how they were going to address it. And their first priority for Data Governance was getting people data faster and easier. Again, it's going to be different for every organization, and that's where you all are the best qualified individuals in order to do this. So I mentioned the framework before. This is the Data Governance Framework from the DIMMoc here. We've already looked at this one. It's a really good idea to start practicing how that works, to have the elevator speech in mind, okay? Whether it's helping organizations make decisions faster, whether it's doing a quality type of an exercise, or an inventory, or optimizing the data performance, doing security, okay? Even strategy formulation. All of these come into play. The question is, what's going to make the most sense for your organization at this point in time? And that should drive your priorities on this. Now, we get a lot of questions at this point that say, what's the difference between Data Governance and Data Management? Governance is a policy level guidance. General guidelines and directions. People shouldn't have to read 100 pages to figure out what Data Governance is all about. For example, if we say all information not marked public should be considered confidential, then you look at a piece of information. If it doesn't say public, you call it confidential. Easy rules, easy choices. Data Management, then, is the business function of planning and controlling and delivering those data assets to the knowledge workers that need them. So again, solving a specific challenge to do the business. The governance may do the prioritization of the projects. The management function may go and actually do the implementation on it. So if we look at this and say, well, what does that mean? We're looking at strategies. We're looking at regulatory compliance in many organizations. That's the most important driver that they have. They may sponsor the type of delivery and access that they're doing. They may resolve issues where people are having problems with it and just generally promoting the value of data assets. These are supplemental here. Again, I won't read through them all, but you can see the various deliverables and things that come together. The key, of course, is team activity. So we're definitely going to have a lot of people doing this if you're doing it all by yourself. Good luck. Many organizations have found some tools are extremely helpful, and this is a really good way to lean on them where it's appropriate for the organization. So lots of tools, techniques, practices in place to do that. I mentioned the frameworks here. This is actually a good place to take a look at it. Now, the way we do this in data governance is we assess the context on the left-hand side of this diagram, define some sort of a roadmap that says, here are the first three things that we're going to do. Then we secure some sort of executive mandate because after all, if you're doing this without any executive support, it's just harder and more difficult and takes longer. We want to then assign some people who are in charge. Typically, these have been called data stewards. Now, I'm going to differentiate here. Many people like to think of data owners. I like process owners. That's a really good business term. But data stewards are actually people who, if you look outside and say, okay, we're going to be a steward of the land, it means leave nothing but footprints if you're a Boy Scalpo. That was one of the things we were taught. Make it better than it was, or at least no worse for having used it. You're protecting the asset, the shared asset in this case for everybody else. And on the right-hand side of this, you can either rinse and repeat. Find something. Go out and do it. Celebrate those results and make sure everybody understands them. Every data governance organization needs to have an internal website that says, what have I done for you lately? Because you know the question will be asked in reverse. I know you did something wonderful two years ago, but what have you done for me lately? You've got a website up there. Somebody will say, go look at their website and see what it is they've done. It doesn't have to be elaborate. It doesn't have to be a lot of stuff. They ask you to do it. The last thing you want to do is a big cattle call to say, quick, go add some value and show what we've done. Keep this going because people sit there on web hours just like this, where I'm probably in the corner of many people's screens and they're trying to get their inbox cleaned up and things, and they'll surf around on the web and find this stuff and actually use the things that are out there in terms of how to do it. Now, I live locally here. I live on Montpelier, and this is a picture of my barn when I was building it. The bank let me have this much money. It was enough to build a foundation, and then they told me to stop, and they did a foundation inspection before they would let me have any more money because they wanted to make sure that what I built was in fact going to be supportable for the organization. This is one area that data governance can play a huge role because this equivalent does not exist in IT. We don't have a stop process that says, let's make sure we have a good foundation before we go forward. Again, the organization that said that their strategy, their business strategy was analytics and their IT strategy was FAP, is in fact doing some success. If I told you what group it was, you'd go, oh, sure, I know those guys, but not nearly as much as they could if they had actually put in a proper foundation in order to do it. And these governance frameworks give you the same kind of thing. It's a system, and it's seven pictures here, so I'm making it a little bit more complex than it needs to be, but it's a way of organizing your thinking around it and helping you to make priorities and assessing your progress in order to do this. For example, in the example of my barn, when I go in and actually put up the walls next, I'm not going to put the walls up until the foundation is solid. I'm not going to put the walls up until the foundation. First of all, it doesn't make any sense, but second of all, the walls are going to be sitting in mud and they're going to rot, and I'm not going to have as long use out of the walls in order to do that. And oh, by the way, the next one, put the roof on, because if I don't have a roof, everybody and everything gets wet. So again, we understand how to do this. It's just rough general guidance. So that was the first data governance framework here, this Zimbabwe one. It's okay to look at that and see if that works. Here's another one from our colleague Glenn Thomas. Glenn's done a great job. None of these are right, okay? And I'm not going to walk through this, but this is something that your data governance group should sit down and say, okay, first we focus on the mission and then the goals and objectives, the areas of data rules and the formation, decision rights, accountability, controls, stakeholders. I mean, she sequenced it all out, hopefully. What works for you? What doesn't work about that? And the answer is probably some things work and some things don't. Here's another one, our friend Rob Siners' piece. He likes to do this and say, let's start off with the traditional enterprise, strategic tactical and operational level. Let's look at how these pieces work. Again, try it. They're free of charge, right? Nothing to sit around at a brown bag lunch and try out seven or eight of these. Here's the IBM. There's like two IBM examples on here. So they look at governance bodies and their focus here is on data risk. Particularly reasonable to look at, particularly in a regulated business type of an environment. Here's another component from the IBM piece. Again, what do we have? Well, risk, value creation, organizational structures and awareness. Each of these frameworks can be useful to you. If you sit down and spend a few minutes just sort of looking through it. Our friend Joe Duchay down at SAS, they've got a great one for their SAS data governance roles. None of these are correct, but here are seven of them that you can take a look. Believe it or not, the American college personnel at the station has one that's actually kind of useful. They may just look like a ship. I'm not sure why, but you certainly get it, right? So again, things to take a look at. NACIO, which is the National Association of State CIOs, also has ways of going through here. So just take these pieces and look at them and see what works for your organization and what doesn't. The typical thing that's going to be is that there's going to be some sort of decision-making authority. By the way, when I say gain executive approval, one of the things I'd like you to do is put into your data governance chart that the data governance group has veto power over all IT projects. People go, whoa, now you'd be surprised how many executives sign that and don't realize what they're signing. That's not that they're not knowledgeable. They just go, well, that sounds reasonable, right? After all, if we have a great system and we fill it full of garbage, garbage in, garbage out, right? So lots of things go into these. Grab as much as you can on that first piece. It'll at least give you a conversation that you can have around that. So again, here's data governance checklists, four cards that are in there, lots and lots of worst practices that come into this. Again, I'm not going to get through these. These are just supplemental pieces in order to look at this. So let's look at some storytelling in action. This is where I think it becomes really, really helpful. Now, when I was a younger person in the late 1980s, I worked for the Department of Defense and I had the title of the U.S. Department of Defense reverse engineering program manager. So we were actually starting Y2K in the 80s and reverse engineering was considered to be a well-established part of that. So they took us and they sent us to Detroit to go learn from the private sector. That's always the thing you hear in government. Go learn from the private sector. Actually, the proper answer to that is we should all learn from each other. The government does some things really well and we should look at those and the private sector does some things really well with those as well. And again, the conference enterprise data world that I've mentioned a couple of times is one of the primary ways we share those stories. We have awards. We have best practices that we talk about and it gives us a good, solid record of what has happened, what has worked. And it provides tons and tons of opportunity for side conversations for people to have around that. Well, back to our story. So they sent us out to Detroit and they said, go learn from the private sector practices. So we went to visit the automobile industry and one of the things that was fascinating, I brought back an artifact. It was an ad in one of the Detroit papers for 11 CIOs for the transmission division of one of the major car companies. A couple of things wrong with that. Why do you have a CIO over a transmission division? Why do you have 11 of them? The whole nature of being a chief is that you are one singular individual. So we decided that not all the lessons Detroit had were worth taking away, but this was one that we did find was quite useful. When Detroit was putting things together and remember they assembled cars on the assembly line, they had a rule. You needed to attach something to the engine and there's several things that could be attached to an engine, an air conditioning unit, an oil pump, a heater, a generator. All of these things are other parts of your car that make your car go and you need to have these little components that get attached to something that is structurally sound. The frame of the car, the engine of the car. Success was measured by these organizations putting these things on the assembly line and not slowing down the assembly line. Okay. That is a good criteria. Problem was they didn't think about how it was done. So they would end up with 10 different bolts, which meant you had to maintain 10 different wrenches, and if you were a dealer servicing a Detroit car, you had to have 10 different bolt inventories and wrench inventories in each of your dealerships. We get back to the rot piece very quickly, right? Too much stuff. Toyota, on the other hand. We didn't actually travel to Tokyo in order to do this, but we got an updated Halberstam's book that was on this. Went one step further than this. The first time, with the first version, the prototype version of the car, they took a step back and they said, how many of these things can be applied with the same type of bolt? Good idea. Well, the idea was, okay, Detroit puts it on 10 different bolts, 10 different wrenches, 10 different bolt inventories. Of course, you know the number's not 10. And Toyota, same bolt for all assemblies, one bolt inventory and one type of wrench. No, that's not the answer either. We never got to one, but it was never as simple as 10. But if you don't take that step back and look at this and say, what is it that has to be done in order to come up with more standardization? Now, just to give you an idea of the standardization, does anybody remember the programming language ADA? Nope, nobody else. One version. ADA was going to be the one standard programming language to rule them all that we were going to do in the Department of Defense. You could get a waiver if you wanted to do something that was non-ADA, that was the official DOD language. All you had to do was print. ADA didn't have any printing capabilities. By the way, SAP version one also didn't have any printing capabilities. After all, this was the 1990s, we were going to paperless offices, right? No, we're still not there yet. So the idea here is, no, you can't apply a single standard and make all this stuff work. But if you don't take the extra step to look at what's happening in the organization and say how much standardization is appropriate and reasonably easy for us to do in this context, then you will never gain these efficiencies of processing. And if you've ever worked on a car, many of us in here have, there's all sorts of different tools that you need to have. And if we could simplify that process, it would make life easier for everybody. The four strategies about choice. This is one of the more helpful diagrams that Michael Porter ever put together in strategy. With strategy, there really are only two ultimate dimensions that you come down to. You improve your operations or you innovate. Anything else is a theme and variation thereon. And yet what we tend to see is that most organizations sit here in quadrant one with little or no proactive governance around their data. But if the first priority for data governance is increasing efficiency and effectiveness, Walmart certainly pops to mind as excellent best practices, whatever you want to call them, in terms of doing this. Remember, Walmart operates on a 3% margin. That's pretty darn good. So they have become really, really, really good at this aspect of it. If we take the other approach, innovation, again, whether you believe Apple is an innovative company or that they're just innovative without stealing everybody else's ideas and putting them in Apple products, they still get the public credit for being innovative. Now my point here is only this. If we took the Apple people who are really good at innovative and said become efficient and effective, that's not the practices that they have. If we took the Walmart people who are really, really good at being efficient and effective and said become innovative, they're not going to be able to do that either. So what we see in most organizations is they say, let's do all of this at once. And just like Napoleon, we can't do it all at once. We've got to sequence this. And if you go Q1 to Q2 from sort of little or no governance to a increasing effectiveness and efficiency piece, you can use the savings that you have from that to help fund the things that you need up in the innovation place, which is actually kind of nice. You can also start with Quadrant III, but you're going to have to invest more at that point in order to come up with these results. Now again, these strategy diagrams are important, and yet you wouldn't believe how many companies I've gone to where they say, that's okay. We can do it all right away. It's a very difficult process. These people have been practicing efficiency and effectiveness for decades, and these people have been practicing innovation for decades. It's not the same set of skills. So you need to back off and say, what can we do? And by the way, if you have a data strategy, you're in that one in 10 group that I showed you earlier on. Most organizations haven't realized the need to actually come up with this before. So remember I said before, approved IT projects should be part of the data governance charter? There's a reason for that. In most organizations, we start out by looking at what our organizational strategy is, and then we build some projects to implement that strategy. That's a perfectly reasonable way to do it. And the data and the information, though, becomes a tail wagging the dog. It's the leftover part, something else that we have to do. Again, I'll pick on SAP. If I say SAP is the way we're going to implement this particular organization instead of IT projects, that's perfectly fine, but as soon as you say SAP, it sucks all the air out of the conversation and nobody talks about what data SAP needs to have, or whether the SAP data is, in fact, correct. Now, I'm going to tell a story about a company that I worked with in Europe for a couple of years, a really fine organization, very engineering-oriented type of an organization. They did a great job at what they did. And they had an SAP system that was perfectly optimized for their finance group. They had mainly the finance and manufacturing modules in place, and they did a terrific job of it. But anytime anybody else looked at that data, it didn't look right to them because they didn't understand finance and accounting. So they said, oh, the data's not right. And what happened, unfortunately, was that the person in charge of the SAP data said, oh, you think my data's incorrect? Well, you can't have it anymore. I literally threw a black cloak over the SAP data and wouldn't let anybody access it. You're thinking, can we play like adults here? Come on, what's going on? Well, then it became, well, the reason that they're hiding the data is because it's bad. Again, none of these things were helpful. The spiral went down for about three years. And until the person who was in charge of the SAP finance data retired from the organization, the rest of the organization was literally walled off from it. Now, this is a very, very disruptive process, and it makes absolutely no sense in today's environment, and yet I witnessed this firsthand in order to do this. The problem is that when you look at it from this perspective, the IT projects ensure that the data is going to be formed around the application and not around the organizational data requirements. And the processes also are formed narrowly around the application and at very little data reuse is possible. Now, I'll say a word about reuse in here. We've been teaching people for years and years that the reason we use object-oriented technologies is because we can reuse the code. Every one of the measurements, 100% of them, shows we are reusing zero amount of code. It's not happening out there. And if you think about it, if this was code that I have on the screen here in front of you, how would you describe that? Well, if the slide has got the blue and orange and red, that's not very helpful, is it? It's got some words on it, so we can talk about the words, but you know, let's put the words out there. So if I'm looking for a slide that talks about strategy, I might do a word search and come up with it. It's hard. And it's really hard to reuse code. It's not that it's a trivial problem, and we don't do it. It's a very tough problem to do. On the other hand, data are a good thing. Now, let me give you one specific example. There's a hospital system that I worked with. They have a very large ERP, a single system that supported the entire hospital needs. And one of the fields in that system was something called Admit Date. You can imagine people would look at that and go, okay, that's the date you were admitted to the hospital system. Pretty good, right? No, we actually found 11 different definitions used to for Admit Date. Now, that's unfortunate, but more importantly, there was a direct dollar cost that measured tens of millions of dollars that the organization was not able to recoup because of this. I'm seeing some giggles around here. Okay, we'll find that story out after we go offline, right? Point being, it seems like a pretty straightforward thing. Even defining that one field in the database and getting that field to be used correctly is a non-trivial problem. So we need to stop this absolute false hood of saying we're reusing code, and let's focus on what we really want to reuse, which is data around these standard definitions. Now, my point here is this is a natural process. People look at this and go, sure, we're going to use this project and then data and information. Of course, do I want it to do it? Well, a little bit differently. When we create systems or create IT capabilities, it is fundamentally a process of filling a gap. We talk about gap analysis in many, many ways, okay? The IT project will fill this gap in our capabilities that we have, and that's a very appropriate way to talk about it, and we create capabilities to fill that gap. But data is different. Data evolves. Data sticks around for a much longer time and changes more slowly and more gradually than other parts of the organization. Again, even here, if you guys went back and took the 10 major subject areas that you've had here, it's the same 10 subject areas that you've used in the past, et cetera, et cetera. I get your processes have changed. The business world has changed. The products and services that you sell here change, but the data that you have is fundamentally not changed. So the rule should be that data evolution needs to be separated from, it needs to proceed, and it needs to be separate, external from system development activities. The reason for that is because we've taught everybody in college and university that they should use something called the system development lifecycle. And the system development lifecycle is a fine thing for creating IT projects. Remember, IT projects don't share that strategic link. If we want to share things like data across projects, we have to do something that is outside of the system's development lifecycle. And we don't teach you that, therefore, you don't do it. Now, that problem is squarely with the colleges and universities of the world. That's one of the reasons I'm still in college and university because I'm trying to change that from the inside of it. We talk about data-centric development. Again, that's what we're advocating for here as a data governance practice. What it means is that we have an inherently architectural focus in nature, that it extends the practices that we already do pretty well in organizations, but that none of this helps out with the personality-driven issues. Remember the story I told you about the European company whose data owner said, you can't touch the SAP financial data. It's a big, big problem. But we really need to look at some different skills in this area. Again, to be successful in data governance, you're going to have to be a nice person. If you try to approach data governance of a traffic cop, it's not going to work out so well. And it requires extra attention to communication, and there aren't very many professionals that we have in this. So we need and have, in fact, developed a specialist discipline in order to try and address this. And we give you a specific example that comes from my monetizing book. Most organizations are really afraid to put their names on this, but Linda Bevello, who is VP at this particular bank, said, you know, I'm okay to put this particular example out there, so I'm going to tell you the story here. She said, when our organizations transform the data-centric approach, we measure success differently than we did before. Same projects, same process, but with different measures. And she had a big project that she was putting in for her bank, and the IT people came to her and said, we're done, and it's on time. And she said, wow, that's great. You know, who ever heard of an IT project finishing on time in the first place, right? Good deal, right? And she said, how much of the data that we originally planned to get in there was in there? She said, 40%. And she said, oh, let's pretend I don't care whether it's on time or not. How long would it take you to do more of the data? And we worked on it a bit more, and they got 80% of the data in there. But she was able to ascribe $50 million of value to the bank for putting that project. In other words, it was okay for that data to make that project late because she could show $50 million, and of course the calculation is that it cost her less than $50 million to build it. The answer was, heck yes. So she did these really nice articulations, asking if our data is correct, valuing the data more than valuing on time and on budget, valuing correct data as much as it's not more so than the process, and then auditing the data rather than auditing the project documents. Very, very nice articulation. If you want a copy of that book, it's out there on Amazon. You can grab a copy of yourself and take a look at it. So data-centric development is somewhat similar. Only instead of starting out with the IT projects first, we want to start out with the data and information needs of the organization, and then transform that into IT projects because that data will tell you whether or not you need to have this IT project in fact in place. This means that the data is developed from an organization-wide perspective, that the systems that are selected to support that complement the existing organizational process architecture, and we can in fact maximally reuse the data assets that we have in order to do that. So let me tell you a couple of stories here about data governance. But I mentioned before, it's important that you develop these stories because these stories become known in the organizations. So here's a company that, my guess, sells a lot of chocolate. And they tried to do too much IT stuff at the time of year when you sell the most chocolate. That would be the holiday season. Not a good idea. And they blew it. They couldn't deliver five million pounds of chocolate. Okay, that's English pounds, not volume weight pounds. Five million pounds, a lot of money. And we sat down on the postmortem and looked at this, and I kept saying, and that was the chocolate story. And every, I'm back there fairly often, and we'll be sitting around the table and somebody will eventually look at me and say, Peter, this is the chocolate story all over again, right? Like, yep, this organization got that the chocolate story was really bad and they didn't want to make sure that, they wanted to make sure that didn't happen to them. And their method for making sure it didn't happen again was, they're going to do a much better job with data governance, which is going to control the amount of IT change that occurs during key processing times of the year. Most of you are familiar with healthcare.gov, little thing actually, I had a conversation with a colleague this morning about it, and I was just, starters from a governance perspective, we knew this was going to fail before it hit the streets because there were 55, when I say contractors, I don't mean people, there were 55 contracting organizations. That's not good on any project. You've heard of the expression too many cooks boil over off absolutely. And more importantly, six months before launch, we did not have the requirements finalized on this project. No, no, just not good at all. John Johnson, who's head of the Spanish organization, which does a great job of tracking you, thinks anybody who written the system or built a code could not be surprised it didn't work. The real news would have been that it actually did work, given this particular piece. But here's another person who was involved, Gennie Morty Abbott, who did some of the analysis of what went wrong. He said, the system was developed so that if anyone part of the system slowed down, the entire system slowed down, you're like having your car headlight go out and not being able to drive, right? Now, you might risk a ticket driving without a headlight, but you certainly can get home. And in those cases, that is a safer alternative. I'm not advocating driving improperly. Don't get me wrong on that. But there were more pieces of this too. In this project, we had some organizations that were doing what we call big data technologies. Now, it's another whole lecture that I do, another whole webinar. But big data technologies are something that we've been talking about in the management that's gotten a lot of attention to. But big data technologies are not traditional technologies that we access the data using what we consider to be the standard form of SQL. So we had one contractor saying, tell me what SQL to write. And the other contractor going, SQL is not going to help you here. And the system went into production that way. It's like writing half the system in German and half the system in French and expecting people to be able to understand it. Another project we did, we did the Army's data governance program. This was kind of an interesting one. Leveraging culture is an important aspect of it. What strengths you have in culture are very worth going after. And the US Army, when they found out that something wasn't governed, they went, oh my gosh, we've got to govern that right away. That's actually kind of good. We can use that. In the Army, everything is governed. And when they found out their data wasn't, boom. So data kind of easy. Now, another component of this, we also were there at the time when the military suicide mitigation project hit the fan. So we just happened to catch this particular one. And just a very short story on it, part of the process was trying to map some of the data that we could use on certain things. So I had a room very much like this room here where we called it our Council of Kernels. And everybody from different parts of the organization would say you can use this data for this purpose and this data for this purpose and we had a chip that we could pull with the Secretary of the Army. And so we brought the individual into the room and by the time the third person said you can use my data for this purpose, you have one of those books slamming on the table tops and the gentleman stood up and said, I, this gentleman, I have an announcement to make from now on out. We will all refer to this as my data. And anybody that wants to come tell me why we can't use my data to save my soldiers' lives, we'll have a very interesting conversation. Now, this empowered the team and changed the conversation around absolutely entirely to can this be done, to how are we going to in fact make it happen in order to do this. If I could get the CEOs of some of the larger corporations that I've worked for to make that same statement, they would be further down the road faster. But many organizations just are very reluctant to do this. If the secretary of the army can do it, why can't it do? Oh, wow. Yeah, a very special individual who were in there. And so we were able to look and discern this communication pattern to save some actual lives in order to do that. Another quick story on all of this. Thanks. This is a company that was buying a very large package that thought that every time you moved petrol from one tank to another, it constituted a retail sale. That wasn't, of course, the case because that's not a retail sale. That is not a retail sale, and that is not a retail sale either. And as we look at those, we said we could either modify the software or we can develop a controlled vocabulary. Modifying the software means that every time they put out a new version of the software, we have to go change the software in the way we changed it before. Controlling our vocabulary, we only have to do that once. And they did and they were able to save millions and millions of dollars. By the way, you don't want to get those tanks confused with those tanks. So if you buy a tank, you're buying 3 million data parts. And guess how many of them control whether the tank is obsolete or not? Turns out one of them. And here, in this case, by controlling for that vocabulary, we were able to save this particular branch of the Armed Forces $5 billion because they were running around putting tanks in operation that actually should have been retired. All of these stories are things that are known to the organizations. You all need to do exactly the same thing here. Quick one on this. Barclays was going to buy Lehman Brothers back in the 0708, the kind of thing that we had. And they had some contracts in there. They said we're going to buy all of your assets that are in this spreadsheet except for the 179 rows. So they hid them. And they had the spreadsheet to an associate who went after hours and accidentally unhid the rows. Which meant that the sale went through and was closed with these things in it. Well, we weren't supposed to buy that stuff. Governments applies to spreadsheets too, right? Now, you better believe, you go to Barclays back today, they have incredibly good, well-thought-out, well-articulated governance around their spreadsheet operations. I've heard the term deep-fried spreadsheet recently. I'm not sure what that actually means, but it doesn't sound terrific. The business securities, another group, they have a very famous piece out there where they had a typer who wanted to sell one share for 600,000 yen and got it reversed and sold 600,000 shares for one yen. That's $350 million. Again, the in-house system didn't have limit checking. The Tokyo Stock Exchange didn't have limit checking. These are all data governance-related issues. If you're not selling penny stocks, never let a stock go out the door that has a price of a penny on it, right? So these stories are incredibly important. And the point is not to take these stories, but to find your own stories and then tell them and then tell them and then tell them until they get sick of them and go, yes, I know the chocolate store already, Peter. You don't need to say it again. So let's just close here now at the top of the hour with this idea that governance is a lot like Maslow's hierarchy of needs, huh? Well, it turns out the fun things we want to do with data sit in the golden triangle, but that's just the tip of the iceberg and that if we have these foundational practices of which governance is one of them, then we will do much better at being able to deliver all of these pieces faster, better, and cheaper. If we understand how these practices work in concert, then we can get these technologies up top to work by developing the capabilities our organizations have and data governance, as you can see, is one of the five key capabilities here. Just one more point on this chart, which is that the foundation is only as strong as the weakest link. And if your governance portion is weak, you need to put more into the governance portion and don't bother to invest in the other areas. Now, I'm not showing that on this chart. On this chart, I'm showing you actually the platform and architecture piece as the weak link. So putting more effort into governance in this example will not help the organization. Again, that's a piece you can look at, measure objectively and find out things that you can actually get to work. And this, without doing the foundational pieces, but it will take you longer, cost more, deliver less, and present greater risk to the organization that, in fact, if you learn to walk, crawl, and run. So the need for data governance is continuing to increase. You can always look smart in the meeting by saying, there's never going to be any less data than there is right now. And now, and now, and now, right? It's not getting less. This is a new discipline. So we're going to be growing our way up. We've got to be driven by a strategy that's going to complement the organizational strategy. And comparing those governance frameworks can be useful because it directs the type of priorities that data management should attract. One last piece on this. If you are not discussing metadata during your data governance meetings, you are not discussing the right type of materials. Metadata is the language of data governance. Ta-da. And finally, process improvement can improve all of this. And while we get ready for the quote on this, I'm going to play a little piece. I'm going to finish up here. You get the idea. It's the Hotel California. So I'm going to have Q&A on the line here. And if you guys have questions, I'll take them as well. We'll go back and forth. Unfortunately, we shouldn't get there. Actually, maybe I can get this to work. Actually, though, I think that's not going to do. Somebody had way too much time in the data governance meeting to put this together, right? Nah, we don't want it to end up like that. All right. Thank you for that picture. Hey, Shannon, you there? I am. And thank you for this great presentation. I do want to give a shout out to our sponsor for today, Healer Packard and our prizes. Thanks for sponsoring us today. And just to answer the most popular questions that have been coming in, of course, it's just a reminder to everyone that we will be sending out a follow-up email by Ender Day Thursday for this webinar with links to the slides, links to the recording of the webinar, and any additional information requested throughout. I also have a link in there for Peter's books. So let's just dive right into it. Peter, you'll have to let me know if there's a question that comes in from your audience in the room there. But first question here is, where do industry data standards such as MIS, MO, and FIBO fit into data management activities? Okay. So the question, first question, is where do data standards fit into data governance activities? Now think about it for a minute. Management is making decisions about things, and management is supposed to make decisions about things. But are they always qualified to understand the utility of these standards? Absolutely not. So this is the place where data governance can add tremendous value by helping to explain the utility, first of all, the standards. And I think that the example I gave there of Toyota versus Detroit is an important one to think about. No, we don't want to tell you that the only size bolt you can attach things to the engine is this big, because if you add something too big, it'll fall off, right? This makes no sense whatsoever. But if you don't take that extra step to look and see how can standards play a role in this, then we have an issue. So the specific question in this case is looking at some specific standards. And the goal is for your group to find out how useful those standards are going to be. So the question is, if you have standards that could be applied but aren't, how long is it taking people to convert data to do this? Now, let me give you just a very brief example. It's one of the book examples. It's out there. If I've got data that comes in and it's first name, last name, middle initial, right, and it's all in one field, we all know that that can be incredibly difficult to parse. Somebody's got to sit down and write a little program to do this. So if we say the standards for data exchange between our organization and other organizations internally and our organization and our external data exchange partners is going to be we're going to put each name in a separate field, that works out really great until you get to where? Middle East. And the names don't fall into those neat categories. Are there standards that can help with that? Absolutely yes. So that's where it's worth looking at. If you're going to be a domestic organization, you're not going to work outside of the U.S., Canada, whatever, and you're going to deal with what we consider the normal names. That's great. By the way, telephone numbers fall into the same problem. You want to confuse an American? Hand them a British telephone number. Four or five digits in a row and you're supposed to say, why are we dealing with that? I have terrible problems with that. We can barely remember three, three, and then four to get it to work. They've got a lot more than that. The great question, again, how can you get those standards to work and how can the data governance organization not provide a 25-page memo to management understanding this, but maybe a one-page summary of the thinking that goes behind it and inviting them to a further conversation if this sounds like it might be useful helping to solve their business practices? Now, the next two questions coming in probably could be full webinars in and of themselves and certainly have been. The first one coming in is a very common question, Peter. Where do I start when clients ask for implementing data governance on a project scale? What aspects do I consider? The question is, where do I start when I'm implementing data governance on a project scale? And by that, I'm assuming that they really mean project as IT project. Now, anybody in your PMP certified? One of the things you learn is a project management professional, which is a great certification again, is that a project has a beginning and an end. That's one of the reasons we talk about data being external to projects because data doesn't begin and end. It persists the nature of data. It's going to be a cross-project type of a piece. So I go back to the question or personal and say, is that what we mean by on a project level or do they mean just getting started in data governance? And that's actually a really good question. Use the very simple definition. Data governance is managing data with guidance. After all, would you want to manage data without guidance? Probably not. Okay, that's where somebody might, for example, take data that's of a very highly sensitive personal nature and put it online when it never should have been put online. Maybe it was unqualified to make the decision around the office of personal break. But you can't just say, we're going to manage data with guidance. You have to show them why. I go back to Simon to next. We need to manage data with guidance for the candy store that I told you about so we don't repeat the chocolate story, okay? For the army, so we have everybody give us the data that we need to do suicide prevention for that tank company that I was telling you about so that we don't have to go in and modify the software every 18 months when we get a brand new version of the software out that we control the vocabulary. That reason is going to be personal to your organization. And it's something that's going to mean something to your organization so you have to find out what's important for your organization. If you go solve a trivial problem, they're going to go, thank you, that was nice. What else have you done for me lately? But if you go in and save $50 million in potential lost revenue, like Linda Beveller did in her organization, yeah, you better believe she got promoted as a result of that. Fantastic, love it. And the next question, what do you think are the most important aspects of metadata strategy, possibly business taxonomy or technical data implementation? I like this question here. The question is, what is the most important aspects of metadata strategy? I have never actually seen a metadata strategy operationalized, Shannon. I've seen a lot of companies that look at this and, again, as you said, this could be another webinar in and of itself. Big secret of metadata? All data is metadata, or metadata doesn't exist depending on which way you want to go with your definitions on that. Oh, that's scary, right? No, I'm not managing anything. So somebody's data could be somebody else's metadata in almost all instances of this. And so I don't like to separate out those two strategies. It's kind of like arguing over what's the difference between data and information, right? Data is the raw stuff and information is how it's used. It's a real good way to think of it. But if you have a separate data strategy versus a separate information strategy, that's splitting hairs, and it's really not adding value to the process. So what I would say from a metadata perspective, where I've seen organizations get into some confusion around that, if you're looking at things and saying, is that metadata and therefore should I manage it as metadata? That can be a very tough problem to solve. For example, I'll just put the number 42 out there. 42 is my age 15 years ago. Who cares, right? Well, actually, the ABC board cares because they want to know am I old enough to buy alcoholic beverages in the state of Virginia? Yes, right? They can do some math and make it work pretty well. 42, metadata or data. Oh, that's his age 15 years ago. It's data. If I have the 42 and I knew the 15 years ago, could I actually figure out whether he was old enough to buy? No, it falls into both of those categories. So the real key to it is not to try and look at everything and label it, but to instead say should our metadata practices be extended to include that particular data item? So if I'm looking at a particular piece of data somewhere, is it important enough to include in the scope of our metadata practices? That gets you to the value of the piece that you're looking at. And if that piece has intrinsic value to the organization, then it should be included in the scope of your metadata practices. Notice I've changed the question. If you're supposed to manage metadata, oh, gosh, that's a big problem. What's metadata? Where do I find it? How much do I have? But if I say am I going to include it in the scope of our practices, we're making a value judgment saying it's worth spending organizational resources to make sure that this data item is managed well within the scope of our practices. Sure. Metadata management is becoming such an important topic to so many people. It's coming up in every single webinar we do. In fact, the next webinar you're doing next month is specifically on metadata management. Yeah, it's the talks we're doing next week too. Yeah, yeah. Yeah, even some of the most unsuspecting webinars, we've had the question of metadata come up. It's just really important, as you've mentioned. You know, the next question we have coming in is likewise a question we get a lot, you know, people struggle with how do you get sponsorship for our data governance initiative? How do you explain to the executives how important this is and the need for this and maybe even build an ROI around it? So the question is how do you get executive sponsorship for it and then the second part is how do you build or turn on investment on it? And that's an incredibly important piece. The sponsorship piece is a really interesting one because people don't really understand how data works. One of the other stories that I tell a lot is a terrific story that we work with a logistics company out in the middle of the country and they had a room full of about 100 people. And these 100 people spent all day every day fixing every bill that went out. The bill had the wrong customer name. The customer had the wrong address. The thing they were billed for was incorrect. The price was incorrect. The day it was done was incorrect. All of this stuff was incorrect. And these people spent a lot of time making sure that every bill was correct. So we talked to the manager that was in charge of this and said, you know, that's something that data governance could really help out with. He said, help. I don't need any help. I just have the best quarter of the best year ever. I need 200 people in that room. Okay. Not a receptive audience. This gentleman was not going to understand this because he had a system that worked well and produced good results for him as far as he was concerned. So we went instead to the CFO and said, you're doing about $9 billion a year business. How would you like to improve your cash flow by 30 days, $100 million a dollar? Absolutely. I got time and attention there. The return on investment case, which was the second part of the question that you asked, was very, very easy to demonstrate. I can tell you, it did not take us $100 million to fix that data governance issue in that organization. On the other hand, the one executive was clearly not going to be an advocate or a champion there. So the question is, what's happening in your organization that everybody kind of agrees is a problem? And again, I told the chocolate story. I told the Mizzouho security story. I told lots of different stories in the organization. Every organization has its own individual challenges. Find out who suffered from that. And surprise, surprise, it's almost never IT that suffers when that happens. It's the business that suffers. Everybody's promised additional revenue, additional savings, additional insight into the customers, faster product innovation delivery time, all kinds of different things out there. Those are the people you have to go to and say, hey, I think that your problem might be improvable if we managed our data with some guidance. And if we did that, we could actually come up with a way in which we could work together and find a partnership and start to build it. You can't solve all the problems at once. You can't boil the ocean. None of this is going to be helpful. So again, find something small, work your way up, and then come up to it. Got a five-year plan. Four of the five years are going to be incorrect on that, right? You're going to get the first year right, and then you're going to revise the next four years, which is a perfectly appropriate way to do it. But if you don't have those returns on investment, and again, I'm just going to make a very crazy example here. If you have five people who are all getting paid $100,000 a year to do data governance, I think it's imperative that you show the organization that at least after two years you save them at least a million dollars, right? Or make sure that they agree that it's going to be three years and a million and a half dollars before you get to that particular piece. Notice I'm using huge numbers that are obviously over-inflated, but in most organizations it's very doable to do that. Five people, half a million dollars a year. I see, I mean, again, I showed you some numbers here, five billion dollars, I can guarantee you, we didn't charge them five billion dollars to find all those obsolete tanks in their inventory that were out there. Very, very easy to find those returns. Love it. And now, you know, back to more of an organizational question, Peter, how does one manage meetings in data governance? How do you avoid calling everyone for every topic? In other words, what are some good data governance structures? So the question is about how to manage the actual data governance meetings. Have you guys heard the story of Jellyfish? Google it out there, it's right now. It's a great term to say we're getting off track. Jellyfish are kind of a sticky thing because you can't nail them to the wall and they're not really pleasant to encounter as well, but not dreadfully, you can swim with them. So it's a term that we use to talk about a meeting that's getting off track. There are lots and lots of these techniques, but one of the most important things to do is to realize that your data governance people may or may not have the knowledge, skills, and abilities to run good meetings. But there's probably good people in your organization who are called professional facilitators who can teach you some of these skills. And if you don't have them in your organization, there's a whole set of online learning tools you can learn how to facilitate these meetings. And the point of the question is very, very good. If you have a well-meaning group of people that attend a poorly run meeting, they're not going to have a good impression of the overall process being useful. So it's a way of putting meeting discipline in place, but there's nothing in governance about running good meetings, right? That's something we need to grab from other disciplines and bring to our process so that we can say, hey, let's run a really good meeting so people come to the meeting, they know what the agenda is, they know exactly what they're supposed to accomplish, and they get done, and they feel like, wow, at least, even if I wasn't enthralled with the subject material, it wasn't a waste of everybody's time in order to go through this. Another group in your organization that you should also look to are your communications people. Almost every organization has some aspect of a professional communications group that handles PR and such for the organization. And ask them to help with your messaging, help brand the data governance group to even brand the data in some cases. We've had data branding exercises that we've used that have been very successful for some organizations, where they simply say, oh, are you using the good data or the bad data? That's not a question that you want to really have come up too often, but, you know, internally, people will actually do some very good work around that. So again, great question, and these are not things we need to reinvent for data governance, they already exist out there, so let's use the resources that we have in our organizations to leverage that. By the way, when you do that, they become friends for life as well, so they're going to be able to help you out in ways that you don't anticipate now, but down the road, certainly. Yeah, these certainly have been some great questions and questions that we see a lot that a lot of people struggle with often. You know, this is the end of the questions that I have coming in here for the moment. Peter, any questions from your live audience there? Any questions here? Great question. So the question is, I told some stories where there were clearly some things that needed to be corrected in here, and do I ever encounter groups that are actually in pretty darn good shape? And the answer to that is there are certain places around that you would hope were doing a good job and in fact are, which is kind of good, right? Just for starters, I won't say too much more about that, but you get the idea on that. But in addition to that, this process seems kind of natural to some organizations. So a heavily oriented process group that has a process architecture that they maintain formally kind of looks at some of this stuff and says, what else would you do? But I find that the ratio is this. Out of 100 organizations, 10 are attempting to do this well and making good efforts towards it, and one in the 10 of those is really achieving excellence. So what that also means is that if you're out there playing in the competition, the competition is not doing better than you likely. And if you do a little better this way, it can lead to a strategic competitive advantage, which is, of course, something that all organizations are trying to achieve. Thanks for that. Indeed. And we have one more question coming in here, Peter. Okay. What types of metadata are the easiest to sell to non-IT? What kind of metadata is the easiest to sell to non-IT? You know, I'm sort of grinning on this and trying to think of an example that I can tell you without divulging too much. But the easiest thing to do is actually not try to sell a type of metadata to people, but to solve a business problem and then show how by better management of your data assets, it would have either prevented the problem from occurring in the first place or at least helped catch it earlier on on that. So I'll give you an example. I said before that the data governance group really should have veto power over IT projects. Why? Well, if you're buying a software package, one of the things I like groups to do, and this, again, is implemented in a number of data governance organizations around the planet at this point, is to say, if you're going to give us software, you have to show us a logical model of what the data looks like in your organization. Somebody says, why would that be important? I'll just give you a very specific example. If you have a business rule that's implemented in the software that says an employee can be one and only one person and a person can be only one employee, that's a data rule that's enforced by the database referential integrity that is put out there. And if you want to implement job sharing in your organization, the only way you can do that is by doing a workaround. If you have two software packages that come in and one implements that rule clearly and the other does not, most organizations don't know to look for it and figure out how much that is going to cost the organization to implement that workaround each and every time they implement the software package. They can either have to customize it or they're going to have to do some business practices to compensate for the lack of functionality that's in there. So that's really what I would do is to find something that has happened in the organization that means something to the organization and really focus in on that aspect of it. So, again, having software packages come in and have the data group veto them, yes, you will save your organization hundreds of millions of dollars in some cases by not investing in software packages that just don't work as well as they think they work, or, of course, they all work perfectly on PowerPoint. We know that, right? Hey, PowerPoint's great for everything, right? You bet, Shannon. Any additional questions coming from your live audience there? We're good. Well, thank you, guys. Hopefully it's been helpful. All right. Yeah, Peter, thank you so much for this great presentation. And again, thanks to HP for HP Enterprise for sponsoring today's webinar. And thanks to our attendees, as always, for being so interactive and offering up some fantastic questions as always. Look at all that stuff you have coming up. And I'm so excited about the homemade jam there, Peter. We're looking forward to that. Monday night of the conference next week, we'll all be playing music. And we are looking forward to seeing almost a thousand people out in San Diego so we can carry these conversations onwards. Absolutely. And, you know, as mentioned, next month we're talking, you're talking about metadata strategies, which is a perfect follow-up to this particular webinar. Just a reminder to everyone, I will send a follow-up email. It's in two business days. So by end of day Thursday, with links to the slides, the recording of the session, and additional information requested. And again, I'll get you the links to Peter's book and everything else in that as well. And I hope everyone has a great day and safe travels, Peter. Shannon, thanks so much. We'll talk to you soon. See you next week. Cheers.