 Hello and welcome. My name is Shannon Kemp and I am the Executive Editor for Data Diversity. We would like to thank you for joining today's Data Diversity Webinar, Data Governance Strategies. This year's latest edition in a monthly series called Data Ed Online with Dr. Peter Akin brought to you in partnership with Data Blueprint. We at Data Diversity are very excited about the particular topics that our attendees keep an eye out for more educational resources on Data Diversity regarding data governance, including our upcoming Data Governance Financial Conference at the end of September in Jersey City. Now let me go to the floor to Megan Jacobs, the webinar organizer from Data Blueprint to introduce our speaker in today's webinar. Hello and welcome. Thanks, Shannon. Hello, everyone, and welcome. My name is Megan Jacobs and I'm the webinar coordinator here at Data Blueprint. We are pleased that you found the time to join us for today's webinar on Data Governance Strategies. As always, a big thank you goes out to Shannon and Data Diversity for hosting us. We'll get started in just a few moments after I let you know about some housekeeping items and introduce your presenter. We have one hour for the presentation followed by 30 minutes of Q&A. We'll try to answer as many questions as time allows, but feel free to submit questions as they come up throughout the session. To answer the top two most commonly asked questions, yes, you will receive an e-mail, links to download safe materials, and any other information you request during the session within the next two business days. You can find us on Twitter, Facebook, and LinkedIn. We've set up the hashtag data ed on Twitter, so if you're logged on, feel free to use it in your tweets and submit your questions and comments that way. We'll keep an eye on the Twitter feed and we'll include answers to those questions in our post session e-mail. Now let me introduce you to our presenter. Peter Akin 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 of experience and has received many awards for his outstanding contributions to the profession. Peter is also the founding director of Data Blueprint. He has written dozens of articles and eight books. The most recent is monotasking data management. Peter's experience is more than 500 data management practices in 20 countries and conclusively 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 multiple year immersions with groups as diverse as the U.S. Department of Defense, George Bink, Nokia, Wells Fargo, the Commonwealth of Virginia, and Walmart. He often appears at conferences and is constantly traveling. So Peter, where are you today? So hi, Megan. I'm across town from you and I'm at the SunTrust Mortgage Office who wanted to hear a little bit about this. And I said, well, why don't I come on out and talk to you guys about it? Well, we're here in the session. So I've got a live audience today, which is unusual. Normally I'm talking just to the computer screen. It's not nearly as much fun. So thanks, everybody, for joining us. And thanks for hosting us, Trevor, on this. So most people aren't really aware of data governance. But anybody know who best Jacobs is? She's the former CIO of Target. And of course, we know they also lost their CEO due to a data problem as well. In fact, it even went a little higher than that. It went all the way up to the board of directors, where the folks in New York were saying the board of directors and the audit committee in particular had acted irresponsibly in ignoring the signals of the oopsie that they had there. And so we're getting a little bit more play in the C-sweets with this stuff. People are starting to pay attention. And you think the Target folks are paying attention? Guess who else is paying attention this morning? Now, my headline here was from a couple days ago, and it says Home Depot is working around the clock to find the data breach. I've already found it now. It's out. And it looks like it might be bigger than Target. How many of you guys have changed your charge card already because of the Target thing or a Home Depot breach? Exactly. We'll see more of that down here. So this data stuff's becoming a little bit more important, and luckily the people at the top are listening to it, which is kind of good. So what we're going to cover today is data strategy around how this works. It doesn't do much good to have governance unless you have an idea of purpose which you're trying to head towards. So we're going to cover recent usage on it in the sense that strategy is a fairly recent term. We'll put it in context of saying that whatever data governance strategy you develop should be in complementing your organizational, your IT strategy on that. And then we'll talk about some difficult choices that organizations are going to have to make relative to that process. We'll look at governance in particular, and just so that you guys know on this, I've got about 12 or 15 sheets of supplemental material where I'm going to flash it up on the screen and it's going to go away. So we're not going to walk through a lot of these. I'm going to leave you guys something to take away on this as well. But we'll dive into what is it, why is it important, and what are the requirements for effective data governance in here. Then we'll look at some of the data governance components. Again, there's some supplemental material in here, so I've got some sort of standard stuff that I'm just going to leave with you and I'm not going to walk through each slide because I've got a lot of material I do want to get us through. And then when we get close to the top of the hour, I'll start doing some storytelling. I may or may not finish all the stories that I'm going to try to do, but it helps. And it turns out storytelling is a really important part of data governance. Then at the top of the hour, when we get back to three o'clock, we will actually come back and open it up for some Q&A out there. Let's dive in and then look at what is strategy. And the first thing to understand is that the use of the term strategy is a very new one. If you look at how the term was used, it wasn't really even introduced until the 1950s. People thought it was exclusively the problem of the military. And while that's interesting, people started adopting it to business purposes and saying you ought to have a strategy. So then we need to define the term, being data people, we love definitions. I like this particular definition of strategy. It's a pattern in a stream of decisions. So it's not a three-ring binder that you put something up on the shelf with. It's a way you get people to start thinking. But when they have to make a choice, they try to say, okay, I'll err on the side of strategy and have it be a guide to your thinking and operations as opposed to an actual thing that says step one, step two, step three. And I'll illustrate that in just a second. Another definition here, it's a system of finding, formulating and developing a doctrine that will ensure long-term success if followed successfully. Now, one of the more famous examples of this is Napoleon. And I know we didn't come here for history lessons, but we might as well dive in and learn from one of the masters at this. And so the question that came up from a strategy perspective is, okay, I've got a small force and there's two bigger forces arrayed against me. How do I defeat the competition when the competition is actually bigger than me? And the answer of force is divide and conquer. Now, Napoleon didn't have a plan here that said step one, step two, step three. So let me show you what he did have, which does represent a good example of a pattern in extreme of decisions. What you're looking at on the slide here is a set where we have in blue the French and Poland's troops, of course, and you can see their supply line at the bottom of that piece. In red in the upper left-hand corner are the British, and they had combined with the Prussians to get up both of those things. As they got both of those things running, you may have to refresh that one too if it looks like it's stuck. The supply lines here you can see for the British ran up to the left, upper left-hand corner there in red. It was to Ostend, which is where their supply lines were. And the Prussians came in through Liege. Oh, that's a terrific idea. And what did Napoleon know being a master strategy person that the others hadn't quite figured out? They did figure it out eventually, but of course they made it. It was too late. The idea was when you attack an army, the way it retreats is it follows its supply line. It's called idiot's tail. And of course that's exactly what Napoleon did. He set up a situation here, watched this little video. What he does is he hits them, and he hits them very, very hard. Much harder than he would do in a normal battle. When you do that, the two armies then retreated, of course, along their supply lines. When they treated along their supply lines, they were no longer one large force facing him. They instead made a pattern in his stream of decision-making and said, let's go after, in this case, the Prussians first, because we hit them harder. We turn around, we beat up the Prussians, and then quick before the British figure out what's going on, we go over, and we beat up the British. So again, bullies on the school field know the same kind of lessons that they go into this. A great example is a classic strategy example from a military perspective. Or we can look at William Gretzky, and most of you know William Gretzky. He's a hockey guy. And his definition of strategy is he escapes where he thinks the puck is going to be. If you're chasing the puck, you're always playing catch-up and you'll never really get anywhere, particularly in hockey. It's a very fast-moving game, but of course we want you to think that business is looking for the same strategy level and the same speed. Now, I mentioned before, we don't want you to develop a data governance strategy that is contrary to or not complementary to your organizational strategy. We also need to make sure that it complements your IT strategy. So we look at the data governance strategy as flowing and supporting the other two components of strategy going into here. And most of you are familiar with corporate governance. It's been inculcated in many organizations over the years where people just say, okay, well, yeah, we've got to have some corporate governance. And we'd also like to have some IT governance around this. Now, just an interesting side note, those of us that are in the data world, we've been seeing some interesting moves in that IT has turned out to not be necessarily the only place that data can report to. And your competition across the street, Capital One has moved their data function under the Chief Risk Information Officer. That's a very different positioning of that particular function. The reason for that is because a lot of organizations, and I'll make sure I caveat that's the only thing I say about Capital One on that, because that's nothing to do with it. We'll do go into these organizations and look at some of the things that are going on in here. What we see is a really great set of articulations. You can get those off of those K-1 forms, whatever the corporate filings are. We'll talk about what they're trying to do. Again, I've got some examples of it. There's nothing real on this slide, but leverage growth and return and this sort of thing. And then if you look at the bottom half of this chart, what you see is a mishmash of IT projects. And the link between the IT projects is tending not to be nearly as useful in there as the rest of it is. So what we see is that IT is very difficult to let work in a project mode. People just tend not to understand it. See my slides are going a little behind here. I'm going to stop and catch up with them real quick. Always difficult when you don't have the bandwidth of the place. There we go. That should do it. So what you have is a lot of really good people who are working in IT, who are working very hard on a specific project. The challenge, of course, comes at remembering the reason that we're doing this. And the reason we're doing this, of course, is some form of strategy. It's difficult, however, to have strategy and focused in on the project because the project is get it done by Friday so you can go and have a nice weekend, whereas the strategy is long-term, decades perhaps in the making, in terms of how to make it work out. So what does exist tends to be confused, inaccurate, and incomplete at the actual IT project level. They don't well reflect organizational strategy. And again, I'm certainly not picking on any one organization here, but look at these things over the years. It's just been a very big challenge. What this means is that when you're talking about strategy, you have some hard choices to make because it's not easy to start off with a particular strategy at a particular place. And one of the reasons for that is because when we look at strategy, people tend to say, well, we can do everything, and we'll try to do everything. But we realize eventually that it's probably not a good idea to do that. I'm going to turn off the video here because this seems to be messing up a little bit of the bandwidth. Oh, here's my video off. Share a line. Oh, heck. You didn't see it. But there we go. There's my video. That should make it go faster. Thanks, Tripp, for that. Strategy means hard choices. Again, Napoleon couldn't beat up everybody if he wanted to. Wayne Greski can't score all the goals himself. The two dimensions of strategy that we look at it from that perspective are to either improve your operations, or if you're not able to improve your operations, then you need to innovate. There really is no other set of choices that we have in there. If you don't understand how that works, what we end up with is somebody saying, oh, we should do everything. You can't do everything. It's just like going to Disney World. You can't do all the rides on it once. You can't do all those sort of things at one time. So when we look at these matrix, one of the first choices is pick one. Don't try and do everything at once, because if you try to do everything all at once, none of it ends up working very, very well. So in that first quadrant down there, in the lower left-hand corner of your screen, quadrant one is where the vast majority of organizations are sitting today. Again, Tripp and I have been in this business for a while, and we would call data governance data administration from many years ago. Many organizations are just now discovering that data is an asset that needs to be managed in the same way as your financial assets, your real estate assets, and other things that are coming to play in there as well. When you look at it from that perspective, you then say, okay, then I have some limited resources to apply. I can either make things more efficient and effective, or I can innovate. Now it's interesting today, you guys are in here today, instead of watching the Apple release of the iPhone 6. Boy, doesn't that sound like something we'd really rather be watching right now? We'll pass on that particular one. But we'll talk about Apple versus Walmart. And as companies go, Apple's clearly on that innovation spectrum, whereas Walmart's clearly on the efficiency and effectiveness spectrum. These are important things to think about, and more importantly than either of those individually is that our measures show that only one in 10 companies actually has a data strategy. So if you don't have a strategy, then any decision you make must be the right decision. That's actually kind of good. Again, a piece of supplemental information I'll put out here is that just the CMMI has put up some data strategy elements. We're not actually doing a data strategy element. That's very interesting. Always magic on the phone. Hang on, let me do this. And hopefully you're still here. So again, what we're trying to do here is answer the question, what does data governance mean to your organization? And the key to this is you're trying to pop some individuals whose opinions matter. You do want to be influential on this. To form a body, it needs to have a purpose, a charge of one form or another. We're going to advocate and frankly evangelize for what we're going to talk about increasing the scope and rigor of our data-centric development practices. And I'll explain what those are as we go through it. But I want to show you an illustration from one of the groups that we've worked with, which is that in their environment, they said, you know, around here, getting data is like that Catherine Zeta Jones movie where she had to go through all the laser beams in order to mess with the thief. So we won't go too far down that particular analogy here, but that meant something to this organization that was really important to them. And when we spoke to them in this language, they actually made their data governance person they called her CJ. Catherine Zeta Jones on that. Now, it's important when you do decide to do data governance to have a nice articulation of what it does. We call it an elevator speech or other things like that. But if you're going to help have data management and data strategy in general help process decisions, that's great. If it's a focus around inventory or quality management, that's okay, too. If you're trying to figure out what their operations or delivery plans are, if your data security plan or your organizational strategy formulation, you've still got to say what does it mean because everybody has this problem of what do you mean by data governance? We don't have the answer to that. It becomes very, very difficult to actually do things. And I'll talk for a quick second here about the difference between data governance and data management governance. This is talking about policy, whereas data management is the business of implementing that particular policy. Now, just the last webinar that we did was the data management maturity framework that Melanie Mechani presented last month. This has been a child of Melanie that she's been working on for many, many years and we're so pleased that the SEI has now adopted this and made it the standard that it is going to be. If you're looking at this diagram here, what you're seeing are five major functions. Data governance, data management strategy, data quality, data operations, and data platform and architecture. And each of these corresponds to a level. The first level is everybody shows up and gets a D. You get one point just for being alive, basically. If your process is managed, but you get two points, just to find you get three. If you measure it, it's four and if you try to optimize it, it's five. These same maturity models are the same thing that form the basis for TQM and ISO 9000. So this is not a lot of new stuff for everybody, but now that I have the ability to look at the practice areas, the things in orange, blue, red, green, and purple on the other side, I can now marry them with these levels and put them together in a way that starts to make sense. And here's an analysis I did for a group at one point where they were trying to figure out where they were. And the answer you can see is they were between a 1 and a 3. So it's not a very mature organization. It turns out there aren't very many of those mature organizations, again, because of the fact that this is relatively new. Or here's an airline we did this for fairly recently where they were 1, 1, 2, 2, and a 1 and they said, what is that? Why do I care? And I said, well, this is your competition. And they went, oh, we're the ones and they're the twos. So they kind of got that they need to start working on some other areas in order to do this. In fact, when we look at the overall statistic, I call this the era of big data since we started that in about 2007. And you can see that the measurements are statistically unchanged in that area. Very problematic because, of course, everybody knows the volume of data is increasing at super, super levels. Again, the London Summer Olympics had more devices connected to the Olympics alone than there are people on the planet. It's kind of an interesting, sobering thought around that. So as I mentioned before, there's a lot of supplemental material in here. This is just stuff for you guys to take away. Deliverables, lists of things, roles and responsibilities. I'm not going to walk through each of these, although if you guys have an interest, we can go back in and do that. More importantly, what are we trying to do with governance? And the answer is that bad data and bad data management practice cost organizations millions in productivity in redundant and siloed efforts and poorly thought out hardware and software choices. It means that organizations are in their time being reactive instead of proactive about it. And our measurements show that between 20 and 40% of all IT costs can be reduced through better spending in the governance area. When we look at governance efforts in general, one in ten produces a positive return on investment. Thirty percent of them produce some return on this. And the vast majority of them produce very little tangible business outcome on that. And that's a problem for people. The reason for this is because we operate in what we call a standard application development mode where we build things and we get to the third step systems and applications, and then the conversation from there on becomes about people software, SAP, or whatever the particular packages that we do. And this guarantees for sure that you're going to have your application processes wrapped around your software and not necessarily around your organizational requirements. And there's very little data reuse possible. The key of this is that data are assets that must be owned or controlled and converted into cash value because if we can't convert them into cash, nobody else understands what it is they're trying to do as well. So evolving data is different than creating new systems. IT has gotten really good over the years of creating new systems, but data evolves at a much more gradual pace. And so my rule on this one is that data evolution must be separated from external to and perceived systems development activities instead of trying to do it at the same time. This new data-centric philosophy then allows us to create the data layer before we go and discover what the network and application layer should be, which maximizes our ability to reuse data within our organization. And as our sole non-depleting, non-degrading, durable strategic asset, it's particularly important that we treat it as such in there. Now this data-centric development, DCB that I'm abbreviating here, is really an extension of existing practices. Many of groups are already doing this in pockets. What we want to do is get organizations to think differently about development and asking if the data is correct instead of on time and on budget and valuing the correct data much more so than the correct process and auditing the data rather than the project documents out there. It makes for a lot of difference in terms of how we do this. So let's get into the components on this. And first of all, getting started processes is actually pretty straightforward. Just like programming, which most of you remember from the good old days, you have a startup routine. You need to do an assessment of some sort. You define your data governance roadmap. You secure the executive mandate, whatever it is, and you assign your data stewards. That occurs once. Then you go over to the other side and you have a plan. You evaluate the results and revise the plan as you go through this. In order to start this for your organization, particularly from a strategic perspective, it's a good idea to look at a series of frameworks and try them on for various sizes. Now, most people aren't really familiar with working with frameworks, but frameworks are very lightweight mental structures that allow you to guide analysis. It helps you organize your process data. It helps you make priorities about your data decision, and it gives you a means of assessing the progress. For example, if I'm building a house, I shouldn't put up the walls or the roof until the foundation has passed the inspection. And if you did a built-your-own house and gone through the similar process, the bank won't give you any money until they actually see the foundations in place. There is no IT equivalent for building systems yet, and that's one of the things we'd love to see happen is have people put that up. On the other hand, once you do start that process, it makes good sense to put the roof on next because that way you can work undercover and not expose to the elements. So if you make all that dependent on contingent funding, you can actually have a pretty good success on that. Now, again, I'm going to go through here with some very, very quick references here. This is the Dimbox framework. It's organized into an iPhone diagram. Some of you remember that. Inputs, processes, or activities, and outputs in there. And I'm going to put our processes right in the middle there. Those are our data processes that we use. Here's another one. This is from the Data Governance Institute. Without there, here's one from my friend Rob Siner. All right, here's a couple from IBM. Again, I'm not going to walk through those. This is something, as you're looking at it, you should take each of these things from us. I did find one for the American College of Personnel Association. There's like a boat. I'm not sure why it's a really clever graphic, but I'm not sure that it's going to give us the right kind of things there, but it works for them. That's the important thing. Data Governance has to work for your organization. In addition to that, some of the other supplemental material that you can take away here is NACIO, the National Association of State CIOs, has a data governance implementation process and a series of checklists that you can look into. Again, I'm putting these up here as supplemental. There's lots of them. They're all attached to the slides, so you can go back and review them at your leisure in order to do this. And one additional piece of this as well, a very nice individual actually and a five-page successful data governance checklist that we've used up as a guest, put that particular piece together. There's also some worse practices, and again, we're going to put them at the end so that you guys can take a look at them in the long run. So let's dive into a couple of stories now. What time is it? I can't see the... How are we doing, Chris? It's 2.30. Good. Oh, we're doing great shit, though. We will get through this. So one of the other pieces of inspiration that I've taken away is a really cute little TED talk by a guy named Simon Temeck. And it's a wonderful thing. Well, he makes a quite obvious point in hindsight that most people like to talk about what. It's a very easy thing to talk about. But people aren't as interested in what as much as they're interested in how, and they're even less interested in that in terms of a why. So we get back to the motivation. Why aren't you setting up data governance? What is the purpose? Sometimes it just looks avoid 2008. That's a really good thing to avoid. Sometimes it's something completely differently. So let me give you an analogy around this. And interestingly, I was presenting this to a group here at the state yesterday, and they told me that's a Porsche engine. I wouldn't have been able to recognize that as a Porsche engine, but okay. We took this lesson away when we went from the U.S. federal government. So I was with the Defense Department for a number of years and we went to Detroit to learn some lessons from the private sector. And one of the things we learned was kind of an interesting one. One Detroit wants to attach things onto an engine. They just want to make sure it doesn't slow down the assembly line. So I'm attaching the air conditioning and the fan belt. All these other things, as long as I can put it on and not slow down the procedure of the assembly line, that's great. But what that produces is 10 different bolts. And the consequence of that is we now need 10 different wrenches in order to have, not just for us, but for everybody who's going to service these automobiles and 10 different bolt inventories. Of course, the number isn't 10, right? Whereas Toyota does this, but their governance procedure says after we build the engine one time and get a prototype, we come back and we evaluate each bolt and say how much can be standardized before we put it in production. If we do that, we have the opportunity then to use the same bolt for all the assemblies, which means one bolt assembly, one type of wrench, et cetera, et cetera. Again, the numbers are not right. It's not 10, it's not one, but you get the idea if you don't take that additional step to do it, you'll never be able to attain the opportunities that occur from that kind of synergy. Similarly, some of you remember healthcare.gov. We had some experiences with that last year about this time. And one of the, of course, amazing things was there's no way that anybody in data governance would let 55 contracting organizations. I started out with divide and conquer. You guys got that. Here now we're talking about too many cook, spoil, and raw. And, of course, with 55 contracting organizations, they're most interested in maximizing the revenue to each individual organization, and that's something we as taxpayers ought to be concerned about. But here's another piece. How many of you would let an IT project start if six weeks before, on two years' development work, they hadn't finalized the requirements? Yes, they hadn't finalized the requirements six weeks before they launched this thing. And, of course, the other part, we would never turn it on to Big Bang either. Let's turn on all 350 million Americans at the same time, right? No, we start out in Virginia, get Virginia online. We'll add Maryland, you know, again, the very, very good ways of doing this. Jim Johnson, who runs the Sanders Group, has really good comment on this. He just says the really miraculous part was that anything actually worked at all on this. Now, another comment on this. Marty Abbott was one of the people who went in to diagnose the problem. The system hadn't been designed to work correctly because any single thing that slowed down slowed everything down. You can imagine driving your car and having a light bulb go out on your headlight or a running light and your car stopping because, you know, it'll keep you from getting tickets. Okay, and that's an okay thing to look at in there. Another example from healthcare.gov that, again, what has been handled by governments was that the software was programmed to access the data using traditional SQL methods, which is what we teach you all at college and university. But one of the vendors had incorporated big data techniques, which doesn't work with SQL in there. So the contractors were saying, here, you need to get this data. And the other guys are saying, tell me what SQL I need to write. And they're going, no, no, no, we're not doing SQL, it's completely different. Again, the stories about this are just incredible to use. There's another interesting story around this. We did the data governance role for the Army. And the Army was very interesting because the Army found out something was not governed. Now, any of you that's had military experience, you understood that governance is an incredibly strong part of the military culture. So it was quite easy to leverage and say, look here, there's something that is not governed. And they went, oh, we got to fix that right away. What do we do? We call that data governance. Okay, so the Army is now rolling out a data governance program around the topic. Another thing we were able to do for the military at that point was work on the suicide prevention program. And you all read about it in the papers and things. President Obama made a lot of statements around it. More soldiers are dying because of their own hands than the bad guys. And that's kind of a bad thing. We really do want to support our men and women of the armed forces and make sure that they have everything that they need to have. In particular, we need to make sure that they can readjust to society when they come back. Now, we would sit around in a room very much like this. And you guys would be what we call the Council of Colonels. Each one of you had a pocket of data that was helpful to this. And we were trying to map the data from here to here and from here to here and to bring it all together so we could get a relatively complete picture of the servicemen and women that were having some trouble in the area. Now, as part of doing that, one of the things you all were doing as good data stewards was saying, my data can be used for this purpose and my data can be used for that purpose. But you can't use this data for that purpose. We're really glad those laws exist. On the other hand, I had a chip that we could pull with the Secretary of the Army, and he was able to come in at one point. You have to remember now, the Secretary of the Army is the highest ranking civilian official who ranks over top of the military. We have a civilian-controlled military in this country. And the third person that said, it's my data, he did this, put his fist on the table and startled everybody, you know, like, wham. And everybody went, whoa. And said, ladies and gentlemen, what you have to make from this point forward, it is all my data. Some of you are smiling, right? That's actually a pretty astute statement for the Secretary of the Army to make. And if anybody has any questions about how to do this, they can come talk directly to me. So if you wanted to make an appointment with the Secretary and tell him why your data shouldn't be to save soldiers' lives, I didn't want to be part of that conversation. I'm sure nobody else did either. Now, of course, the conversation turned around. The reason I tell this story a lot of times is because if I could get some of the C-level executives to take similar courage and say, no, I'm sorry, this belongs to the organization, it doesn't belong to marketing, it doesn't belong to manufacturing, whatever it is that they're arguing about, I could say companies hundreds of millions of dollars in which case I'd say, I just want to work for a small percentage about an amount of money. That would work really great for everybody. So of course, with this, we were able to develop communication patterns so we could determine when soldiers were at risk and what types of challenges that they were going to be running around facing. Now, again, remember, all of this is the context of strategy. So the strategy for military suicide prevention is keep people alive. Find out early what's going on and let's make sure they don't get themselves into trouble. Here's another military example, although I'm going to start out with an interim example of an oil company. Now, the oil company had a software packet that they were acquiring. It was another ERP, enterprise resource planning program. And this ERP came in and it didn't have the right vocabulary for this company. Any transfer of liquid from one tank to another constituted a retail sale. Well, that works out perfectly well if you're putting petrol into one of these things for your lawn mower or into your car. But if I'm putting tanks into these things, which are oil tankers or refinery tanks or maybe tanks that float on the sea or maybe tanks that fly, we don't want to count those as retail sales because they're part of production. So the company was facing an interesting dilemma. Should you modify the ERP, which always costs a lot of money, takes a lot of time, and has to be repeated every time there's an upgrade to that particular software or if they could control their vocabulary correctly, then they wouldn't have to make that investment. They could run the software vanilla out of the box, not have to deal with the constant upgrade challenges that they were facing, and in fact save the organization lots of money. So their governance organization said, here's what we're going to do. We're going to make a conscious decision not to modify the software because we don't know whether it'll work really well for the organization overall. And we're going to be very careful with our vocabulary. And they control their vocabulary and they have two types of sales. They have petrol tanks in cars and petrol tanks that are retail tanks and everything else they back out. So by controlling their vocabulary, which was a lot cheaper than fixing the software, they were able to actually save a ton of money through a data governance strategy. And of course, you don't want those tanks to be confused with those tanks which are completely different or we can drop in a little joke there about somebody being tanked. But let's talk about back to the military example. Every time the military buys a tank, it results in the proliferation of more than 3 million individual data values. Great. How many of those do you think controlled obsolescence? Of course, the really bad answer is if nobody knows the answer, which is the case, you end up spending a lot more time working on things that you shouldn't be doing. Again, we want the men and women of the armed forces to be working on tanks that are going to be used, not tanks that are not going to be used. Those tanks should be sold to the local police departments or whatever it is we do with our surplus tanks these days. On that, we were able to find $5 billion in inventory that was able to be repurposed back into the war fighting effort. And you guys know how expensive those wars were. That was a non-trivial amount of money that we were able to put in place. Here's another little one. I'm going to do a quick Dilbert here. This is Ted who comes in and says, hey, can you check my spreadsheet for accuracy, Dilbert? And Dilbert says, it's an intenetrable jumble of poorly organized data with cryptic labels. Ted says, I don't want to talk about the metadata. I just want to talk about the data. I'm going to check it for accuracy. And Dilbert says, I don't think accuracy matters if nobody can tell what it's for. So Ted grabs the paper away from me and says, sheesh, let me explain this simple document. This column is the ratio of product returns to gross revenue excluding sales taxes annualized and is clearly labeled as oh my goodness, what about the other 80 columns? Now I use that as a lead in because many of you remember when Lehman Brothers went under a bank called Barclays Bank bought Lehman Brothers. They had a little challenge around this. It was again a data governance challenge, just an absolutely fascinating story on this. They put together all the things they wanted to buy in a spreadsheet. So again, Barclays is buying Lehman Brothers and they're saying this is the spreadsheet, this is what's going to control. What should be the controlling back? Well, that's a great idea. Until at midnight you hand it to the first year associates and say now make it look pretty. And the associates in the process of doing this turned around and unhides 179 contracts that were previously hidden. They went back to the judge and said, here's the thing we're going to do. And the judge looked at it and said, sales done good. Of course what that meant was Barclays had just bought almost 180 assets that they had absolutely no intention of buying under any circumstances. Governance around this? If you ever go to visit Barclays Bank, they have so many rules governing the use of spreadsheets in that organization. And again, appropriately, given what almost happened here, they actually went back to the judge, explained it and said, oops, sorry, we made a big, big mistake on this one and we really want to undo this. By the way, this is all written up in Flashpoints, which is Michael Lewis' newest book on the topic, fascinating, fascinating book on that. Here's another example of data governance. And this is a burning bridge issue as the last one was. It's one of those things that you just want to keep in mind. This is a company called Mizzouho Securities that in 2005 had a trader that wanted to sell one share of a company called JCOM for 600,000 yen. Most of you know that yen are many to the dollar on here. He, like me, was a little dyslexic, and he sold instead 600,000 shares of JCOM for one yen, which is much less than a penny. Yes, OUCH, and again, OUCH 250 million dollars worth of loss on this. But it gets worse. The in-house system that they had established at Mizzouho Securities had no in-house limit check If she simply had said we don't deal in penny stocks, anything that comes through paying or it's just like having an executive, we're going to pay you a million dollars an hour. Wow, great. Let me have a couple of those paychecks. No, it doesn't work that way. It didn't stop there. It went to the Tokyo Stock Exchange, and the Tokyo Stock Exchange also didn't have limit checking or the ability to cancel an order. Well, these are just crazy things. I mean, absolutely nuts. I don't want to run a business around this. Now, I visited Mizzouho Securities 10 years after the fact, technically, but last fall, and they were still shamed. You know how important it is to the Japanese culture. They were still doing this. 10 years after the fact that they had learned their lessons. They were very anxious to show me all the in-house checkings with them and all the other things that they had around this in their way of calling it data governance. There's another story. Again, governance wise. So, question, remember that we're trying to keep in mind here is what is our strategy? So here's a chocolate company. And this chocolate company has done a really tremendous job of selling its products. As you might imagine, towards the end of the season, on its holidays, everybody starts buying lots of chocolate. Well, would you say that's a good time or a bad time to make a lot of IT changes? Again, everybody's laughing here in the room. Of course, it's a terrible time to go in and make a lot of IT changes, and they have four major projects going on, which meant they were actually delivering the chocolate to the wrong cities that didn't get to the customers. There were five million pounds of chocolate that didn't get delivered correctly. Whether it's pounds in the English sense or whether it's pounds of lean weight, it's still a bunch of stuff, right? So you've got a lot of things that are hanging out there. And what we did on a postmortem was go back and find out why. And again, good governance would have kept these people from making these changes. Companies that are particularly dependent on seasonal activities have a lockdown period, where we're not going to make any changes. Again, for you guys, if everybody bought their mortgages in May, you'd turn all your systems and lock them down in March just to make sure you were ready for May, whatever that particular situation is. Well, the point of this was everybody in the entire company ended up knowing the chocolate story. So five years after the fact, I could sit down in a meeting and start to talk about data governance and somebody will interrupt me. My goodness, and say, we remember the chocolate story, Peter. You don't need to go over that one again. You know when they've got that. They're really getting it. They really are understanding the value of data governance in that particular area. Here's another little animation from British Telecom. I wish I had the music that went along with it. It stopped after a little while. But you can see this is a little email that was sent to all the associates at British Telecom. It says, previously information was stored in a bunch of different places around BT. We've got lots and lots of animation that's going on there. So I say, ah, yeah, it's great stuff. We've got information stored everywhere. What do we want to do with it? Well, it kind of made things redundant. We had so many processes that were matched up and that were doing things. It really didn't make a whole lot of sense. So we're able to go back in and say how do we fix that? Again, I'm catching up here on the screen here. The processes were duplicated. People weren't seeing things. Oh, you're making a wheel, and I'm making a wheel too, right? Just really kind of... And of course, they say in a typical British understated humor, it was all a bit messy. Yeah. And lots of other organizations are suffering through exactly the same process. So the simple message is, we're now starting to sort all of our data instead of trying to keep it around. Again, talking to a group of IT professionals and data management professionals, I can say master data management. You guys go, oh yeah, sure, of course, I understand that. But you have to remember back in these days, people weren't understanding it. So the idea of sorting your data into seven sisters, in this case they called it, they were able to do this. Now, again, this little animation that I'm showing here was sent to every associate. So it's a really nice articulation. It didn't cost them but a couple hundred pounds again to have a good animator tell a fairly complex story on this but very, very quickly and very, very articulately so that they were able to get what was actually happening out of this. Again, the question here, as you're looking at these things, is what is the purpose that you're trying to govern the data for? If there is no purpose, then any decision you make must be okay and we know that can't be the truth. So there's got to be some sort of motivation, some sort of rationale in order to do this. If we don't have those rationale, then anything we do tends to be okay. So I told you a couple little stories around that because it is important to have these stories. Again, you get on the elevator at the top floor, one of the towers, and the boss comes in and looks over and says, Tripp, you work for me. I can see that on your badge. Tell me what it is you do. And the elevator starts to go down. You've got about 30 floors to say something quick and articulate. And if you say I'm the person that fixed the chocolate story, that's a good job, right, because the boss remembers the chocolate story. Or you say we were the ones that kept soldiers from killing themselves or we were the ones that fixed that particular problem with this particular system. Whatever it is we're trying to do, these are the things that we need to put in place so that people can, in fact, manage data as a resource, as an asset that it really is, instead of treating it as storage, which, fortunately or not, has been how we taught you how to do it in schools all these years. So let me finish up here at the top of the hour then with Maslow's hierarchy of needs. Everybody kind of goes, Maslow, wait a minute, how did we get here? So Maslow, everybody remembers was if your food, clothing, and shelter needs are unmet, you're unlikely to work at the top of the pyramid on your self-actualization activities, whether that's poetry, playing music, reading whatever it is that you do, it's not going to happen if you're still scrambling to get warm, right, fed, et cetera, et cetera. And data management is an awful lie like that. We have a lot of things that we call in the golden triangle of data management, master data management, mining, big data analytics, warehousing, so all kinds of really neat things that do work technically, but they work a whole lot better if we understand that those are really just the tip of the iceberg, that that's what everybody wants to have, but you can't have the iceberg tip without the rest of the iceberg that comes into it. And the rest of that iceberg is hooked into these five data management practice areas that you see here, and governance is one of those areas. If governance is weak, and I'm going to add one more little piece to this chain, it, like healthcare.gov and its initial version, drags everything else down. All of these five practice areas, the ones that I showed you on that other diagram, the ones that are in the base of this pyramid here, are all interlinked, and any one of them performing at a low level will drag the others down. So if you have an excellently performing data governance group, and it's performing at a five, what we talked about a little bit while ago, but that your metadata management practices are extremely poor, the overall organization can only perform as well as the lowest form of the weakest link that's in that particular area. So it's an engineering concept that we have to get into management. We have to let them understand that while data governance is huge and important and necessary, it is one part of the overall chain. And people are always asking us, well, okay, I hear you, but can I still do it without it? And the answer is yeah, absolutely you can, but it'll take longer, cost more, deliver less, and present greater risk to the organization than if instead you crawl, walk, and run your way to the top of that particular pyramid. What we're really talking about here is the difference between outcomes, things that you buy as tools and capabilities that we want the organization to have. And we're having just a little bit of a conversation here in the room before we got started. And the simple question asked is, do you think the regulatory burden is ever going to get less? No. So we might as well become good at becoming compliant with regulatory. That's the capability. That has nothing to do with MDM or technologies or anything else. Each of those technologies can be employed and it's the role of the data governance group to make sure that these things are, in fact, correctly deployed. So a couple quick takeaways here. We'll try to get to the questions and answers and things. The takeaways on this are, first of all, the need for data governance is increasing. From two perspectives in particular. One, the volume of data is going to drive us crazy. Again, you've all heard of the Internet of Things. Anybody have a refrigerator that sends an e-mail just yet? Don't worry, you will. By the way, it's kind of a useful thing. You left the door open. I'd like my refrigerator to tell me that. When it starts telling me that I need more beer because somebody just drank the last one now, that may be getting a little too personal about it. We also, though, have a lack of practice improvement, but we haven't established well-done procedures here that we can use repeatedly. We need to work on those in order to do this. The state of governance discipline, even if we say it's 100 years old, is 5,900 years younger than accounting. So again, when we talk about a millennia or several millennia that they've had to establish generally acceptable accounting principles, we know we've got some catching up to do, and that's us to make this particular set of history on this. The data governance piece has to be driven by a data strategy that complements the organizational strategy if it doesn't, what's the point? I was telling Triple Story at lunch today when we had a company call us up and say, we want you to do a data strategy. We said, why do you want to do a data strategy? And they said, well, we don't really know or care, but if we don't do it, we're going to get in trouble. So just write us something. And we said, great, send us a million dollars, and we'll send you a binder that you can put on your shelf. And they said, well, that's not very good value. And we said, no, that's not the kind of project we like to work on either. It can be really useful to compare those data governance frameworks. I went by them very quickly, but they're in your PDFs. You can look at them. All you have to do is say, how would that work if we did it here that way? I don't expect you to take the American Association of Academic Professors and adopt that as your model. There may be ideas in it that are certainly worth looking at. So there's seven of them that I've given you in there to take a look at it. Data governance then directs the data management efforts. They're taking what happens between the time you capture the data to the time that you end up using the data. And of course, we have generally one capture point and many use points. So it becomes a one-to-many relationship in there. But the language in which data governance speaks has to be metadata that you're using the same terms. One of the most important takeaways on all of this is that I never let any of the groups I work with describe a concept as simply as customer. We tried it at VCU one time. Who are the customers of our university? Well, you know what? Anybody a parent? Got a kid in school? Kids in school? Taxpayers of Virginia? Yeah, it's one of the things we got us through the recession because we have a better, more educated academic base here in Virginia than a lot of the other states have. Listen up, Mississippi and Alabama. That's me and I now. Finally, process improvement is the way you improve your existing data governance piece. Again, you're not going to put up the first perfect version of this and it's going to work perfectly for you the whole way through. You're going to try some stuff. You're going to see what happens. And then you're going to evolve it just the same way as data evolves as you're going through this. So we're at the top of the hour here. Again, I've just got a couple more things to put on and we'll move on to the Q&A session. One of the stories you don't want them to tell about your data governance activities is captured so well in this Dilbert. So again, Ted, who says that the committee decided that the file naming convention will start with a date in the order of month, year and day. Okay, they got that part wrong right away. Then a space, then a temperature at the airport and a half-size living here, a squirrel. That'd be perfectly honest. It was a long meeting and we didn't do our best work towards the end there. Clearly, they didn't. But if that's the perception that people have of data governance, they can't see it as a burden. They've got to see it as something that helps out in the organization. And I found a really cute little piece. I forget who put this together. I wish I could remember on this, but somebody actually had time to go put a data governance piece together to Hotel California. Wow. Okay, so we've got a lot going on here. Way too much time on some people's hands. That's interesting. I've got a couple of books out on this. They're very, very thin. Easy to get ahold of them. You can get them through the Diversity Bookstore on this. So again, in your packet here, these are the worst things in the checklist that I told you were in there. In addition to that, I've given you a couple of websites as references, as well as a list of IT governance books in here so that you can do a little bit more Q and A. The next webinar we're going to do is trends in data modeling coming up on October 14th, and we can now move to our question and answer session. So I think you guys in the room will be able to hear this. It's not all repeat the questions. And Megan, we'll turn it back over to you, and I want to apologize to everybody. Shannon's going to tell you in a minute that WebEx crashed on us in the middle of our thing. So that was fun. We missed a little bit of the presentation, but thanks for being patient. And it's your turn now. What sort of questions do you have? If you guys will hold off, we'll get these. Megan, you're still there? Yep. All right. Thanks, Peter. That was a great presentation this time though, wasn't it? I know. There's a little trouble there. Now it's time for Q and A. As Peter said, it's time for you all to ask your questions. So just click on the Q and A window feature. It's at the top of your screen. You should be able to submit your questions through that window. And it looks like we've had a few come in. So we go ahead and get started. First question is, how can I get data governance policies and processes clearly understood by the entire organization? Okay. So the first question is, how can I get data governance policies and policies so they are clearly understood by the whole organization? Great question. Because you can imagine, take yourself out of IT and put yourself in the business. And you've got a job to do. And you come in every day and you do your job. All of a sudden somebody's bothering you and knocking on the door and going, I got to talk to you about data governance. And you go, why? Well, if you can actually answer the question, why, with, remember the chocolate story? Oh, yeah, that was bad. We don't want that to happen again. Okay, I'll always give you five minutes of time to listen a little bit to what data governance is. In other words, we're not going to get this to work by top-down command and control, by saying you must pay attention to data governance. Remember how well that worked for TQM? Anybody have to live through TQM? None of you guys? Oh, you guys got lucky. Unless everybody else in the world have to go through and live through TQM. So you've got to attach it to a story that is related to your strategy. If you don't know what your strategy is, any road will take you there. But if you've got a strategy that says we need to do more with our existing customers, because everybody knows, if you do more with your existing customers, then it is to go out and get new customers. Great. So what should the data governance strategy be relative to that? Well, it should say something about customers, shouldn't it? I'm not doing something with the existing customers. I'll use an analogy here. And again, it's sort of a definitional thing, but it's something that Claude Finkelstein taught me a long time ago. When we're doing data, we tend to do a lot of definitional work. What do you mean by an employee? Here's the definition of this particular thing here. Here's the definition. Those are good. Better, though, is instead of putting out a definition, let's put a purpose statement into the model. Because the purpose statement speaks back to that motivation and strategy component. We're keeping the information on people's shoe size because we might, in fact, Monday want to sell them shoes. Okay, and you guys are going home. But if it's part of your strategy, you'll get it. There was a rumor for a long time that Capital One actually kept their customer shoe sizes. I don't think it was ever proven to be true in there, but it still was an interesting rumor that came out. So the key, of course, to making this relevant to people is tying it to something and also having a burning bridge. And I'm not urging you to go out and manufacture a crisis just for the purpose of having the crisis. Life happens as it is, and we have enough things that go on. But find one of them. Show how it was related to a data governance crisis and show how data governance would have corrected that. And more importantly than just do that, put it up on an internal website where only you guys, but the people you want to see, can see that particular instance. So while you're sitting on one of these boring webinars, people will be clicking around and doing other things and they might run across these stories. Or better still, eventually somebody's going to come along. Some of you are old enough to remember this, but how did we in the old days decide whether a report was still being used or not? And the answer was, we'd turn it off. And if nobody complained, it must have been the right answer. You think I should have said that. The problem with governance is that so many of the governance initiatives are intersected because they are not tied to the strategic drivers of the organization. And consequently, when it comes along, it's like, well, I saw that come along and it was here for a while and then it went away. So it must not have been important, right? But if you say this is related to the chocolate story and everybody in the company knows the chocolate story was a bad thing that happened and they want to keep it from happening, that's the way to get people to pay attention to it. So you have to have a very simple question. It's a very good one. But it needs to have that grounding and strategy and you've got to have some sort of a story there. Even if it's just a simple thing like an elevator speech when the boss gets on the elevator and says, so what is all this data governance stuff I'm hearing about? And you say, well, yes, sir, you know the last year when we let 600 mortgages go out the door without full signatures on them? This will keep that from happening again and they'll go, okay, good answer, right? Thanks, Megan. Next question. All right. And the next question is, what is your view on the relationship between data governance and information governance? So the question is what's the difference between or my view on information governance versus data governance? I get that question a fair amount what people are saying, are we managing data or information? If you go to the proper definition, a data is a piece of a fact that is paired with a meaning. So if I throw out the number 42, who knows what the number 42 means in this room? Some of you are going, yeah, life in the universe and everything, right? So we happen to both have read the Hitchhiker's Guide to the Galaxy, which said the answer to life in the universe and everything is 42. The rest of you are going, what? Well, 42 was my age 13 years ago. Do you care? No, but it's suddenly another combination of fact and data. What's the difference between data and information? All we're doing now is adding a little bit more metadata around it and putting the word request in there. I've actually got a little diagram that shows this in more detail when we pull that up here while we're talking about it. So the key there is that if you are managing data and information separately, it's a really bad idea, and that you get more synergies from managing them together than you do managing them separately. So if you can keep that in mind that if somebody's trying to manage your data and information separately, they're going to spend a lot more time trying to figure out what is different, where the differences are, who does what to whom, and all the rest of the things. Then if you simply say, we're going to manage our data and information in a combined fashion. Again, here's the little slide that talks about it. Here's our data. There's our number 42. There's our facts and meanings. And we add to that request, and that now becomes information. If you try to manage them separately, you will spend much more time defining and running around and having confusion that you just say, we're going to manage it all together. There's one more layer that I always add on to this as well, which is to understand what your strategic use of data is. Really, we talk about the word intelligence at this level. It's really saying that our first guess at the requirements of the organization are probably going to be mostly correct, but not perfect, and that until we iterate on that process one, two, or three times, we won't really get to the fine tune part, and that's where we really get to business intelligence. Yeah, I've got information on the shoe sizes of our customers. Great. How's that going to help us stay in business? I'm not sure, but if I have a pretty good idea, as the Vodacom company does in other parts of the world, that when I look at your bill and your usage patterns on your phone, and I could predict that within four months you're ripe for switching, where the competition will try to come and pluck you away, it's a good time to send them out a coupon and say, hey, we love you here at Vodafone. We don't want you to get tempted by the other guys who are trying to get into this particular space. So I'm very defensive about that. I've seen a lot of organizations try to manage data and information separately. It's much more trouble than it's worth. Again, long answer there, Megan. Let's have the next question. Oh, shit. Great. And the next question is, what metrics do you think companies should use to measure data governance program effectiveness? That's a great question. What metrics should you use to govern this? And I do actually have a slide on that, but I'm going to go very quickly by, but let's go back to it. So first of all, you can see it through the deck and talk a little bit about it. The metrics that we want you to look at in there have to do with things like the number of decisions and the impact of those decisions in the organization. It has to do with the number of deliverables that are produced. It has to do with the effectiveness of the organizations. So here are just some of the measures that you can put in place looking at data governance deliverables. Again, do you want a 300-page data governance manual? No, because nobody's going to read it. Is it possible to put in place a couple of paragraphs that describe the sense of how the organization is going to use data for the next phase of its existence? We know that that will evolve over time just as the nature of our business evolves over time. Do we want to have a million data standards? No. Do we want to keep track of the number of issues that we've resolved? Yes, that's actually a really good place to look at it. Do we want to look at how data management has been helpful in identifying things? One of the measures that we like to look at in organizations is that it turns out that most data in most organizations falls into the category of ROT. ROT stands for redundant, obsolete, or trivial. And if you're dealing with data that is redundant, obsolete, or trivial, why are you spending any organizational resources to manage it at all? So part of data governance is getting rid of the ROT. Now, again, the comment was made that our data is in a bunch of different places around there. The average organization has their customer data in 17 databases. So if you're above that, you're below average. If you have your data information stored in only 10 places, you're above average. Standards are pretty low in this area, aren't they? Another thing that you can do is to quantify the quality of the data that you have around there. And we had a real interesting one in the state government the other day. I got to tell a story last night in front of the Secretary of Technology. They had a data set over one of the departments that everybody said it sucked. Well, that's not a very operational term, is it? And one of my friends got hired into there, and she said, what do you mean by sucked? And I said, I don't know. It's just how I heard about it. Here's the data set. It sucked. So she went in and measured. And it turned out this data was 98% accurate. All of a sudden, everybody's perception, because they knew this data set, went from, oh, wow, it doesn't suck. Or maybe it's still does suck. Maybe 98% isn't good enough. Again, we get back to the strategy. What are we trying to use the data for? If this is the data we determined to get your credit scores or whether you're worthy of a mortgage or something along those lines, then you want it to be pretty accurate. On the other hand, if it's the last 10,000 customers that you've had from 1990, how do you let it go on there? So again, from a governor's perspective, it's changing the data sucks to the data is 2% inaccurate. And then we can have a really good intelligent conversation about is that good enough? Because if 2% is not good enough, then we need an initiative to go in and try to make that to go to 99% or whatever the particular strategy value is on that. Again, great question. Thanks for asking, Ellen. All right, great. And the next question is how about value propositions associated with data governance? How can you qualify and or quantify value benefits with no baselines? Well, you just asked a very interesting question. So the question is how do you quantify these benefits without any baselines? Now, again, if we were in accounting, we'd have a lot of very good set of baselines because they've been around for 6,000 years doing this. Dear, it looks like it cut us off again. I have no idea. Can you hear me, Megan? Shana? Anybody? I can still hear you. I can hear you. Okay, we'll keep the audio going then that somebody didn't crash again, I think. It's always going to show a... You on your end. Yeah. I hope it doesn't knock everybody else off. That's the thing. I think I still see people out there. Megan, what was the question again? I'm sorry, I got distracted by crash. Don't give me one second to bring it back up. Hold on one second. No worries. Let's see here. Can't actually bring it back up now. Can I repeat the question? I'll go down the line. That's right. Thank you. Chris here in the room told me what it is. How do we do baselines? Okay, so first of all, one of the books that I love, and I've written nine books, I've actually sold more of this guy's books than anybody else, it's called How to Measure Anything, like I'm in Douglas Hubbard. And it's a phenomenal book that talks about finding the intangible value in the intangible thing. So I'll put that out there as a, which you guys should definitely look at if you're having trouble with it. But the most important thing is, remember George Fox's comments about models. All models are wrong. Yeah, the caveat though. Some models are useful. And if you think about it from that perspective, starting off with a wrong baseline is not necessarily a bad thing if you incorporate into your process of measurement a way of going back and evaluating it. So you might start off here again and say a credit score of X is required in order to have a product Y. Try it for a couple of years if it doesn't push out of business, right? Then you can adjust it. Say maybe the credit score is too high, too low, or maybe we should add felony convictions in there as well. Make it stuff up here on this. But the point is, because we don't have a lot of baseline standards on this, it doesn't mean that we can't start inventing them and, more importantly, coming into forums here like the Data Diversity Forum so that we can actually use this stuff and share it. And I think we do have a webinar coming up that's going to address some of the topics. So again, another good question. Thanks, Megan. All right, great. And the next question is, what business line would you see as the logical owner of data governance? So the question is, what logical line of business should own the data governance function? I was mentioning to these guys here in the room that Capital One, who's a very interesting company and fairly innovative, has just taken their data governance function and moved it under the Chief Risk Officer. So they decided that it was not appropriate and was not being served well enough by IT, and so they moved it from there to their next spot. Now, whether that's the right spot where it should stay, I don't know. My own thought is that because data is an evolutionary process rather than a creation-oriented process, we're not building new data sets each time we do this. We're trying to do things more with our existing data set. Because it evolves there, it doesn't fit well into an IT project management paradigm. And so I really don't want it to be managed by somebody that only knows a project paradigm. And this has been one of the flaws that we've had in teaching people about project management, is that there is a higher level structure than a project. What is it? It's a program. Data really is a program that works in the organization and should not and cannot, in fact, be properly managed as a project. That said, you can take aspects of that program and then manage those aspects as projects. But data from a management perspective anywhere except IT is my answer to that, which doesn't make me a lot of friends in some cases. But hey, so you wear funny shirts and do strange things like I do. Megan. All right. The next question is, what metrics do you think companies should use to measure data governance program effectiveness? So the question is, what metrics should a company use to measure the data governance program? And the first thing I would start out with is awareness, just to make sure that people do understand the data and the aspect. I mean, again, if you ask your HR director, what are they going to say the most important aspect of any organization is, of course, our people, right? And if you ask the chief financial officer, what are they going to say? The money, right? And if you ask your chief risk officer, they're going to say our ability to manage risk. There's nobody advocating for us up there at the C level around this. Your CIO is never going to say, our data is the most important thing. Actually, I should qualify that. One in 10 CIOs actually said that. The rest of them are much more enthralled with their systems and the technology that they have. And there's nothing wrong with their systems and technology. It's very, very good and it works and it's necessary. But the data is going to persist long after the technology goes. So we really do need to have an advocate there and working at that level as well. All right. Great. And the next question is, how would or could you monetize a governance program? Is this a sunken cost or a recoverable expense? Gosh, you just set me up for these things. So the question is, how would you monetize your data governance program? I have another book out on that and it's got some examples. So again, you guys can certainly take a look at the monetizing book. But the key for it, and again, I'm going to take a non-monetary example and just take you back to the military suicide problem. The last thing you want is the military or people who are young men and women that go into the armed forces, thinking that nobody cares about them after they've done some of the things that we've asked them to do. So from the military perspective, it wasn't about money, it was about lives. But it's about saving lives. The military, I want to say, it's almost a deadly theory. It's idiotic to say that. They're very serious about trying to save lives in there. We can do the monetization thing. We can find how this is. But you're going to have to participate. It doesn't happen by itself. There aren't hundreds and hundreds of years of history to do this. You've instead got to say, what does governance mean for our organization and how can we use governance to do our business better to make our bosses look good so that then our division will still be around and all the rest of the games that we have to play in corporate. But eventually, you will start to see that this part of the organization, implementing data governance, is performing differently from this organization, whatever it is that's performing without it. You can even take it into your IT development processes and look at the data-centric development processes versus the application-centric processes. The data-centric processes will show higher data reuse and lower application development costs than the other ones will do. All of these things are very important. You're going to have to find something that works for your organization in order to make it a very good case for it. All right. The next question is, how does one justify the cost of maintaining and developing metadata when it is considered a common good? The question is, how does one justify maintaining metadata when it clearly exists for the common good? Well, I'll tell you about a project that we worked on for one organization, and this organization has a lot of people in it, and each person in that organization is valued at $60,000. So we just said, any of your time, we're going to charge out at $60,000 annually. And we had an opportunity to make a case for a metadata repository. We said, if we could save just 15 minutes a year for the entire workforce by providing some standard definitions that they didn't have to go search for and could, in fact, put their finger on because it's right there on the intro web for them, what would that look like? And 15 minutes per year was about 10 times the cost of the investment in the metadata. So very, very easy business cases to make. Again, you heard me say it earlier. It was the last bullet on the second to the last slide that I had. The language of data governance is metadata. So if you can't really do data governance if you're not doing metadata, it's just a completely unproductive exercise around there. All right. Great. I think that's all the questions we've had come through so far. Thank you, everyone, for participating in today's event. We hope you've enjoyed it. Thanks again to Data Diversity and Shannon for hosting us. Once again, you will receive today's materials within the next two business days. And our webinar next month will be Trends in Data Modeling. Hopefully you'll be able to join us for that as well. As always, feel free to contact us if you have any questions. Thanks, everyone, and have a great day. And Shannon, thanks so much for getting us back up and running. So quickly, that was just a terrible crash. We've never had that happen twice. I know. We really apologize to everybody, but we'll do better next time, right? Yes, absolutely always. And I think we've got it sorted out so we can definitely prevent it from happening next time. So, again, thanks, everyone, for your patience and for hanging in there through the webinar. We really appreciate it. Definitely not the way we like to produce webinars. So, and Peter, and of course, despite the interruption, it was a great presentation. So thank you very much for that. And I hope everyone has a fabulous day. Thanks, Shannon. Bye-bye. Thanks. Bye.