 Welcome. My name is Shannon Kemp and I am the Chief Digital Manager for Data Diversity. We'd like to thank you for joining today's Data Diversity webinar, Data Governance Strategy, sponsored today by InfoJix. It is 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. He 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 bottom middle of your screen 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 highlights of questions by Twitter using hashtag data ed. And to answer the most commonly asked questions, as always, we will send a follow-up email to all registrants within two business days, continuing links to the slides. And yes, we are recording, and we will likewise send a link to the recording of the session as well as any additional information requested throughout the webinar. Now, let me turn it over to Jonathan for a brief forward from our sponsor today, InfoJix. Hello, and welcome. Thank you very much, and welcome to all our attendees. So I'm going to give a little bit of an introduction to Pita's presentation here, and really just some observations on the strategy challenges as we see it. I'm going to start off with a bit of an infomercial, just to keep it to one slide, but I work for a company called InfoJix. We've been in the data business since 1982, which is a little hard to believe at times. The world has changed remarkably since then, but over that time within the data governance and data quality spaces, and always in the data analytics space, although that means something totally different than what it did in 1982. Back then it was more of an accounting definition, reconciliation, and so on. Nowadays, we're really looking at the analytic functions as they support data quality and data governance and so on, so not the broader scope of that term. Larger midsize customers for the most part, and in general our folks have been with us on average of 18 years, so we're very proud of that across a number of different market segments and so on. So that's just a very brief overview of InfoJix. We go to the next slide. What I thought I'd do is just really focus on, if you go to the next slide, Pita, just some observations as they relate to strategy, and this might help ground the discussion, might help you think about kind of where we're going here and maybe resonate within your context. But as I was thinking about this, I just thought, you know, okay, governance strategy, you know, for a lot of our customers, strategy happens the second time around. The first time around, governance is all about solving some kind of pain. At some point, people step back and say, how do I scale this? And then they tend to run into challenges, and that's when you see a lot of these failed programs. So strategy is something that needs to be addressed, and quite often that's on the second time around. Secondly, you know, little grounding in the reality of business-related business proposition. The strategy is going to help you out in this perspective. It is so easy in the trenches, if you're a data steward, if you're in a curation, if you're labeling data, you know, in the trenches to really remember and keep in mind why we're doing this, right? And a lot of the folks and a lot of the teams that are practically engaged, you know, that's what I see. And of course, people lose interest, they lose energy and so on, lose focus. So the strategy helps there. Thirdly, you know, as I'm looking at the strategy, a lot of folks don't question their operational model, right? You know, who's meant to be doing what, for whom, why, with what tools, that kind of thing. And as you're doing that strategy, you're really forced to think these things through, right? You know, reality is not always the same as strategy, but the strategy forces you to pull back and really focus on those. And lastly, I would say in tons of general observations, there's a long trail of words here, right? There's always that person on the team that's been at the company forever. They've, you know, they know every reason why governance hasn't worked for the last 20 years, and they're more than happy to communicate to you around that, right? So those people can be assets, they can be liabilities. You know, you've got to find a way to communicate with them. And the strategy is a good way of saying, look, I get it, but here's what we're doing, here's why we're doing it, and here's your role, et cetera, et cetera. So, you know, for me, a strategy is critical. It ties all the pieces together. I'm looking forward to hearing Peter's thoughts. So I've got one more thought. You know, Peter's got to talk about Dahma Dinbar, we go to the next slide. And, you know, there's a lot of frameworks out there, right? And what does good look like? I find that the frameworks are really good to help me look smarter, maybe more knowledgeable than I actually am, which is always helpful. But there's a lot of frameworks out there. And I include, you know, GDPR broadly speaking, but some of the ISO things, BCBS 239 risk data aggregation, if you're in the banking world, APQC and SCORE, if you're in supply chain management and so on. And you've got to tie those into your governance framework, right? How do they fit into the governance framework? Some level, quite easy, but those really go down to the data level. And so I tend to rely on Dahma Dinbar and CMMI's data management maturity models as frameworks, as sort of my key references. Because at the end of the day, you've got to drive that down to the data level because that's what we're managing that sort of underpins a lot of these best practices. And I think Peter did a CMMI webinar a month or so ago. So between this one and that one, probably have quite a good reference there. So with that, Peter, let me hand it off to you. Looking forward to your thoughts and we'll have some Q&A afterwards. Jonathan, you'll be joining us for the Q&A afterwards too, right? Yep. Yep. We'll get everybody in there. You bet. Sorry, Shannon, didn't mean to cut you off. No, no, perfect. That's exactly what I was going to say. Awesome. Yeah, so yeah, thank you, Jonathan, so much. And thanks to Fidget for sponsoring. And as mentioned, if you have questions for Jonathan, he'll be joining Peter and the Q&A at the end. And now let me introduce to our speaker is 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 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 11 books. The most recent is your data strategy. Peter is experienced with more than 500 data management practices in 20 countries and consistently named as the 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 as diverse as the U.S. Department of Defense, Deutsche Bank, Nokia, Wells Fargo, the Commonwealth of Virginia, and Walmart. And with that, let me turn everything over to Peter to get today's webinar started. Hello and welcome. Hi, Shannon. Jonathan, thanks for a great introduction, and we are looking forward to engaging you as we get to the end of this because one of the things that's real important to remember for all of us is that unlike the accounting profession which has literally 8,000 years of tradition in it, we do not have that. So when Jonathan says he's been doing this since 1982, my own company, Data Blueprint, I only formed that in 1999, and that was before Google. So Jonathan was before Google if you want to go that way on all of that, and we'll look forward to circling back around and catching some of that. But what we're going to cover in the next 55 minutes here are four major topics. First one is that Data has some very confounding characteristics. It's got some really good and some really strange aspects of it. It is uniquely valuable in a way that other types of assets are not. It's largely composed of rot, which if you hold your breath, we'll get to that. So I'm going to make a case for making better decisions about data which is really an important part of governance. We'll talk about three specific strategies. The first one, as Jonathan said, strategy usually does come the second time around. Wow, we can't really boil the ocean once they realize how big the ocean is. Like I said, the discipline is immature and by the book is not really a good starting place. So we need a more targeted approach to data governance. Second strategy is that data governance has to exist at the programmatic level and I want you to tie that in your organization's minds. By the way, I say you, you the delegates on this call are responsible for going to your management and communicating this stuff. If you want some help, call Jonathan and I and we'll be glad to help you out on it. But data governance is central to data management as a practice and it must be decoupled from IT strategy and directly supportive of the organizational strategy. And our third strategy then is gradually add ingredients. So things like frameworks, stewards, checklists, scorecards, we'll go briefly through a bunch of these things, finish up with some worse practices and if we've got some time, we'll talk a little about storytelling at the end so we'll see how fast I babble and work our way through this. Let's start off with data's confounding characteristics. First of all, IT thinks data is a business problem. If they can connect to the server, my job is done and I have heard that phrase from a large number of IT people. This is not a bad thing, but it's the way they have been socialized and taught and more importantly rewarded for doing their jobs. Well, if IT thinks data is a business problem, they're not going to do anything beyond say, I've given you access to the data and now my job is done. Of course, business thinks IT is managing data perfectly adequately because after all, who else would be taking care of it other than somebody with the title Chief Information Officer? This means that data has fallen into a large gap between business and IT and collectively our mission as data professionals is to rebuild, re-establish the trust that needs to be there. Now, as a topic, data has some very confounding characteristics. It's complex and detailed and besides the three of us on this call and the thousand of you roughly otherwise that are out there. In addition, outsiders don't want to hear or discuss any aspects of this. It's just not terribly interesting to them and quite frankly, most of them are unqualified because they don't have the requisite architecture and engineering backgrounds. In addition, in most college and university courses as well as private courses, it is taught inconsistently. The focus is largely on technology because technology is easier to teach than what we're talking about in this webinar. And in virtually all instances, the business impact is not addressed. And finally, it's not really well understood, which means every workgroup in your organization has had to learn about this because there's a lack of standards and poor literacy rate and their very unknown dependencies. Now, I showed this little clip here and I'm going to put this up and just give you guys a little bit of some good work but maybe not the right kind of work. Now, that guy's great, right? But if his challenge was to go off and learn how to play the piano, there are ways to do it. And unfortunately, this is what's happened in your organizations that everybody in your organization has learned how to play the piano in a different way because of the lack of standard practices around it. And it's probably not a news flash to most of you, but half of all companies report making bad decisions. And the reason they make bad decisions is because the business decision makers are not data knowledgeable and the technical decision makers are not data knowledgeable, bad data decisions lead to poor treatment of organizational assets and poor data quality, which leads to poor organizational outcomes. And of course, we have to get ourselves out of this particular spiral. Now, in terms of confounding characteristics, one of the really interesting parts about data, I mentioned it before, is that I hope you agree that if data is better organized, it is increased in value. For example, if I were to give you these slides or Shannon were to send you out the slides at the end of this webinar I would probably get a little confused and perhaps a little frustrated and say, Shannon, what's the deal? And she said, well, the data is all there. You can figure out how to do this. After all the slides are numbered, all you have to do is take them and put them in order. Well, that's not value added. So these poor data management practices are costing organizations a lot of time and money. And 80% of the data in your organization authoritatively is rot. Rot is an acronym standing for data that is redundant, obsolete, or trivial. Because it means your knowledge workers have to wade through a large amount of it. By the way, my wife corrects me on that. She says it's redundant, incomplete, obsolete, or trivial, but rot's a better acronym than riot. So the question comes up, which data needs to be eliminated? It means governance is largely about reducing the rot, recycling the stuff that is good, adding good practices to it, and re-using the remainder so that we have fewer vocabulary items and we can engineer the rest of it for better leverage. Now, data as an asset is a fascinating asset because it's the only asset you have in your organization that is non-deletable. Excuse me, I said non-deletable. It's absolutely deletable. It's non-depletable. That's the word I was looking for. It is non-degrading, and it is durable in nature. Durable is an accounting term back to our 8,000 years of accounting history on this. And at the strategic level, data assets win when they compete against other assets because other assets don't have these characteristics. People wear out, buildings wear, and most of the time our transactional data is not nearly as durable as we'd like it to be. So everybody wants to say things like data is the new oil. Frankly, I can't stand that phrase. It's a terrible way to think about oil because you never think about what happens to the gasoline after you put it in your car. And yet, data needs to be reused. So the best way to think about it is when somebody says data is the new oil, say, can I correct you on that? And just put the word, just give me the letter S in front of it. There are two things about S soil that make a little better metaphor for this. First of all, you don't just randomly run around your yard and sprinkle seeds all over the place and expect good things to happen. That's not the way it works. And secondly, you don't plant tomatoes on Monday and expect to harvest them on Friday. So timing and care and preparation are two things that go well thinking about data as the new soil. Bacon, that's okay, too, as long as we can get people to talk about it. But the bottom line is that data deserves its own strategy. It deserves attention that is on par with similar organizational assets, and it deserves professional administration to make up for past neglect. Now, bad data governance costs organizations millions each year. Productivity, redundant and siloed efforts, poorly thought out hardware and software purchases, delayed decision making because they're using inadequate information, spending too much time reacting instead of being pro-acting. And finally, eliminating 20 to 40% of all IT spending through data governance. So those are pretty interesting characteristics. Let's move directly into the first strategy. And the question pops up. What is the world's oldest profession? I've already told you, it's accounting. Again, it's been around for 8,000 years, and the most important aspect of that is that we now understand that there is something called generally accepted accounting principles. And those principles are absolutely key to understanding how organizations do this. Again, we go to maybe 150 years if we do it. I look at Lady Ada Augusta King. She is the daughter of Lord Byron and the world's first programmer. She invented programming before computers were invented. So let's take our 8,000 years of generally accepted accounting principles. And by the way, they haven't been around for 8,000 years. And let's look at seven definitions of data governance. And I'm going to put these all up here on the board. We look at them and it's like, oh my goodness. Whoa, what does all this stuff mean? Even our own DIMBAC, the exercise of authority and control over the management of data assets. Good definitions, all good definitions. No problem with any of them. But I prefer a better way to introduce it. The way to explain data governance to people is to think about how you're actually going to do the work. And I'll do a quick little Dilbert here just to illustrate it. The committee, says Ted, decided that the file naming convention will start with the date in the order of month, day, and year. Of course, he's got that wrong already. Then a space, then the temperature at the airport and the high hat size of the nearest squirrel, to be perfectly honest, it was a long data governance meeting and we probably didn't do our best work. Well, you don't want people to think about data governance as something simple that they can think about. Managing data with guidance. Now interestingly enough, the first question people ask then is would you want your soul non-depletable, non-degrading, durable, strategic asset managed without guidance? And the answer is probably no. So we go back to managing with guidance and frankly we really need to add one more word in there. Managing data decisions with guidance. So let's take a look at how that works out. First of all, hopefully this is not the first time that you've seen our Dembach wheel, but you'll notice that governance is central to that wheel. We publish this in 95. We've made a revision to it. This is the first version. There is a second version of it out there. These are good efforts, but you'll notice that governance is central to each and every aspect of data management around here. And this is really key. Now I mentioned earlier by the book was probably not the best way to take a look at this. And by the book says that your governance should take a look around metadata and data quality and BI and master data and data acquisition and database strategy and document strategy and ... No. No. No. It's too much. And especially as you're introducing something new to this. So as Jonathan was saying earlier, pick three things. We like to look at a balance. So maybe a first component of data governance might be to look at the connections that exist between data quality and reference and master data management. If you don't know what those are, we have webinars covering each of them. So just stay tuned and they will roll back around on this. But the idea is governance is key. It's a necessary but insufficient condition for successful implementation of either quality or master data references. And that's one example. We can take a second example of that as well, which is maybe that we've now moved from there into sort of a BI kind of situation. And again, notice we're exercising different wedges of our DIMBOK PI, but the data governance still continues to be absolutely central to this. Now to look at data governance from an overall perspective, this is the way that DIMBOK version one described the environment of data governance. So you can take a look at this, you'll get these slides. As Shannon said, we're not going to cover everything on here, but it's a nice input-output process diagram showing you what it is you need to do to do the same things that we already do at the corporate level. Corporate governance does exist in all organizations. And with respect to IT governance, very, very useful equivalency constructs. If we're going to govern our corporation and we're going to govern our IT, then we probably ought to be governing our data as well. And let's start out by being very practical about the process. What does data governance mean to my organization right now? There may be other times when it means other things, but at the moment, let's focus on one aspect if it means managing data with guidance, getting some individuals whose opinions matter. We do need to do some social engineering around this to form a body that needs a formal charter, a purpose and authority, who will advocate, evangelize for, try to avoid words like dictate, enforce, and rule to increase the scope and rigor of what we call data-centric development practices or more commonly known as data-centric type things. Let's take a look at how they work in common. First of all, if we've got a governance organization, they are supposed to be managing data with guidance. Well, where do we start? One of that is your data strategy is going to tell you what is the first bite of the apple or maybe a better metaphor, the first bite of the elephant. I'm not advocating eating elephants, but you know what I'm talking about with the references here. What do they do to support strategy? And the feedback from that is how well is the strategy working. Now, a data strategy is absolutely context-less unless you have an organizational strategy as well. An organizational strategy says what is the data doing to support the organizational strategy. If it's not supporting organizational strategy, one might ask the question, why is one doing that? Now, at least in Peter's world, I say that data governance also prioritizes IT projects, and I've got a large number of organizations that have achieved success with that by creating that as a clear part of their data charters. It doesn't make it easy, and sometimes we end up with some unhappy people as a result of it, but it is definitely working well. We'll add some feedback loops in there just to make a more complicated diagram here and then I'm going to simplify it now. Let's just take the real important parts of it out here. What we're really talking about is that data strategy and governance has to be about achieving specific business goals and that the language of data governance has to be metadata. If it's not, one might ask the question, why did these things go off the rails? As Jonathan referred to earlier, the answer is because people tend to start talking about things that are not directly supportive of organizational strategy. A quick definitional difference here. Data governance tends to exist as a policy level of guidance, and data management is the implementation of it. You might have a policy that says all information not marked public should be considered confidential. That's a perfectly reasonable strategy in order to do that. In fact, in the federal government, they've recently been told that by law. So as of July 14th, 2019, all data in the federal government that is not sensitive data is now going to be considered open data, and that's going to be a big change for everybody. The process of how to get there in the federal government and everywhere else is the data management function, and that's the component that we're going to look at as well. Let me show you, though, a little bit of how these two work together. Now, DIP is an abbreviation for a data improvement project, which is something that the data governance and the data management organization are agreeing to put together to get started. I may start out with not really a lot knowing some sort of vague feedback and a data leadership position may come along, and they may say, we need to do some data governance, and that's policy, and that'll start to improve data over time. It's a slower approach to that. But we also need, from a day-to-day leadership perspective, to implement some specific improvements, and that's a faster approach as we go through this. That gives us better feedback, and when we have that better feedback, we can then start to implement more aspects of data governance. For example, putting in place a class of people whose job it is to be trusted with the data. That's what the definition of steward is. And those stewards may have some contacts in the data community that they can influence and help to make their jobs easier, and those data community participants interact with other people, so we've pretty much got the entire organization there. Eventually, we'd like to have a two-stage process where data improves gradually over time through better guidance, but the data improves more rapidly in response to a burning bridge incident that may actually be faster. Where we've had trouble in the past is that that sort of wavy set of lines there between data things happen and organizational things happen. That line is not always as clear as it could or should be. And that's a place we've got to get better as data professionals in order to do this. Both Jonathan and I have had many, many years of helping organizations understand that a change at the data input level, for example, forcing hospital employees who are taking in patients, they shouldn't actually optimize for speed because we did run into a hospital at one point that thought they were doing lots more knee surgeries than they were because the default hospital admission code was knee surgery, and the hospital director thought that the hospital was being managed according to data. So a little bit of a context here. We can't rely on simply the top line to improve data quickly, and we don't want to do just the bottom line. We need a balance between the two of those pieces. So that's strategy number one, keeping data governance practically focused. Let's move on to strategy number two now. Data governance has to exist at the programmatic level, and what I tell people is to equivalent it to, that's a terrible word. Let me say that again. Make it equivalent to, in everybody's mind, your HR program. Nobody in your organization is sitting around and saying, hey, I think we've done enough HR. We're never going to hire anybody else. We're not going to have any internal problems. We'll never have any regulations that we have to respond to or new laws that we have to implement. So all of you HR professionals can pack your bags and go home. It just doesn't work that way. HR is recognized as a valued part of the organization that needs to exist as long as the organization needs to exist. And you know what? Your data governance program is exactly the same. If you don't understand or your organization doesn't understand the difference between a program and a project, your organization is likely to be one of those ones that Jonathan said is going to need to come around and do it at least a second time. I've been in some organizations three different times to get them up and running in order to do this. So let's take a look at how this manifests itself. It's really sort of problematic because we need to understand that data governance being central to data management means that the way most organizations have been doing things is simply wrong. Now, the way it starts out, it seems very reasonable in support of strategy. Oh, by the way, I should say happy birthday to Doug Bagley, who's our originator of this diagram. A friend I met a number of years ago, about a decade ago actually, and just noticed on LinkedIn, he had his birthday the other day. The organization starts out with strategy, and they do some IT projects, and data and information is kind of like the last thing that they think about. Well, if your IT project involves a piece of software, as soon as you start talking about software, the entire project becomes about the software, and we tend to spend all of our money on software, and then we fork with the data into the new system. This is a problem. Dave McComb has a wonderful book out this called Software Wasteland, and some of the points that are made here are very similar across everybody's domain in this area. It ensures that the data will be formed around the applications, and not around organization-wide information requirements. The process architecture that's created when you do this is narrowly formed around application support, which means very little data reuse is possible. Now, that's the wrong way to do it. Here's the right way to do it, and you'll notice there's not much changed. All I've done is flip the data and the IT box is on there. But it's a very important flip, because if I put data next, that means that the data assets can be developed from an organization-wide perspective. The system supporting the organizational data needs can complement organizational process flows, and most importantly, we can maximize use of information and data along with. Again, good, bad, very easy to see the difference. Strategy data, as opposed to strategy IT. But you can see that's going to upset some apple carts and make some people a little bit unhappy. It gets worse. Again, from a governance perspective, many organizations say we've got an organizational strategy and an IT strategy, and then we've got our data governance strategy down below this. Well, again, this is just simply wrong. And if you allow organizations to do this, you will achieve not-as-good results too. The correct way to look at this is that IT strategy and data strategy are co-equal in this case, although I'd like to pull an animal house here and say that the data strategy is a little more equal than the IT strategy. The key to this is understanding that data is not a project. Data being a durable asset is something that we need to have. We need to understand we're managing these assets with a useful life of much more than one year. In fact, one of the key measures to all of this is called customer lifetime value. Well, how long is that data going to last? The lifetime of the customer. Reasonable project deliverable times for a project are 90 days or maybe two weeks if you're in an agile mode of somewhere, but data evolution is measured in years and in many cases, decades. This is a hard sell to management. We're going to buy into a process that's going to take us five years to make up for vast problems in this to start working in the future because data evolves. It is generally not created. We grab it from other places. And as an organizational asset, it is significantly more stable than other types of organizational assets. For example, I have a number of organizations where literally I have gone back to them after 20 years and we've taken our conceptual data models and our logical data models that we've built and looked and said, yep, we are still managing exactly the same types of data that we were managing 20 years ago. Which means it is more than worth the investment that needs to be made in this. The key is if you start building IT components and you don't have ready-made data architecture components to put into those. These are a necessary but insufficient prerequisite to agile development and the only alternative is to create more data silos which means you'll be either Jonathan's customer or mine or maybe both at some point in the future. Data programs must precede IT projects because IT is a build, a project-oriented type of discipline. Whereas data evolving over time means that from a structural perspective, we need to separate, make it external to, and precede systems development activities. And we don't teach it this way in school. So we've got three generations of students who have been taught incorrectly in their college and universities and you wonder why we have so many projects that literally go off the rails. Our third strategy then is to take a look and gradually add ingredients. And this one is more important because so many organizations like to figure out exactly what they're going to have and they think they can forecast the future on this. So you guys can actually forecast the future, give both of us a call because we're all in the wrong business and we should do something very, very different than we are actually doing right now. If you get on Google Maps, you can see this is my house and this is the barn that I built. Now I'm what's called a horse husband which means that part of the deal was that my wife gets a barn and so we went to the bank and asked them for money and they gave us exactly this much money. You may say, well, that is not a barn, is it? And the answer is no, that is not a barn. But that's all the bank would give us in terms of value because they wanted to make sure that we had a good foundation. And data governance is partly about making sure that your organization does in fact have a good foundation upon which to build. Let me take the barn analogy just a step further. If I built this barn with a poor foundation then I would spend money in vet bills because the barn would not stand up and it would fall down on the horses and cause them harm and my wife would take them to the vet and I would pay the vet bills, right? Well, if I'm paying vet bills I don't have money to give the bank to pay back the bank loan for the barn. You see, banks are pretty smart. Before further construction can proceed they required the county to come out and give me a certificate that showed that I had a good quality foundation and I could build a good barn on top of a good foundation but there is no IT equivalent. So, this gets us to a discussion of frameworks. And frameworks can be extremely useful if they are utilized correctly. The idea is that a framework is a system of ideas that guide analysis if you have not already encountered it. John Zachman's framework is one of the more successful and popular frameworks that are out there. We haven't done a topic on that but if that's one that you want to see just send Shannon a note and she'll accumulate them and get them together on that and we can certainly do a topic around Zachman framework. It's a means of organizing project data. It gives you the ability to make priority based decision making as in what should go on the framework next. Like if I'm building a barn I'm probably going to put the sides up and then I'm going to put the roof on it. Why? Well, because if I put the electricity in before I put the walls up I'm going to have wires all over the place and the wires will be exposed to the elements. If I put a roof on I can put walls up and then the wires can go inside of the walls. It gives you a means of assessing your progress around that. Again, I already told you about the roof and make sure that all funding is dependent on that. Now, this diagram that I showed you a few minutes ago from the DIMBOC is a framework. You can look at this and see what things are we doing, which places should we start, what activities are important for us to do, and what project deliverables will most benefit the organization. But I'm going to show you a number of other frameworks. Your task is to look at these frameworks and decide whether they are valuable for your organization. Not now, not in real time when you get the slides and take a look at this after the fact. But here's a great framework that the Data Governance Institute has put together. A good friend, Gwen Thomas, who's been at this business for many, many years. Rob Siner has a framework that he uses here. Again, his is a very good framework. Each of these frameworks, coupled from IBM here in order to put things together. All good frameworks. Don't look at these right now and pick one, but spend some time with your leadership and see what happens. Gosh, here's the American College Personnel Association and their framework looks like a boat. Cool. My point of these frameworks is that each of these frameworks offers certain things to the organization. And it is well worth your time to sit down and study them and think about how your organization works and decide what elements from what frameworks are going to be useful to your Data Governance Initiative in order to do this. And most importantly, in what order should you implement them? Because if you try to implement it all at once, it becomes somewhat problematic. So, again, a couple of different frameworks that are out here. I don't expect you to look at them now and make a decision, but take them with you and look at them and then see how that works within there. This is FAS Institute. It has a very good one that's out there. Each of these things are very, very useful within that context. And I want to tell one more story here to get to the sandwich story. So, let me just go back to the Data Governance Framework. I'm working for an organization that's a government organization right now, one of our Data Blueprint clients, and they're doing a great job on this. But they decided that they wanted to have a Data Leadership Component in their framework. And so, when I showed them the framework that they were going to be adopting, they looked at it and half their leaders dropped out. Said, whoa, we don't want to do that. It's like real work and we've got real jobs. So, everybody kind of wanted to be involved in it, but there's a difference between the chicken and the egg kind of situation. And in this case, excuse me, I said chicken and egg, chicken and pig in this case. So, the pig obviously is committed to the process and the chicken is participating in the process. And these are good ways of helping the organization understand when they look at these frameworks and see how it's going to work for your organization. You may decide that you have different ways of doing this and different phases in which you take your organization into this particular road. Now, we talked about chickens and pigs. Let's talk about sandwiches now for a minute. And the idea is, from a governance perspective, currently your organization, without knowing anything about you, has got varying data literacy levels in it. Your organization also has varying amounts and qualities of data supply and varying use of data standards. What we're trying to do with governance is to sort of smooth these things out because one thing we do know about data is that there's so much of it that we largely have to automate processes around data. So data governance has to be thinking not in terms of manual decision-making but in terms of automatic decision-making. Only when you have automatic decision-making can you put these things together in a way that works better for organizations. And these things, of course, cannot happen at the automation level with the kinds of data volume that we see in most organizations without engineering and architecture concepts. I mentioned before most organizations, most people don't have that kind of requisite background. But interestingly enough, I was on holiday in India last year and literally on this tea farm that I took a picture of here, there was a sign-up at the cash register that said quality engineering architecture work products do not happen accidentally. That's a very profound piece of wisdom from Peter Deming, if I recall, correct? Maybe it's not Peter Deming. Maybe it's a... I think it's Deming quote. Sorry, I said Peter Deming. I was going to say Peter Drucker. It's Deming on this. And of course, we need to go back and add in the words data here, data engineering, data architecture, data quality engineering. All of these things cannot happen without that. So how do we get started in the process? Well, pretty much you're going to have some startup activities, right? You're going to assess your context and come up with a roadmap of some sort. Make sure you've got executive mandate and assign some stewards that on the left-hand side occurs one time. And on the right-hand side, you're going to go into the cyclical process. Execute, evaluate, revise, apply, change, management, a typical Deming planned, do, act, check, cycle. Why are you going to do that? In many ways, it's the same way that one would learn how to play a musical instrument. If one starts out, and understands that the first piece of music they're going to play is chopsticks. You guys are going, what are we listening to? That's me imitating a piano very badly. And more importantly, when you hear somebody playing that, you usually say stop playing that piano, right? because it's annoying, but it's the only way you get better. And that's what's got to happen on the right-hand side of this diagram, is that you're going to find out what works for your organization and start to include in that process things that go into it. So let's go a little further with this. Again, just to tease the analogy out here, right? If you look up in our DIMBAK body of knowledge, it'll say that you need to have data policy standards resolved issues, projects and services quality, and information recognized. That's a lot. And by the way, it's the deliverables. Let's go a little further, roles and responsibilities. Oh my God, we've got suppliers, consumers, and participants, and each one of them has multiple roles that are in there. What are the practices and techniques that we've got to learn how to do? Oh my goodness, right? That's just four slides, and that's a bunch of work. There's no way you can anticipate how any of this is going to work, which is why so many data governance initiatives sputter, falter, lose support, the primary decision maker disappears from the scene. They're no longer able to put in place things that they'd like to put in place. So let's take a look at it from a little bit of an easier perspective. Again, I'm not saying any of these things are bad, but they are all aspirational, and you should not try to plan in advance how they're going to be. What you should do is pick some of them and start to implement them on that cycle. So let's take a look at the components that go into this. First of all, we've got IT, and we need to have IT because IT provides the supporting infrastructure for things that we do. That's a four-quadrant diagram. So on the left-hand side of the diagram, we have domain expertise that is less and domain expertise that is greater on the right-hand side. And the roles are less formally defined on the right-hand side and more formally defined on the left-hand side. Y axis, whoops, I hit the wrong key. Let's go backwards. There we go. On the right-hand side of this diagram then, we also have two dimensions here. The people on the lower half of the diagram that I'm going to show are going to encounter governed data more directly whereas the people at the top half are going to encounter it less directly. And they're going to have more time to dedicate to it on the bottom half and less time on the top half. So our first quadrant is the leadership quadrant. We're going to have some data leadership. And we need to make sure that data leadership is in fact correctly trained. And one of the most important aspects of data leadership is ensuring that your data governance program has the required resources. If it doesn't have the required resources, then it's not going to be successful in order to do that. Many organizations just think that as long as I've got a data leader, that's good, but if we look out there, one half of the chief data officers worldwide have no staff and no budget. That does not represent conditions for success. The leadership is going to get guidance from people. The guidance is going to come from people whose title is Data Stewards. Ideally in Peter's role, Data Stewards are a full-time position. And if you have the opportunity of getting 10 people to give 10% of their time to a task, I would ask to trade that 10% of 10 people's time for one full-time equivalent because you will get better productivity and results out of them. But stewards are informing leadership about data decisions that they make. And when leadership makes data decisions, that information goes back to the stewards who then need to interact with the data community participants. These are your subject matter experts, the people who use data heavily in your organization. And this is where ideas come from about how to improve things because the data community participants are the ones who are running your analytics or fixing problems with your legacy systems. About half and half, by the way, in order to do this. We've also got this fourth category in the upper right-hand quadrant, the generators of the users. And they have some feedback that they will be giving directly to leadership and through the data community, which then comes back to the stewards in terms of ideas. And once leadership has made the decisions there, leadership then expects that decision to be transformed into action. And that action goes back to from the stewards to the data community participants and the generators of these ideas. If we don't have these types of conditions together, it's going to be very, very problematic. Finally, of course, we want to make sure that people who are not directly involved in this do experience some change in order to come up with this. Now, let's take the context of a data steward in particular. And our friend David Plotkin has written a very fine book on data stewards. The only problem with it is that I want you to imagine yourself trying to go into the organization and saying, well, I've only got 10% of 10 people's time. So 5% of that time is going to be managing some of this business data steward and somebody else is a technical data steward. And oh, by the way, if you've got data stewards, then you need to have data steward auditors in there and a data steward manager in order to do all of these things. Sorry, David, this is too much, way too much as a starting point. It's a great place to mature into. And in 30 years of doing this, I probably can count a dozen organizations that have matured to the point where they can do this, which means that hundreds and hundreds of others that I've had direct contact with are not mature enough to break these things out. So instead of trying to describe what these roles are and who's going to occupy the roles in all of this stuff up front, let's just start with the concept of a steward. What is a steward? Well, a steward is someone who is trusted. It's one who actively directs things. And if we move it to a data steward, then they actively direct the use of organizational data assets in support of mission objectives. This gives them the ability then to go in and talk about specific types of things in a very narrow, let's roll it out, gradually type of process. Again, we can move on to scorecards on this. Yes, we have decision-making authority standard procedures, all of this stuff that we go up to, but let's not do it all at once. And the same thing for scorecards. Let's not go through and add all of these things at once. Let's start small, grow our way up into these programs because if you try to do it pre-specified all at once, you'll run into the personalities and things that there are these soft aspects of this, things that technology can't help us with. And instead, we will have really bad cat fights in order to do this. One more component for this strategy piece. Again, here's our guidance from previous webinars we've done and things like that. These are things that we should include in data governance program, right? No, let's not do that. In fact, let's instead look at this and say first for our organization, again, hypothetically completely in nature, but let's say that risk management is most important and then security and privacy. In other words, prioritize these things so that we can put them in an order that will make sense. And I'm going to go over here just so that you guys hear the Hotel California running in the background. And if you read through the words, it goes in and talks a little bit about how problematic these things are. But if we don't have buy-in from the business community or we've got business in IT fighting each other, that's going to be a problem. If we start to go ready, fire, aim, which many organizations are prone to do, that's a worse practice. We solve world hunger or boil the ocean. We're going to have 100% of our data completely clean by Friday, right? The Goldilocks syndrome, if the big one is too big and the little one is too little, then the middle one must be right. That's generally not a good way to do it. If you've got people sitting at data governance meetings and they're trying to figure out what they're doing, oh my goodness, that's a death sign for your project. Not taking projects through to fruition. Not dealing with change management, which is a formal discipline. Assuming that technology alone can answer the question or not building sustainable processes and ignoring the shadow data systems that are there. If you'd like a copy of that Hotel California little video there, just send me a note. I'll be happy to send it out. I really can't remember whether I put that together or somebody else put it together. But it's definitely a good little piece. So let's spend the remaining 10 minutes here talking about how these strategies work in action. And the most important thing that you'll do as a data governance person is to learn to tell stories. Because if you can't tell stories about how data is working, people will have an extraordinarily hard time relating to what you're talking about. The first story was a wonderful customer that we worked with, and interestingly enough, in their own words, they would say things like, getting access to data around here is like that Kathleen Zeta-Jones scene where she's having to get through all those lasers. I don't know if you remember that movie, but it was a fun one with Kathleen Zeta-Jones and oh goodness, who's the British actor that's so wonderful on these things. But anyway, she's trying to get through something, she's being a robber here. But this was literally the language that they used. And when we started to show management that this was how their knowledge workers felt that they had to act in order to get data, that's not what this organization wanted to have. So it's a great example of taking, in this case, something that was really, really near and dear to the organization. They really wanted to do this very, very well, but they couldn't, and making it practically focused. So their data governance initiative was all around making sure they would eliminate those laser beams and they didn't have to be as live and as agile as Kathleen Zeta-Jones in order to do this. Another story. In Detroit, we were sent at one point to look at how Detroit did things. Now, I was part of the government in those days. I was a federal worker, worked for something called the Defense Information Systems Agency. So often learned from the private sector. And one of the things we learned was that in Detroit, they considered its success if they put something on an engine, on an assembly line, and it didn't slow the assembly line down. Well, what that led to were three different bolts, which means when we put parts on the engine, we might put it on this type of bolt in this part and a different bolt in another part and a third bolt in another part, which meant that if you were going to maintain the engine, you needed to have three different wrenches, which means you needed to have three different bolt inventories so that Toyota would do one step beyond Detroit. They would sit down and look back and say, what can be harmonized? And by the way, the number wasn't three. It was usually closer to dozens of different bolts in this case. And of course, Toyota never simplified it on one type of bolt. But you can see here that the process of thinking about this and adding this extra step in made their cars easier to build and easier to maintain. And generally, most people think that's a good idea. So trying to simplify things around that gives you again the ability to gradually increase the scope of your data governance efforts and put them into place. Programmatic level. One of the easiest data governance projects I've ever done before was working with the U.S. Army because the U.S. Army looked around and they governed everything. And they said, oh my gosh, something is not governed in the Army? We have to fix that right away so we used their data governance to implement Army policy which just said that we'd need to have in this case many, many things that actually do work. So again, from a strategy perspective, it was keeping it practically focused if we've got something that's not managed and ought to be managed. Yeah, we can fix that pretty easily. We were there, as you can see from the data on this around 10 years ago when we started the military suicide prevention project, which is still going on. And unfortunately, we still have 20 service members daily that commit suicide. But we were putting together the very first set of data that allowed us to do the analysis work around this. And in order to do this, we started working with what I called a Council of Kernels and in this case, a very, very large 30 by 30 matrix. So I want you to imagine this room here full of a bunch of kernels and they're all very well-meaning people and they would say, yes, Peter, you can use my data in column 12 for purposes number 10, number 14, and number 17, and those rows. And if you've ever tried to manage anything off of a 30 by 30 matrix, it becomes very unwieldy very quickly. So one of the things I was able to do was request that the Secretary of the Army come to one of those meetings. I went to Secretary of the Army, heard the third person stand up and say, yes, sir, you can use my data for these particular reasons. He said, hey, let's stop and rethink this a little bit, right? I'm going to put you guys out there a little solution. We're going to call it my data. And anybody wants to tell me why my data can't be used to save my soldiers' lives, my office door is open. Are we clear? And everybody in the room said, yes, absolutely we're clear and we can take that. They've empowered the team, moved us along the way, and we do have better ways of going in and now understanding more specifically what's happening around these, we still need some more help. So I'm not telling you that the military suicide problem is gone, but it is absolutely a data governance problem. And most importantly, the gentleman who did this said, I probably wasn't empowered to do that, but did tell me that I was okay to include that story in a book and put it together at the time called Monetizing Data Management. And those monetizing capabilities were useful to hopefully be inspirational to other people. Now, I've told that story directly in person to more than 100 CEOs of private corporations and not a single one of those CEOs has taken the courageous step of saying it all belongs to my organization. It's my data. And that has been an enormous, enormous problem and an enormous disappointment and enormous barrier to actually making progress in these areas. Another quick example here, we had one organization that was doing lots and lots of work with tanks and from a governance perspective, they were going to have to go back and modify their accounting package and instead we said let's not modify the accounting package, let's talk in terms of specific types of tanks. So we can talk about tanks that fly and tanks that swim and tanks that put things on big guns and we'll talk about tanks too but that's another component of it. Each of these tanks then breaks out into hundreds and millions in some cases of data values but these data values, three million of them when you buy a tank, only one of them controlled obsolescence. Excuse me and the problem with that is that we found one of the branches of the service was actually maintaining tanks that were obsolete, not a very good practical way of approaching this whole process. Again, another governance perspective, Barclays, you may have called this from the oopsie that we had in 0708 when the economy tanked, Barclays bought Lehman Brothers Bank and they were contracts that they didn't want to buy. They said we're going to buy the good stuff and we don't want to buy the bad stuff. So we're going to put all the good stuff and the bad stuff on a spreadsheet and when we don't like something, we're going to hide the rows and take the spreadsheet to the judge. The judge will say everything on the spreadsheet good, both lawyers say yes, and say that's the contract, right? Well, they handed the spreadsheet to an associate the night before it went to the judge and after 11 o'clock they went through and unhid all the things that were there. So unfortunately they actually ended up with the contract after the sale closing having the wrong kind of exercise in this case. I don't have to talk when I go to Barclays or Lehman Brothers for the spreadsheet governance. They understand the rules of this because they learned through an almost disastrous process. One more quick example here, a very famous one, a group called Mizzouho Securities in Japan. They had a real interesting thing where they had a securities analyst who wanted to sell one share of a stock called JCOM and he wanted to sell it for 600,000 yen but he hadn't had his coffee and he sold 600,000 shares for one yen. Now even if you don't know the conversion rate, you know that's a bad result. There was a $350,000,000 loss on this but the governance examples were amazing. The in-house system did not have limit checking. One of the things you should do if you don't sell things for penny stocks is that you should look for the price of the stock and see if it's a penny and report it and put a break on it and say maybe we don't want to let that one go to the market because after all the market may not and in fact this case did not at the time have limit checking and it did not allow order cancellations. These are horrible, horrible events. Now what we've done is taken a little bit of storytelling in this. We're going to take it just a step further here as we finish up to give you a couple quick takeaways on this. Again data governance need for its increasing because the volume is increasing and the practice improvement is not there. It is a new discipline so we must conform to constraints that are in your organization and there is no one best way to do it. It must be driven by data strategy keeping it practically focused implementing it as a program and not a project and gradually adding ingredients. And the reason we need to do this of course is because most people think data is this sort of bat sign that sits there between IT and the business and reality wise it's more like this although quite frankly it's actually much more like this. So I've given you a couple of references to take away on some of this and we now get to the part that's the really fun part where we get to answer your questions about all of this. Shannon back over to you. I'm getting myself off mute there here. Thank you Peter. Sometimes it's a challenge for this great presentation it's so fantastic as always. And if you have questions for Peter or for Jonathan feel free to submit them in the bottom right hand corner of your screen there. To answer the most commonly asked questions we receive just to reminder for everybody I will be sending a follow up email by end of day Thursday to all registrants with links and the slides to the recording of the session. So diving in here Peter way back when on slide 36 says I know you can always go through so many slides it's amazing. I think you are the champ at Gotta be good at something right Shannon? Yes It says you are making assumption that there is a data strategy on slide 36 so what happens if the data strategy doesn't exist? What do you do? Excellent question and think about it let me turn the question slightly it's a very good question the way it is posed right now but here what we were talking about is that data governance has a lot of things that need to be done to make amends for past lack of attention. If nothing else your organization has five times the amount of data that it needs to have and that's a huge barrier to productivity. So the question is what if you don't have a data strategy well then you will probably try to implement data governance by looking at some of the slides that I've shown here and let me just go to my favorite one which is the one that has all four of those pieces on it all at once and try to do all of them without actually having any practice at it. And it's kind of like me telling you that I want you to play electric guitar lead next week and you've never picked up an electric guitar in your life you know where do you start so all strategy does is tell you what's more important than what else and that's what data leadership is about qualified data leadership should say yeah we need to clean up all of our data but we're not going to be able to do it by Friday but we might be able to clean up this sliver for this use by Friday and that might actually deliver value in which case I can then go back and ask for more resources. Now let me add another piece onto this the more successful data governance practitioners are people who are recognized by their organization that if you give them $100 worth of resources they will return $100 plus dollars even if it's $101 right they're still getting value back out of it in fact I have one that is so successful that literally she doubles whatever she gets so she's given $100 she gives back $200 and I keep saying can I give you cash because we would both be in a completely different business in that case. Jonathan let me turn it over to you what do you think about slide 36? So I think the business of not having a strategy is quite common and quite often folks we need data governance so let's set up this group and off they go. You know for us we quite often say look manage the data that's important to you so if you cannot tie that data to a key performance indicated to a programmatic initiative that's funded to senior management's objective you know goals and objectives kind of thing then it's just less important and generally speaking the data governance group has more than the needs or can do given the resources so it becomes part of your rack and stack and kind of selection criteria when you're looking at the tasks that have been given to you but in general you know that's how you sort of separate the wheat from the chaff but in general quite often we find the data governance guys asking the hard questions you know what is that policy level leadership or direction that you want to give me to allocate my resources and focus and in doing that you kind of work backwards into you know forcing it some leadership it's not a good position to be in some manner of education because at the end of the day you need that you need executive leadership but that's how that's a common sort of scenario that we focus on. So let me let me ask you another question on that though Jonathan when you're talking to people about how to get started and actually do the racking and stacking piece we also see that a very wide variety of approaches in there and some of them are automated some of them are not automated many organizations think that data governance technologies can help what's your opinion in that area what's the proper role for a data governance technology how can automation help us. Yeah I mean in this particular challenge here I mean obviously there's tools to help tasks and so on but you know if you haven't nailed down what it is you want to do having a tool to automate it really you know that can just make a bigger mess than what you started with and it forces you into a level of comfort and you think the tools are the problems but in fact you're just digging a deeper hole half the time so we talk about the framework the governance framework how do you want to think about all these components and how they work together and understand that a conceptual level I think sort of conceptual data model is a conceptual framework model how do you want all these pieces to talk to one another and then go about automating it with tools. So I popped up the Alice and the Cheshire cats you know little analogy which is which road do I take and the cat says well where are you going and she says I don't know and he says correctly then it doesn't matter if you don't know where you're going any road will take you there let me let me ask you just to elaborate on before we go to our next question too because I know you had some thoughts on frameworks in there and I I hope people don't I go through them quickly not because they're not valuable but just because there's really no point in me taking up 30 minutes of discussion on them but what I want organizations to do is to look at these frameworks and say what aspects of these frameworks are useful in my organization and how can I apply them how do you approach that process as well so I am a as you know sort of a big fan of the maturity kind of process involved with the CMMI stuff so I kind of got a inclination in that direction but you know if you you one of your first steps is to understand where you are and understand that if you're at a lower level of maturity you can't focus on the high level right you've got to focus on those next steps you've got to build them out so the maturity models and those frameworks whether the maturity or not are going to help you identify those tasks that have to be down and break them down to a level that they're sort of digestible right everyone wants to be best in class but not everyone talks about how you get there so I use the maturity framework anyway to sort of understand what those next steps are what might be expected to help me break it down I use the dim box to you know that's more of a reference model than a maturity model but you know to give me some insights into am I looking at everything have I missed something if I have missed something have I done that on purpose you know my organization just not ready for it those kinds of things to really frame the thinking and help me there's so much to do right so how do you narrow it down and focus on this and what do I need to do first and what do I need to do next and you know all the rest of those things let me take it a little bit further and we will come back to the rest of the questions I promise you on this but this is really good stuff because even our dim box wheel here that we put together in Dama and I'm the past president of Dama and still highly involved in the organization and I mean this with all due respect this diagram is decision in two ways that are pretty important to data this shows what are the aspects of data but I get calls here at Data Blueprint all the time that says the dim box says I need to do data warehousing well it's not what the dim box says the dim box says data warehousing is a part of data management but it's easy to see where you would get that impression because this diagram does not show optionalities and dependencies other than showing data governance as the central activity so I think even this diagram can be improved on in order to come up with framework type discussions and thanks for adding to that Jonathan and this is why we have a half an hour for questions in this presentation it's great I love the in depth answers and I believe everybody else so just you know I kind of going back backtracking a little bit you know and going back to data strategy what are the elements of a good data strategy should it include priority scope operating model and implementation strategy and where and who owns it is it IT or the business we get that question a lot a lot Jonathan want to go first his own data strategy it is you know if you have an organization that is has set up a CDO and so on then that that's somewhat of a simple question because they recognize the need there but you know who doesn't own it is IT in general I'd like to see come on to the COO if it's not spun out of anything as its own component and you know but my vote is for the COO in general terms if you have the option but you know at the very least the organization has got to recognize the need for it and establish some organizational component that has a degree of independence and the ability to bridge across the organizational structure and I've seen it done lots of different places if you put it in IT you got to watch out because you know you need to control that but occasionally you see it in IT and sometimes that's just the way it is within various organizations I would say that one in ten IT organizations does a really good job of implementing data and data strategy correctly I talked to in fact one of the gentlemen that reviewed the monetizing book that I mentioned earlier came back and said I don't know where else this function would exist I'm the CIO I'm responsible for data I understand how this works and I said yep and you also only talk to people who you think are equally smart which means you're dealing with a very rarefied atmosphere and I challenge the individual to go out to the organizations to some data conferences come to us to enterprise data world one time and ask other people what they did and found that they were not as successful here so one in ten does it correctly but I also agree with Jonathan that absolutely if you want to make good progress with this do not try to do this under the CIO because the CIO is already slammed there are all kinds of things that your CIO is paying attention to everything from managing vendor contracts to trying to make sure that software is delivered and implemented on time to make sure that we've got the hardware and software matching and you know have gotten through procurement regulations and implementations and lots of dependencies and optionalities in that environment as well and if you ask them to do more with data something else will start to fail in most organizations so fully half the CIOs that I talked to about that say yep I got no room on my plate and I'm glad it's somebody else's problem now here you go good luck with it yes that chuckle is exactly what we're hearing on this and the other half I'm going to my title CIO what if you take that away from me you're kind of you know emasculating me if you will and generally a point that can become contentious for some organizations so we still haven't tipped that but I also like Jonathan agree that if we can get it out of IT and report specifically into a COO who is more financially driven or we've got right now as far as where CDOs are reporting about one third are reporting directly to the CEO but one third are reporting into a COO or a CFO or a chief risk officer kind of construct and a third of them are reporting into CIOs we will need a couple of years to let that sort of percolate and we can go back in a couple of years and see what works maybe there's one answer or maybe for organization type X structure Y is the right answer for it we don't know at this point but what we do know is that what has been working hasn't given us the results that we want and what has been done has been done what has been implemented in most organizations is that data has largely been an IT implementation project around tools without the discipline on it so Peter with respect to the components I would just point out that the CMMI's data management maturity model defines data strategy in a specific way and defines all the things that it influences so different sources will provide a slightly different perspective there but I would go back to that webinar last month that sort of addresses that to answer that particular question or at least one view of that question yep absolutely and I'm big at hearing into that and Jonathan you have to be careful if you say her name three times she will appear so I have not yet said her name but I guarantee you she's out there listening for us no no we love Melanie absolutely Melanie Melanie and just so you all know there's a link for past webinars to them on demand if you missed it last month so you can that will be included in the follow-up email so Peter specifically what did you mean by data shadow systems shadow data systems shadow IT systems they are systems that exist in the organization that are not formally part of IT and many organizations consider them to be a problem I consider them to be a point of really trying to find specifically much more about where IT still has some room to support so I'm trying to figure out what slide that was but well when you walk into an organization you know I tend to be shown a lot of things right and one of the things I'll find is that there's an individual in the corner who'll say look IT doesn't know but I've got a SQL server implementation running under my desk because I need different kinds of support than the rest of the organization and I say two things to them don't worry IT knows you're there and they're keeping you there because they know you're doing good work with that piece and they can't support you in other ways but shadow IT systems can become a problem because we also have many many instances and again Jonathan I'm sure you've seen this as well where an organization will make an error because somebody didn't understand that there was a data refresh problem that should occur they may have been working with data and then they find out oh my gosh that data I've been using is three years old because I didn't understand enough about the data that I was using and I was quite frankly unqualified to do this so shadow IT systems are systems that are not typically part of IT but that are out there in the environment and that can in some instances become problems and a lot of organizations tend to think that's a place we should go stamp them out I say don't stamp them out until you understand exactly what they're trying to do because an awful lot of organizational knowledge can be tied up there. Jonathan go ahead I think it's all good points in the sense that they're not desirable but they might be a necessary evil kind of thing but just to give you a bit of a story I'm working with a group right now who has a number and this happens in the analytical space quite a bit right because an analyst is forever slicing and dicing and adding columns and doing all kinds of things so but in this case they're grouping together country codes and region codes and making their own groups so to support a number of different business endeavors but they're doing it kind of on the side those reports are bubbling up and they're not necessarily matching with your general ledger and your financial activity right so at some point someone looks at the two reports and says these don't foot what's going on kind of thing and so that's an example of you know yeah we need to we need to bring those into some sort of governance so we can create a data service in this instance that provides a crosswalk look up look up table it's a reference data problem around country codes really and we can provide that service as an enterprise data management office it's highly value added it hits some critical reporting that goes out and we take we offload work from an operating unit to the enterprise and leverage that across the whole organization so in that sense you know kind of a success story it's an easy win and the impact is great because that shadow system was bubbling up reporting that just created a lot of reconciliation work absolutely that was probably more information than the questioner wanted but I think we covered it it's my problem I do that sorry thank you guys so moving on here though I hear a lot of data-centric presentations that acknowledge the importance of change management but not many that offer guidance on how to successfully adopt it why is that is it just difficult like why is that so you're hitting on exactly the question which is that the hardest thing for most organizations to do is in fact change change is all about doing some things differently than you've done them in the past and there is a formal discipline called change management even my university Virginia Commonwealth University has a formal group now we have about 50,000 employees excuse me we have about 50,000 people at VC about 15,000 employees in there and to get them to do something differently we need a group called change management that comes in designs ways of I'm going to be very cynical about the description making it more difficult to do the old way rather than to do the new way in order to do it that's one way to think about change management but what you're really doing is explaining the benefits of doing this and saying look if you think about how data is used after you input it you'll probably give the organization better instrumentation to fly the organization on kind of a thing Jonathan anything on that change management you know other than just it's always been a component of the discussion and it's always been very sort of culturally driven so as you're working your operating model you talked about what should be a strategy but part of that you know what's the operating model of the group it's got to accommodate the reality of that organization which day one might be very different from where you want it to be you know five years gets to that maturity discussion but you know I wish I could say for me it's not been very formulaic other than you know high empathy high engagement high communication and you know follow the best practices you know over communicate structure be consistent all those types of things absolutely key to recognize is that if your organization does not possess this expertise that expertise is a necessary but insufficient condition for success in data governance because data governance is about doing things differently and if we don't give people rationale and reason and support to do things differently they are likely to revert back to the norm and that will not produce the results that we have back to Jonathan's first slide your second implementation of data governance is likely to be the one with talks about strategy so storytelling is so important when rallying sponsorship and organization alignment to data governance any tips or tricks to share with the audience for how to formulate their stories 10 minutes I gave you a bunch of stories and I'm pretty sure everybody on this call could come up with their own story so practice again this is a discipline you can go off and take classes there's a master class same group that does the master class series on the web the webinar groups on how to do storytelling it's not a huge amount of things but if you learn a little bit about storytelling you will learn how to take things that happen in your environment and turn them into stories and when you do that then you start to practice them practice them on friends and family if they don't put you off and say you're boring you're probably doing an okay job with your storytelling stuff on the other hand I can tell you that if I come home some nights and tell my wife I got this great data governance story that we did this week she'll go yeah not till I've had my drink right then you can tell me story so there are clues that can tell you whether you are doing storytelling well or not and it's a skill just as change management is a skill not that we data governance people should learn all those skills but you need to have them accessible if you don't if you can't tell this again another pitch you'll hear a lot is the elevator pitch alright you get on the elevator in the 20th floor and the boss comes on on the 19th floor looks over at your bed and says Peter you work for me tell me what you do and if I stammer and stutter and don't produce anything valuable by the end the guy's going to remember Peter and put me on the list of people to get laid off the next week because clearly I'm not adding value to the organization on the other hand if I say yes ma'am the I'm the person who put in place the data governance constraints that keep us from sending the same bill to our customers three times in a row that probably won't get me fired so you've got to have this ability to come up with a 30 second a three minute a 30 minute and a three hour version of the kinds of things that you're doing those by the way are key elements to a data governance communication plan another part of another seminar that we do but we'll certainly get to get you down there Jonathan any any guidance for storytelling well I think you know my particular thing that I watch out for is that you know stay away from the details at the end of the day we get excited data people get excited about things that normal people don't write and then you got to stay away from words like semantic and ontology and vocabularies you know people just don't want to hear that so all of the things that Peter said and just keep in mind the audience again complex and detailed and probably nobody cares except us which is good we've got to have somebody care about it but at the same time if you've ever wanted to get into a discussion of accounting practices and the way they do taxes differently in Oklahoma versus Idaho probably not your standard dinner table conversation so data is a very interesting topic and keep in mind this thing this guy's name by the way is Wally Easton and if you google him or go out onto YouTube and get his clue he's really quite good at what he does but do you want your organization getting good at this I'm sorry it's just not the right place of knowledge workers right I'm impressed that your wife is even willing to listen to your stories she is a comptroller Jonathan so I get to listen to her stories as well so fair fair play right it goes around comes around okay there you go there we go I know yeah do you think humanizing data sits with data governance or change management or don't you think the two should be separated are you saying change management should be separated from data governance I sure hope nobody believes that change management is a part of data governance for sure yeah do you think humanizing data sits with data governance or change management or do you think no I would incorporate them in when I was with the defense department doing this type of work 30 years ago the senior executive on the project a woman named Mary Howard Harding Smith and I say her name reverently because she was one of my favorite people to work for in the entire world she said if we do this for something that nobody understands we'll be out of out of work in just a little bit so she said we're going to do this in a way that affects people and again gets to that humanizing concept in there if we again my little story about the hospital director right if we've got everybody using the default hospital admission code and we'll just say the hospital admission code default code is knee surgery and everybody takes the default the hospital director in a couple years looks back over the data and says wow we're doing lots of knee surgery I'd better reorient our knowledge skills and abilities towards knee surgery if I don't have knee surgery in here I'm clearly not serving my community whereas humanizing that process would have been to say to the intake clerks that were picking up the data on the way in you guys almost caused this hospital system to fail because you were telling everybody we were doing knee surgery we weren't really doing knee surgery so I absolutely believe tie it as tightly as you can to something that affects people's behavior and you will be able to get that behavior changed in a way that makes sense people remember what's personal right so do that and going back to the previous conversation about where everything should sit why do you recommend CIO instead of CIO and then Peter you gave your answer and Jonathan could you explain a little bit deeper as well? Defend your thesis sir. Yes so I think the short answer is the CIO's shop and maybe not the CIO themselves but further in the trenches are very much focused on a different set of priorities and deliverables and every organization I've seen where the data shop has been under the CIO or in the IT realm whatever they call that pyramid the data work is important but not always as critically urgent as some of the other stuff so if the guy's got to keep the data center running or reworks on tables to make so that I can index and find data more effectively the data center running always wins always so you consistently come up with this difference in priorities that shifts the data work out and unless you control for that and there are CIO shops that are able to do that then the data stuff always falls behind and the IT shop always has a good reason for falling behind because the alternative is that the data center went down that's a real story but it's always something so I think that's one reason and sort of very practical and real in my experience the other one is that data is a bridging function there was a slide in here with the data in between the two jigsaw pieces and so you need people with that skill that can really understand people process impact and enabling technologies right in that sort of example there's four things and one of them is IT right so in that context again it's a balancing act and I find that this CIO shop just has a hard time of maintaining that balance in any kind of consistent way it's always attention right nothing to add exactly what he said yeah okay we got three minutes here I think we can squeeze in one more question quickly both speakers said they would be available to communicate with us if we have specific projects I'll get you that information for both of you I'll send that out in the follow up email going out by end of day Thursday and guys how pit is a data asset registry how flexible pivotal oh pivotal thank you good much better work so how are you going to manage it if you don't know what you have I recently did a group within the army and the data governance strategy for them was to say that look you're being given permission and trust you're being entrusted to manage some army data do you know what that is and they kind of looked around the room said well you know I assume it's this and that and the other thing because they deal with this that and the other thing and I said yes are you sure that's all of it and they said well I think so but what if the army is actually trusting you to manage why and you don't know that why is part of your portfolio so part of this is to formalize the process just real quick you will never complete your data inventory you will never complete your data registry we've never seen it I'm putting words in Jonathan's mouth but I think in 30 years in his case and 30 years in my case we've never seen anybody finish that so the important thing is not to have a complete inventory but to start the process where when you discover new piles of data that are lying around you have a way of registering them quickly easily and efficiently and so in that sense pivotal absolutely how are you going to manage it if you don't even know it's part of your portfolio so many examples of what Peter's talking about I'm not going to go into that but I had a slightly different twist with respect to sort of if you do a capability assessment whether informal or just do your own inside your organization I don't know 90% of the time maybe you know some certainly more than 80% of the time you're going to find that your organization has skills has capabilities with respect to data that people just don't know about again and again it pops up so your registry your catalog when it comes to data you need to kind of google your data is one of the things that we talk about from time to time absolutely absolutely well that does bring us to the half hour there thank you both so much for this fantastic presentation very informative and very fun very engaging so thank you both thanks to Amphibix for sponsoring today's webinar as well to help make it all happen and thanks to our attendees for being so engaged in everything we do and all the questions that have come in just love all of that and again a reminder I will send a follow-up email by end of day Thursday with links to the slides, links to the recording also have the links to the past webinars from Peter so you guys can look at the webinar that was referenced from last month and I hope you all have a great day, thanks so much Thanks guys, it's a real pleasure to work with you and Shannon great to speak with you as always we love working with you guys so we'll let let him take us out have a great day guys, bye bye everybody