 Hello, and welcome my name is Shant Kemp and I'm the Chief Digital Manager for Data Diversity. We would like to thank you for joining today's Data Diversity webinar, getting a restarted with Data Stewardship. It is the latest installment in the monthly series called Data Ed Online with Dr. Peter Akin. Just a couple of points to get us started, due to the large number of people that attend these sessions, you will be muted during the webinar. 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 your questions by Twitter using hashtag dataed. And to open the Q&A, or just click the Q&A icon in the bottom middle of your screen for that feature. And if you'd like to chat with us or with each other, we certainly encourage you to do so. Again, just click the chat icon in the bottom middle of your screen. To answer the most commonly asked questions, as always, we will send a follow-up email to all registrants within two business days, containing links to the slides. And yes, we are reporting and will likewise send a link to the recording of the session as well as any additional information requested throughout the webinar. Now let me introduce to you our speaker for today, Dr. Peter Akin. Peter is an internationally recognized data management thought leader. Many of you already know him or have seen him at conferences worldwide. He has more than 30 years of experience and has received many awards for his outstanding contributions to the profession. He has written dozens of articles and 11 books. The most recent is your data strategy. Peter has experienced with more than 500 data management practices in 20 countries and is consistently named the top data management expert. Some of the most important and largest organizations in the world have sought out his expertise. Peter has spent multiyear 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. Ah, yes, details on mute. I'm mute. Yes, thank you, Shannon. It's such a pleasure to be here with everybody. Thank you for joining us. Shannon says a little note that says, hey, don't forget to get off of mute, right? And of course, I do every time. Anyway, just real quickly, we've got some event pricing on some of the books right now, but let's dive into our topic on this. Really key for this is that I wanted to say getting started with data stewardship, but I find that a lot of folks are actually trying to restart as well. So I wanted to make sure we got both. So if you're starting data stewardship, I think this tells the same kinds of things for you. And the real key for this is to understand, excuse me, the role that data debt plays in relationship to Stuart. Data debt is, of course, what you accumulate when you are not governing your data. And many organizations can say they have never governed their data. Consequently, they have lots and lots of data debt. Let's dive in a little further and talk about what we're going to cover. And the real first question is, why do we need data stewards? And we'll talk about some specific definitions. I'll give you a better definition of data debt. Stewards have to be concerned with architecture. They cannot simply clean things up. It doesn't work that way. You can't just clean up all of your data and then it'll be ready. And of course, I don't think anybody's ever cleaned up all their data anyway. And for that, you need to have a strategy. Strategy is what allows you to say this is more important than that, whatever this and that are. And strategy keeps you focused and make sure that you do accomplish something as opposed to starting a lot of things that never really get filled all the way through. There are a second section that we'll look at how stewards are supposed to eliminate data debt at the same time they're facing regulatory initiatives or deadlines or other things like that. And there's there's lots going on. So we've got to resolve the prerequisite challenges on there. We've got to understand the relationship with governance of organizations and governance of I.T. And then we'll talk specifically how the role of stewards fit in there as well. And I like I would like you all to come away with the end of this understanding what I call the fire station model. I live in rural Virginia. Again, just to give you an idea of how rural I live. My desktop, my local provider gives me two, not 20, not 202 megabits to the desktop and point three going back up. And as you might imagine, I have a volunteer fire department around here. Well, it turns out that's a really good model for thinking about data governments around there and the role of stewards playing in that particular context. And then so we've looked at why do we need stewards? How are they supposed to do this and when are they going to do it? And there's really a key here is understanding that data works very differently from how we have been trying to do things technologically and process oriented in the past. There's a different cadence, a different rhythm. And this often requires a different structural approach to do this as well. There are some foundational prerequisites before your stewards can be successful. We'll talk about those. And then lastly, really is the need for simplicity, agility and practice in these areas. Of course, we'll get to the end about an hour from now and head to the part of the event that we like so much, which is the Q&A with Shannon on this and to talk to you all about it because I end up learning bunches of things from you all, as well as everybody learning from the community, which is, of course, the purpose of these sessions all the way. Let's dive right in then with the topic of do we need stewards? And were we in person? Hopefully we will be in person sometime in the near future. But were we in person? I'd ask you to raise your hands. How many are starting versus restarting? And usually it's about half and half to come to these sessions. So those of you that have not started your data, stewards program or your governance initiatives should take this as a pretty good indicator. The first term for a lot of organizations has simply not been as productive as they want to do it. And the reason for that is and hopefully take away some lessons from this so that you won't get caught in the traps that they've gotten caught in. But the reason for this is because we don't have the kind of tradition that we have here in data as we have in accounting. Accounting records, literally we have records that are 8000 years old. These are some cuneiform rocks that we were recording beer sales on from 2000 BC. So that's sorry, it's 4000 BC. So that's that gives us our 6000 or 8000 years around all this. And most importantly, as a distinction between the two, accounting has had enough time to develop what we call generally accepted accounting practices. When a company gets in trouble for one reason or another day to breach or something else happens to it. One of the first things that analysts do is they look to see if they are in the 80 percent of the companies that follow generally accepted accounting principles or the 20 percent who don't. And if they don't, they immediately ask, why not? What are they trying to hide? What's different about this organization? But at least we can say among ourselves that 80 percent of the companies that are out there are following generally accepted accounting principles. Now, we trace data back to Augusta Ada King, who is a countess of Loveless. She didn't live a long time, but she was incredibly productive. And just one of the things that she came up with during her short life, but very fruitful life was that she looked at this thing in the bottom left hand corner that hopefully you recognize as a weaving loom. That's to say that we put different colored strings through and we can make very interesting designs on this. Of course, you can see the one that is shown is a manual process. She actually looked at these, which are the industrial strength things. And these things on the right hand side with these holes punched in them are literally the same thing as computer cards. In fact, the design for the Holler system was taken directly off of this in response to some observations that she made. And she looked at this thing here and this bit here that was the programming piece, the computer cards on this. And she said, I can design a system that will do math for us. Well, it was great. She really did invent the computing field as well as numerical analysis and a bunch of other things that were there when those computers were created. They, in fact, did show that she could solve Bernoulli equations based on her set of instructions that are in there. And I say that not that we are bad people in any way, shape or form, but we are still learning. And that's, of course, a thing that we hope to do throughout our lives as continue to learn. And yet when we look at what we ask knowledge workers to do with data, the answer is practically nothing in a formal sense. There are very few programs that deal with these pieces and what people should know about them. And of course, my definition of a knowledge worker is a person who works with data, which means 100 percent of these individuals need to pay attention to it, but they haven't trained them. OK, problem. Same thing when we look at what we've been teaching to I.T. Now, I'm a tenured professor at Virginia Commonwealth University in Richmond, Virginia. I've been here since 1993. I'm not saying bad things about our profession, but it is not on the cutting edge. And I don't mean that specifically about VCU. When I look at programs around the world, they typically get one course that teaches students how to build a new database. If there is a skill we do not need any more of on planet Earth. It is how to build a new database. We've got plenty of people that know how to do that. What we need are broader categories of data in there. And that's, of course, the subject of the next book, which hope will be out perhaps even as early as next month on data literacy. We'll come back to that in a bit. The other problem with this type of curriculum is that people who are not going to be I.T. professionals understand the curriculum and they say, oh, you get 10 courses in your major. And one of those 10 courses is about data. One of them is about telecommunications. One of them is about how to do programming. One of them is about analysis skills. Again, they have to go through there. But what it says is that data is only one tenth of what's happening in the overall area. I'm pretty sure that everybody on this call disagrees and thinks that it's a little bit higher than one tenth of this. So we are not only communicating incorrectly to students who are our customers on this, but we're also incorrectly communicating to the rest of the profession that's out there. And this leads to confusion because I.T. thinks that data is a business problem. After all, if they can connect to the server, my job is done, is a phrase that we hear way too often from I.T. Similarly, the business looks and says, well, there's somebody there with a title of chief information officer. Who else would be taking care of my data? And the answer is, of course, that data has fallen into an enormous gap between business and I.T. And our quest as data professionals is to repair that damage and to reestablish the partnership that should exist in order for organizations to be productive in this area. Given what I've told you then, it should be no surprise that half of companies report they've made an inaccurate business decision based on bad or outdated data. And this leads to what I call the bad data decisions or the data literacy spiral. And it starts out fairly simply. Business decision makers are not data literate and technical decision makers are not data literate. Therefore, they tend to make bad decisions when they make bad data decisions that results in poor treatment of organizational data assets and poor quality data, which leads to poor or like organizational outcomes. If you want to see an example of this, I have literally seen in the last 18 months, 12 organizations that have done the following thing. They have bought something that works pretty well. Salesforce.com as a software and nothing wrong with it. Software, but if you install Salesforce and then put your data out there and open it up for people to look at the general public, your knowledge workers in your organization, your customers are not smart enough to look at the data in Salesforce and say, ah, the data in Salesforce is wrong. No, they're not that sophisticated. Instead, what they say is Salesforce sucks because they can't separate out the difference between this. So these bad data decisions can include things like, well, let's just reverse the order of put Salesforce out there, clean the data and then turn it on instead of turn it on and then clean the data. Kind of a simple thing. Salesforce, I know wishes it was the way I'd prefer it to be in there because they would not get called bad software on a regular basis as they do. Similarly, though, in terms of the overall literacy around this, you'll see a lot of things out here. And I see this slide fairly occasionally. And it's kind of a bit heady to say, this is the one person at work you can't possibly live without. I mean, I agree with that as a general sentiment, but it's probably not where you want to lead on this. And it leads to questions. So let's look and see what do we mean by stewardship and data stewardship in particular? So steward is a person who looks after things. If I go to Europe, they expect them to be serving me a drink on a plane, a flight attendant, these types of things that go into this. A person responsible for supplies of food, again, another way of exhibiting stewardship. But there's a second definition, which was equally valid, which is an official and third gets into it as well. A person employed to manage another's property. Especially a large house or an estate or a pile of data. So stewarding, then, is the idea of keeping arrangements or keeping order at the event was organized and stewarded properly. Again, to manage or look after another's property. So when we go to data steward here, we can look at managing data assets on behalf of all the stakeholders and in the best interests of the organization. This gets us to an ownership question. We'll come back to that in just a little bit. But it takes the interest of all the stakeholders and an enterprise perspective, which means we should not. Stewards should not be subject to local optimization type responsibilities. And finally, you can't ask people to do this stuff if you don't give them time. So rather than having 10 stewards that are dedicated part time for a data effort on this, I would say you take the 10 percent back to all of them and give me one person, one FTE, because that person will do a whole lot more than the 10 percent of the 10 other people in there. An important concept around this is the concept of trust. And we're starting to get this in all various aspects of data. Interestingly enough, we're now starting to see speakers that will go to certain conferences unless they put out their their policy for bringing people on and being inclusive and all the rest of the things that go with that. All very good efforts around that, which trust leads us to a more formalized version of trust called a fiduciary relationship. And you already have fiduciary relationships with people in your life, your doctor, your lawyer, perhaps your tax planning individual. These are examples of people who you have disclosed certain data to. And they have an obligation under the doctor's case, HIPAA, a penalty of HIPAA to violate that in there. So it's really critical that you tie the concept of data stewards to this concept of fiduciary. Let's take it a little bit further on this as well. A steward, again, one who actively directs right out of Marion Webster's on that. And therefore, a data steward would be one who actively directs the use of organizational data assets in response to specific mission objectives, not for the sake of the department X or department Y, but in fact, something very much broader and at a higher level of abstraction. What do the data stewards do then for our organization? Well, again, I'd love to have this one that's up here in the slide here. And it'd be great to have those kinds of capabilities. But really, we have to say, what is the purpose of a steward? They have a responsibility, right? They've been trusted and they have a fiduciary responsibility to improve the organization's data value as well as advocate or evangelize for increasing the scope or rigor of our data centric practices. And if ensure the efficiency of data management practices. Now, the last one I'm going to cross out here because it's a really bad way to say it. And I would urge most of you not to take that up to your management, but try to say it in a different way, improve data's use, achieving organizational objectives. That will give you a much better, clearer line between what happens in data and what happens in the rest of the organizations. Those of you who are not familiar with it, this is our dim-bock, I say our. This is the Dama International's body of knowledge. It's the representation of this. And of course, governance is right at the center of all that. Data debt, then, is the time and effort that it'll take to return your data to a governed state from its likely current state of ungoverned. I call it getting back to zero because you really need to be at zero. It involves undoing existing stuff and it will likely demand new skills on your organization. Once you get to zero, once you have eliminated data debt in certain areas, then the process starts out from scratch. And unfortunately, the right-hand side of this diagram is the only thing that we tend to teach people. And we don't teach them that this still requires annual proof of value. That somebody sooner or later is going to go, yeah, you did some great stuff for me back in 2019, but what have you done for me lately? And now you, as the data steward, get to get good at both of these. Almost all data challenges involve interoperability. There's little guidance around the optimization of those practices and very little guidance as far as how to get back to zero. So this is a challenge for everybody. And another challenge is that poor data tends to manifest itself as a bunch of different types of problems in the organization. And it is necessary to do what we call a root cause analysis around this. So poor data may be at the problem of it, but turns out that almost all cases it's filtered through some sort of IT system or some other business process in there, which means that the people who are trying to do this don't recognize the common theme that these poor results are all tied together with a root cause of bad data. Again, usually it's the IT system or the business process that gets blamed. And only sometimes do people go beyond this. Well, particularly if you're in firefighting mode, I don't want to say that's an excuse, but it's at least acceptable in that sense. And yet when we look at this, we have to have somebody who's able to go in and say, no, no, no, no, that's not an IT problem or it's not a business process problem. It requires a team of specialized skilled that are deployed to create repeatable processes in problem solving and develop sustained organizational skill sets. If you don't have the ability to do that and you won't in a fragmented stewardship organization, then it will become an increasingly contractable problem for you. There's some aspects of governance and architecture in here. I'm just going to put them up there for a quick second and say that corporate governance, again, is the idea of how does a company relate to shareholders? There's certainly some issues with corporate fairness and things like this. But corporate governance is a real thing. In fact, it's so real that just a couple of years ago, Jamie Diamond got up and said, you know, it's also no longer only our purpose to produce an economic value for our shareholders. Instead, we need to look at how we fit in in the good of society. So lots of good work around corporate governance, no problem. IT governance, you know, you've got some similar kinds of things in here. Again, the idea is to align the IT strategy with the business strategy. If the business strategy says everybody stay home and work from home, then the IT strategy ought to support that. And again, I'm oversimplifying here because we all just been through the first phase of the pandemic here. The key from an IT perspective is to look at it from terms of measurable results, what can we measure, what can we find out and answer some key questions about governance, value delivery, resource management, risk management and other types of performance measures. Now, I'm going to stop on this for just a quick second and ask you guys to think about the elevator pitch. Most of you have heard of this. Maybe some of you have actually done it. Just imagine you're walking onto the elevator and the boss is in there and boss gets on and says, Hey, Peter, I want you to tell me what is this data governance piece in the time the elevator goes up or down? And hopefully by the time you get off, you've actually made a good coherent pitch. Yet here are our definitions of data governance. And again, these are ones that have put out there. We tend to say that these are the right ones in the sense that they exotic, and I didn't even let you read them because it's just not worthwhile because none of those definitions would make any sense to any executive on any length of an elevator ride. So when the boss looks over at you and says your data steward, what are we doing? What is this data governance stuff for little words for them? Well, sir, I help manage data with guidance. Oh, yes, ma'am, I do managing data with guidance. And that immediately asks the question, would you want your soul non-depletable, non-degrading, durable, strategic asset managed without guidance? And the answer is generally no. The higher level we go up in the organization, the more I talk there to executives, it's not just managing data with guidance. It's managing data decisions with guidance. And that's the area where most stewards fall down because they don't understand other people make decisions that they have to come back and pick up. Now, to do this, we're going to dive into some architecture real quick. And just to let you know what architecture is all about at a very high level of abstraction is defining things. These are the architecture components and then defining the function of these things. In this case, thing one and thing two both run or whatever that is for. Good old Dr. Seuss. And then how do they interact? Well, again, here we have an example of how these things interact. So organizations have architectures. In fact, sort of a jokie thing here, but it does look a little bit of sense. Here's an Amazon architecture, somebody making a representation of it. Somebody else saying Google. Remember, there used to be three of them at the top. Of course, we know that's been subsumed by Alphabet, et cetera, et cetera. Facebook, we really need to structure Microsoft, come along, shoot up your own projects, right? Apples all centered around one individual and Oracle. Again, just a series of acquisitions in terms of all of this. And again, it's sort of tongue in cheek here, but these these things are reasonably important and you make a difference on this. I like to say that a data architecture is establishing a common vocabulary for the organization so that people and systems all understand what they're talking about. And we're doing that because we don't want to have the Tower of Babel. Again, if everybody's trying to look at the same thing, we're talking about understanding an architecture and this architecture is a digital blueprint of the organization that is ideally shared by systems and humans. The number one question I get asked as a consultant is, can you come here and create a data architecture for us? And I have to say, I'm sorry, ma'am, I can respond to you. All organizations have architectures. So you don't want me to create an architecture. If you had no architecture, you would not be in existence. But the question is, do you understand your architecture? If you don't understand it, then it's not going to be very useful to you. And of course, part of understanding is to document that process. So all organizations have architectures, all organizations have data architectures. The question is, does anybody in your organization understand it and is it documented because if it's not documented, it's very difficult to look at it from that perspective. Most organizations manage some subset of these architecture. I shouldn't say most. It's really one in 10 organizations that actually tries to do this. So if you're thinking about doing this, you're actually looking to take yourself out of the bottom 90 percent there. On the other hand, if management perceives that nobody's getting anything done and that you're just having lots of meetings and nothing's happening, that's going to be a problem, too. So let's talk about the role of strategy. As I already introduced it, the idea is, of course, strategy tells you what's more important than other things. The word strategy never entered our vocabulary until about the year 1950, when the Peter Druckers of the world decided that it was a good word for management. You can see it's gone way, way up since then in terms of its use. So what is our our strategy? Well, it's our master plan, our game plan. Right. I don't actually like those because that gets you to define strategy as a thing, a set of PowerPoints, a document, other types of things in there. Strategy, if you go back to the military context and remember, military ones, wars, so kind of important to pay attention to their perspective, too. The military definition of strategy is a pattern in a stream of decisions. And that is a process that is not a thing. Let me give you three quick examples. Here's Walmart's former business strategy. You all know this already, actually, every day, low prices. If you make an error in Walmart and you happen to be airing on the side of providing a lower prices for the customer, they will not get mad at you. Right. It's just very, very simple that you're following the strategy. Wayne Gretzky also has a strategy that he describes in his Wikipedia article and some of the writings that he's done. His strategy is he skates to where he thinks the puck will be. So if you're chasing a hard piece of plastic around slippery ice and your own skates, what are your chances of catching up with the puck? Not good. So the strategy is go to where somebody can pass the puck to you. And then, of course, you will score or at least try to do something along the line to what Wayne Gretzky actually did. One third example here, and this is a complex strategy. OK, so question. How do I defeat the competition when their forces are bigger than mine? Says Napoleon as he's looking at Waterloo and the answer is divide and conquer. Sounds great. Now, remember, this is a pattern in a stream of decisions that we're looking at. So I'm going to dive into this one just a quick bit. Excuse me. So you know what's going on here? The armies that were facing him and the British in red were being supplied out of a stand that is out on the Belgian coast. Oppression troops were being supplied out of the town of Leish. You can see they're in opposite directions. And it's a well known fact that if you hit an army and make them retreat, the army is more likely to run towards its food and shelter than away from its food and shelter. That's just basic Maslow in that. So Napoleon's plan was to hit them in a way that would make the armies move away from each other to divide them. And then his plan was everybody turn to the right and we'll get the Prussians first and then everybody turned to the left and we'll get the British. I said this was a complex strategy. First hit both armies hard in just the right spot. Then everybody turned to the right and defeat the Prussians. Then everybody turned to the left and defeat the British. Oh, and by the way, do this while somebody's trying to kill you. Right. This is a complex strategy. And in this instance, it didn't work. You can go look that one up in history to see about this. So complex strategies are potentially problematic. For example, here's a data governance process that a fairly complex organization is trying to put forth. They're doing a very good job of it. But does everybody understand that this is much more complex than watch our data? And again, there are specific challenges requiring a very specific set of individuals in order to do this. If they don't realize this is complex, we've got some issues that we need to do. So the strategy, again, a pattern and a stream of decisions means that we're going to start looking at things. Here is one strategic approach. This is not necessarily a good one or anything that a steward should do, but it's one that happens a lot, which is that organizations say they're going to start out with master or reference data. And what they do is they say we're going to control the allowable values that are in the reference category. This gives us a little dot up here in the right hand corner and listing things like the countries we do business in. If we don't have it listed as master data, we can't sell things to people in Mexico or whatever the particular example is that controls then another set of constructs that are called the master data. Again, this is a question like, are you a member of our premium club? Are you using standard data structures, etc., etc. It gives you a little bit more control of data. But that master data controls lots and lots of transaction data. And this transaction data is listening to me. This is where you learn that you pay five dollars for lunch or maybe it's five dollars for an ATM machine, whether you're authorized to do certain things in a security perspective or whether you liked it, something on Facebook. This type of process then leads us to what we really want stewards to do, which is to help us leverage our data assets. We look at our organizational data on the left hand side and our stewards over here on the right hand side. We can see that this has elements of people technologies, which in this case is a lever, excuse me, on that lever. And of course, we've got a fulcrum here as well. If you're again having trouble with those, just ping me during the Q&A session, we'll go back through them again. But there's also a process around this as well, which is to say that the stewards are going to move the lever and the lever is going to affect the data. Gets us to something else too. We need to talk about rot. Rot is data that is redundant, obsolete or trivial. Cleaning up rot is a big part of data debt, not the only part of it, but a big part of it. And reducing rot increases leverage there in that. So we look at considerations around all of this and say the term stewardship is just not widely known. We don't have agreed upon definitions. It's become a de facto widely used, but kind of ill-defined term. Stewards work with architectural components. They have to understand architecture and it focuses their leveraging activities on things that work for the organization. Because if you take a step back from your organization, your organization is literally seen by outsiders as a data machine. All of your inputs and all of your outputs are data. And we could manage all of it very formally. But if we put in too much management, too much governance, too much stewardship duties, it becomes slow and expensive. And if we have too little, we miss opportunities. So one of the things the stewards have to do is to help figure out the right level and turns out that interoperability is the key determinant of value in that particular situation. So let's keep moving on, hopefully I've given you a good definition of why we need to have data stewards. Let's talk about how they're supposed to interact with this. Again, there's a usually a data or information gap in organizations, because most organizations are overly dependent on human beings, what we call wet wear, the stuff that's between our ears, knowledge workers, informal communications and the weakest link in all of that, because organizations have little idea what data they have. They don't know where it is and they don't know what their knowledge workers do with it. And that means the stewardship tends to happen pretty well informally at the workgroup level. But once you get beyond the workgroup, you are without guidance. And imagine also the amount of time that each of your workgroups has spent coming up with their own version of stewardship, which I assure you, they are in fact practicing at this point in time. The data chaff then becomes sand in the machinery and it prevents smooth operation. I say death by a thousand cuts. It's really not. Nobody dies from data death. It's just that things continue to become harder and harder and harder because organizations and individuals lack the knowledge, skills and the maturity in order to look at this. Separating the wheat from the chaff is a critically important aspect of stewards. Is, first of all, they should all be prepared to answer the question. Is well organized data worth more? And the answer is, of course, yes, it is. If you have questions about that, just ask somebody to take a book. By the way, a really good book recommended hardly how to make sense of any mess by Abbey Covert available at Amazon as a free Kindle download. If I'm subscribed to the right services and it's not an expensive book after that, but one of the things that Abby points out is that even before the information age, we had page numbering, alphabetic ordering of indices, things like this to help us be able to figure out what happens in these books and to use these books in a way that makes sense. Now imagine taking the spine off the book, throwing the pages out, taking the page numbers off of them. Of course, you can see that the data becomes a funnel very, very quickly. And the reason that's critically important and it's also the reason that we have so much data that we consider to be wrought, which is data that is redundant, obsolete or trivial on that. But the question comes back, which data do I eliminate? The vast majority of most corporate data is never analyzed at all. And when you come back to this wheat and the chaff thing, part of the job of stewards is to figure out how to do this process much more efficiently and then let's get rid of the stuff that's not worth anything and keep the stuff that is worth something. Because data assets, again, are the most powerful, underutilized, poorly managed asset, I've already said, sold on the pliable, non degrading, durable, strategic asset, when you compare them to finance, real estate, inventory, et cetera, et cetera. Data assets win in terms of the characteristics that they have. But unfortunately, most people still think that data is the new oil because somebody started saying it about 10 years ago and people don't get any smarter about that. You shouldn't think of data as a new oil as much as they like to hear that from Middle East and other places. You should really add a letter to this because oil is a one way production push function on this. Better way to think about it is data is the new soil. And that is two things. One, you don't just randomly walk about your yard and fling seeds places to expect good things to happen. It doesn't. Some of them may work and some things may happen. But if you're going to plant the garden, you prepare the soil. The second thing is a timing issue, too. You do not plant things on Monday and expect to eat those wonderful handover tomatoes on Friday. It takes time to do this. You do need to have some sizzle in the process as well. There's got to be some sort of component for somebody to see what they want on there, but this really means that data does deserve its own strategy. It deserves attention on par with other organizational assets. And it requires professional administration to make up for past neglect. It's so bad. Here's a really interesting example from Ford, Ford's magazine last fall. They noted that American Airlines was valued by the market at six billion dollars on this, but that their American Advantage Program, which is the frequent player program, was valued at between 20 and 30 billion dollars. Obviously, these two things cannot be simultaneously true. The company that owns the data cannot be worth six billion dollars if the data is worth between 20 and 30 billion dollars. This is not a fluke. United had the same kinds of things that occurred in here. Nine billion dollars last fall and their mileage plus program was valued at 22 billion dollars. Again, there's the link for you right there. And the thing this allows us then to look specifically at frameworks. And when we talk about frameworks, it's this idea of guiding analysis. So the first thing stewards have to do is have an agreed upon framework. How are we going to organize the data on this? How are we going to decide on priorities for decision making? How are we going to assess progress on this? This is where good guidance that sounds, again, like common sense, don't put up the walls until the foundation has been passed. And the foundation inspection has been passed on this and put the roof on as soon as you can because there's an inclement weather that comes and make all of this dependent on continued funding around this. Well, a framework for stewardship is just personal mastery of what goes on. Personal vision that occurs, how your personal vision is going to help support the organizational vision, some aspect of mentoring always important for stewards because you are seen as more expert than person who is not in that particular role. Looking for diversity of opinions and ideas coming up with a shared vision, understanding what the tolerance is, both personally and organization for risk taking and experimentation, what types of vulnerabilities and what type of maturity do you need to have in order to do this? What type of awareness can we raise and what type of results can we deliver? So given that as a framework, the way I like to think about a framework for stewardship is that you start off with some organizational data challenges, whatever analysis produces those challenges and then immediately you have to make a decision and that should be guided by strategic considerations. We're going to address this stuff sometime later, put in a bit bucket, come back to it or we're going to try and do it now. And through the stewardship engine, we've got regulation policy that can help. We've got stewardship activities that can fall into two categories, reactive and proactive. Obviously, over time, you'd like to shift from more reactive to more proactive. And finally, there's an important aspect of this. There are going to be monetary and non monetary values in this. And as you start to understand how these things, the stewardship activities create value, that value will continue to grow over time. I mentioned the firehouse model on this as well. And the reason that's important is because everybody knows the firemen don't just go to the fire station and sit and sleep while they're not fighting fires. They have all sorts of other things that they do. Education, training, awareness, et cetera, et cetera, in order to do this. But it's also important that the firefighters, or in this case, the data stewards be a little bit like MacGyver, if you don't remember that show. Harmless. He, of course, could fix anything with a paperclip. Well, it's difficult to think about that, but it is a new way of doing it. And we are seeing more and more organizations adopt this. Let's talk about a couple of specific components within here. Here's a wonderful four quadrant diagram just so that you've got the dimensions here on the left-hand side of the brown lines. The domain expertise is less on the right-hand side. The domain expertise is greater. Similarly, the roles on the left-hand side are more formally defined and the roles on the right-hand side are less formally defined. Notice that I've already established IT and systems development activities as a grounding for all of this. And then let's go to the horizontal axis. Everything that is above the brown line encounters data, excuse me, encounters governed data less directly, more directly below the line. Similarly, more time is available below the line, less time is available on top. So what are the four quadrants here? Well, we've got leadership, we've got the stewards, we've got participants or what we call our SMEs and others, because there's lots of others to get in here. And let's, on the left-hand side is typically where organizations will draw a line around and say, these are the first round of data governance officials that we're going to bring in. This is the first round of data stewards. By the way, critical when you do your pointing of these stewards always say this is the first round because you won't get it perfect. And if you say it's the first round, that way, when somebody rotates off and somebody else who should have been in there in the first place comes on, they won't be insulted. They just had to wait till round two. So the roles here, leadership brings resources to the party. If they don't have resources, we can't fund it. They're going to get some sort of feedback, things that that tell them there are some things about data that we need to do better. Leadership will make decisions, communicate those decisions through the stewards here who will then take action and make changes. This is pretty abstract stuff, but you can see we've got a lot of things that need to happen. This is why it's important to start slowly and build it. Over time, your feedback networks will get better. The ideas will become stronger and the guidance will be better. I wouldn't show this chart to anybody. So here's a less complex version of that same chart. Again, people always ask, can we use these? Yes, by all means, this is what they're here for. Better still, though, if you find a better way of saying it than I've done it, send it back in and we will recycle it and give you credit for it, because that's what we do around here. The data governance role here then is to look at what feedback they can glean from the organization and say, let's add some data governance in here. And what we do is we look at data improving over time. In many cases, however, this is a case where somebody sitting at the bottom of a waterfall and complaining about the quality of the water upstream. Yes, if we do fix it upstream, no problem, but it will take a while for it to come over the waterfall. And that's usually not very comfortable for most organizations. They then say, we probably need to do some things to fix some things faster that we did. So data improving as a result of focus. This is the proactive aspect that I was describing to you. And that gives us better feedback, which means as you start to implement these data stewards in your organization, they can start to become additional sets of eyes and ears and hands that you can reach out into the community as well as to everybody else and start to make things happen in the way that they should happen. Now, this yellow box that I've described here in the middle between the two snails, the fast snail on the bottom and the slow snail on the top, in order to do this, this is kind of critical because this is where most data people stop and we need to go better than that. Although what I've done there by that sign in blue there, it's the approximately equal sign. You can see it fades on because we just haven't gotten good at saying when something good happens in data and we want to celebrate it, we need also to make sure that there's a similar celebration over on the other side. And I say we're not good at it because many data people do not appreciate the business context in which they're doing things. But what you see happening here, of course, in the diagram in which you'll see in your organization as well, is that those pieces that are bold. Yeah, we had two different Xs that both contributed to the same dollar amount. In fact, we could get some really significant dollar amounts if we keep working on it, combining resources and coordinating these activities at the organization level instead of at the work group level, which is where we have been doing it typically in an ungoverned, unstewarded type of a context. Let's look at how strategy fits in there and where the role of the stewards are again, organizational strategy. The only reason the data strategy exists is to support the organizational strategy. And that data strategy is what tells data governance what they should be doing. OK. Organizational strategy says we've got to make more money or whatever it is. Data strategy says how are we going to use data to do that? And data governance says, what changes do we need to make in our existing environment in order to do that? In Peter's world, data governance actually gets to chop on IT projects as well in there, and we can drop that down to organizational operations, put in some feedback loops. And again, I've got a diagram that's too complex. So I would simplify it to this type of a thing here and talk specifically about what are the data assets to do to support strategy that's got to be expressed in business goals, but the language of data governance must be metadata. If we are communicating about vague terms, you'll see people doing things and then not doing the right things. When we figure out what it is we want to do, we then delegate that out to the stewards and governance also should be looking at what is the most effective use of our stewardship investments that we have at this point in time. Who are then talking to them about projects, plans and problems in all of that? The tribal based knowledge has to be transformed into data asset leveraging. And the stewards transform governance by strategy focused action. They apply this framework to the task to understand how to get good at both reacting and proactive activities to incorporate leadership outside of traditional channels that while you certainly will report up in a normal fashion, you're going to find out that data habits of other parts of the organization impact on your roles as stewards there. And of course, finally, we know we can't do it all. We're never going to have the the resources to do this in a great fashion. So the wrong question is, should we manage this data? I know the right question is, should we include this data item within the scope of our current stewardship practices? And either way, document, please, why you're doing that because nobody else is going to remember in two years when you've moved on and somebody else has your goal. Our last section here now talks about the cadence in this. And first of all, let's take a look at how often things happen. These are just some numbers I've grabbed from some organizations that I've worked with. Just focus on the last one. Here's an organization that runs a query 30 billion times a day. Now, that's a lot. And this is where I bring up the concept of a data governance sandwich, because most organizations are somewhat data illiterate. Their data supply is uneven characteristics and their use of standards is also uneven. We can start to smooth these things out and make them work in a nice coordinated fashion. This cannot happen without engineering and architecture. And in particular, it can't happen 30 billion times a day correctly or even mostly correctly without engineering and architecture. And yet I had to go to a tea farm in India a couple of years ago to see this wonderful Deming quote hung up over the cash register. Quality engineering and architecture work products do not happen accidentally. Of course, the same thing is true for data engineering and architecture work products, because data is not a project. Data is a durable asset, has a life more than one year, which means our project deliverables in an IT sense may be OK for two weeks or 90 days. But data evolution must be measured in years. It evolves and is typically not created out of the process. And it's significantly more stable than the process or the IT infrastructure that delivers it in there. And this way you should be not proceeding on these projects unless you have ready made architectural components that are prerequisite to agile or any type of development. In this case, the only alternative is to create additional data silos. And that's generally not a very good thing to do. Most of you will be familiar with the difference between a program and a project, a program has a ongoing and a link to budgetary. I'm not going to go through each of these with you. But the idea is your data program was on a call just yesterday and somebody said, yeah, we're just looking to finish up this data governance program. I said, your data program must last at least as long as your HR program. Nobody's going to look around and say, hey, I think we're done with HR now. We kind of mastered it and everybody's going to behave from this point on. No, you need a data program and it will last as long as your HR program in your organization. Similarly, you need people to start conceptualizing what the organization is in a different fashion in 90 percent of the organizations that I work with. Your organization is all about data management makes plans. They communicate those plans. That's data down to people. And in some cases, some of your organizations make physical products. In the most case, your organizations are making data products that produce out of this. And if we don't know what business we're in, it becomes very problematic. Now, the way I like to do this and the way I focus the data strategy book around was a book called The Goal. This book is a wonderful book. It was recommended to me by my wife and I say recommended with air quotes. She simply said, as we were getting together 15 years ago and starting to have business discussions, she said, I'm not going to talk to you about business until you've read this book. And I kept asking her questions and she said, did you read the book? And I finally said, yes, ma'am, I read the book. Now we can have discussions. Well, the book is about the adventures of Alex who goes off for a company called Unico and tries to save the day. It's a wonderful book. It's actually a narrative. It's a very fun book and we use it in classes today, even though it's 30 years old. But what it really does is teach a system called the theory of constraints. In any system, there is always one constraint, at least one constraint that focuses on identifying the constraint and eliminate. And you can see here, the person at station 10, the work in progress piling up is keeping these other two from working on this. Well, it's a great way to go about fixing data change because data is no stronger than the weakest link that it has in the chain. So these organizational practices, when we look at them from a theory of constraints perspective, what we're seeing here is that most organizations have some data stuff that they do, but that tends to be a black box. They don't understand it. Boy, they've got analytics, they've got data warehouses, they've got March, they've got all sorts of dashboards and things. And the problem here from a governance perspective, which is something that stewards should be examining, is that the feedback tends to be on the right hand side of this diagram. But we notice these numbers aren't correct or whatever. We correct them here, whereas clearly it would be much more useful to come back and fix them as they go into the black box rather than out of it. Another way to think about stewardship from a specific perspective of innovation is that most organizations have no stewards and there's only two things you can do in terms of innovation. You can improve your existing things or you can do something new. Pre-go, that's probably not right. So if we go to the next piece that we want to be on, it's a ball march in particular, just we understand they're fairly good at efficiency and effectiveness around that. And we'll pretend that Apple is really good with creating strategic opportunities up here. So Apple's the innovator and Walmart's the improve operations here. And the reason I want you to think about it this way is I want you to imagine stewards in Walmart's organization who are really good at doing efficiency and effectiveness and asking them to be innovative. Their heads would explode. Similarly, take Johnny Ive, who's a really erudite British guy who used to introduce all the iPhones and the iPads. This is the lovely thing and it's floating through the air and doing all sorts of things and tell him to be cheap. Right. It's not going to work. These are two things that are different. And if you're trying to do both of them at the same time, it's even more complicated. Only one in 10 organizations is even really trying to do this well. So if you're trying to do this, you're already, as I said before, out of that lower level. And of course, the clear path for most organizations is to start with some efficiency and effectiveness and use that savings then to go up and create the innovation pieces around all this. When we look at data strategy from a perspective, many people say, OK, well, data strategy should be subordinate to the organization and IT strategy. And again, this is just if you couldn't hear it, that was Morgan Freeman saying this is wrong. He says much better than I do. Yeah, absolutely wrong. The organizational strategy should absolutely guide the IT strategy, the data strategy, but the data strategy has a lot more influence on the IT strategy than the other way around. And yet if you look in your organizations, you will not find that this is the case. Most organizations are very confused. They're saying, OK, we got to do something better. Does that mean we're doing data centric, data driven, data focused, data first? I like to use the KISS principle. Keep it simple. So we've created something called the data doctrine. This is the second version of it. It's going to come out in the literacy book here. And it's modeled after the agile. Excuse me, doctrine, which is very simple. We are uncovering better ways of developing IT systems by doing it and by helping others do it through this work. We have come to value and they put down four things here. But if you remember the IT, the agile manifesto, it was actually looking like this. That is, while we value things on the left hand side. Well, we value things on the left hand side more. We value things on the right hand side less. I said it backwards, I'll say it one more time just to make sure. While we value things on the right hand side, we value things on the left hand side more. And this represents an incredible change for most organizations. Just look at the types of different stewards that are here in this type of an organization, just picking one off of a random little bit group that did some work with. Again, imagine trying at the start of your process to say, here's a wonderful book by Dave Plotkin. Let's read it. Oh, now I've got to define seven different types of data stewards in here on our first go round. I'm sorry. No, don't do this. By the way, the rest of this says once you've got that many types, you need also an auditor in there and of course a manager to take care of that. Again, David, I love the book. It's a great book. It's a really good reference book. It is not the place to start out when you are starting to do data. Start simple. Think about it for just a minute. Strategy number one, good guys are here, bad guys are there. That's one strategy, right? If we change the playing field a bit and say the good guys are here and the bad guys are there, you're going to have a different strategy. And of course, if the bad guys are here and the good guys are here, you're going to have a third different strategy. So this is why you don't want to put things out that are too locked in, too rigid, not able to, in fact, do everything that you need to do. So we've talked about why you need data stewards. The key is that nobody has been taking care of your data beyond its access at the workgroup level, which has been working reasonably well. But the inefficiencies of everybody learning how to do that well, coupled with the combinatorial power of data, mean that we should make the case and hopefully I've made it for you here today, that that should be managed not at the workgroup level, but at the organization level for some data elements, that the data stewards are needing to focus on specific tangible things. They're not like their policemen sitting around with a radar detector and looking for things that are wrong. There are plenty of data debt related issues that you have in your organization that you can be proactive about and to understand that this process because it is a different cadence, it has some foundational prerequisites. You need to fix the data debt before you can properly manage it and that the need for simplicity, agility and most important practice. As in, let's do some things with data stewards and learn from that process and make it an active learning process. We've just got a few minutes left before we turn it over to Shannon for the Q&A. And I want to do a couple of quick takeaways around this as we get ready to the top of the hour. Since stewards own the results, they can control the remediation process. What that means is that stewards are uniquely empowered and we need to make sure we give them the types of information they need to have so they can be successful in their jobs. The need for professional stewards is increasing. One of the things we are doing at DAMA is to try and push data stewardship training programs into community colleges. There's a tremendous opportunity there for a two year degree in data stewardship. And this is easy when you think about the increase in the data volume that's out there, the lack of practice improvement at this point. And I've got some bits in the data literacy book that show that our data literacy over the years has not improved while the data has increased massively. In fact, there's a statistic out there, the gentleman that wrote the forward for the book, so that all of the data that was produced in the last two years far exceeds all the data coming up to it at this point. So we are just looking crazy, crazy increases in volume, but we're not doing anything about improving the practices. Data stewardship in and of itself is a relatively new discipline. It must conform to organizational constraints. You can't operate outside of the bounds of the organization and therefore there is no one best way. But if you start saying I invested X and was able to deliver through data governance and stewardship effort value that is X plus in some way, the best the worst thing somebody can argue with you about there is we didn't do the right type of savings. OK, I saved the wrong million dollars. No problem. Point me to the right ones and let's get it done. That the stewards must be driven by a strategy that complements the organizational strategy. So many times I've seen 100 page data strategies created by a big expensive consulting firm out there. And it's just not a good way of taking a look at it. Data stewards direct data management efforts, they will be the ones that talk about specific things and then come back and check up on them. And finally, the language of data stewardship is metadata in here. Process improvement can improve stewardship and organizational practices around all of that, but we are at the top of the hour. And so now it's time for me to stop talking and turn it back over to Shannon, who will start to ask questions. And I am still looking forward to just one more thing real quick. Good book on this, my colleague, John Ladly's second edition of this book is one that we want to take a look at. So, yes, let's jump over to the Q&A piece on this now. Hi, Shannon, are you still there? I am. And yeah, thank you so much for another great presentation. I'm sure John will love the plug. It is a great book. Thank you so much. And just to answer the most commonly asked questions here, just a reminder, I will send a follow up email by end of the Thursday with links to the slides and links to the recording to everybody. So diving in here, Peter, our data stores made or acquainted, is it better to find people in your organization who will be fantastic data stores and train them? Or should you bring experience data governance specialists in from the outside? Let's talk about that from the types of knowledge and skills that you need to have as a data governance professional. Yes, there will absolutely be times where it is important to get external expertise in here, particularly as you get into areas that are regulatory or otherwise governed from an external perspective. The vast majority of organizations, however, do not need to have that and that you can find the source of expertise by going around and looking in your organization, but I'm a data person. So I'm going to fully admit that I fall into this category as well. We data people tend to be a little geeky sometimes, right? And if the geeky person isn't able to articulate the value or the process that they are trying to do, the how, when, and why of data stewards, they are not going to have a very successful process. So an important characteristic that at least some of your stewards must have are people skills, what we call the traditional soft skills. And the reason for that in particular is because we've surveyed for years and years and found out that only 10 percent of organizational challenges are technological, that 90 percent of organizational challenges are people and process issues. And this is the reason for governance and governance is implemented by stewards so we could draw a straight line from that all the way through to the end. By the way, the study is at New Vantage Partners. I think if you just Google New Vantage Partners on the web, you'll see he actually posts about six or seven years worth of results there. So you can not only just watch this 90 percent that I'm talking about, but you can watch it change not at all over the past couple of years. I say not at all. It went from 86 to 91, but still the ratio of 10 to 1 is absolutely in there. Great question. Thanks for asking that. So can you give us some examples of how the benefit of data governance can be quantified to help make the business case for investing in data stewardship? Absolutely. Turned out I've got a little book out there. It's one of the ones that's on special. They called Monetizing Data Management. I'll just give you a couple of ways of looking at it from a couple of perspectives. The first one was the easiest data governance and stewardship initiation that I ever did, which was one we did with a part of the US Army. On this and the interesting thing, culture, of course, plays a big role in all organizations and no small role within the US Army and the Army basically governs a lot of things. And when they found out data wasn't governed, they had to fix that, right? Fix it right away. So that was a great example of using that particular piece to focus in there. But culture is a critical component of what's going on here. And that's where things have to change as opposed to technology on that. So it's I think not necessarily the case that you can't value these things or that you can't value them perfectly accurately, but it is the case that you can put some dollar costs on things. And again, I gave you the one in the Army, which was like, oh, my gosh, that's the way we do things that we have to fix it here. But I actually have a personal total. Maybe I should work this into my intro speech Shannon on the things. I can point to a thirty five year track record here. And I have personally helped organizations save more than one and a half billion. That's with the B dollars on this. So I've gotten very good at these practices. And it's really the subject of another webinar in terms of the actual monetization steps, but they're not hard. Basically, you look at what your knowledge workers are doing, cut out clicks, cut out steps, cut out delays in the process. And you will make things more productive. And when you make things more productive, you should be able to attribute that increase in productivity to some kind of dollar cost on it. We can go into this in more detail in another environment there. But I really get disturbed when people say you can't monetize this stuff. Absolutely, you can. I have a billion and a half dollars that I can prove that I saved organizations and you can prove that you can save your organization time, money, effort and reduce the risk by similarly having good stewardship operations in there. Thank you for the question. I love it. So, Peter, how to measure data debt and how do we control and reduce it? So the first general concept around data debt is that your organization has a lot of data integration activities that seem like they shouldn't need to occur. Again, if you're you're taking things and before you can send them to I'll give you a specific example as a customer in the Midwest, it's a logistics organization who they were actually taking all of their bills. Now, just to understand again, the context here, we're there to help them get off the mainframe because somebody decided that it was too expensive to be on a mainframe in the cloud. They had been told is cheaper. By the way, as a data steward, one of your standard speeches should be nobody has ever saved money by going to the cloud. It's just simply not the case. They get lots of new capabilities and things can be better. But saving money is if that's your primary reason for going to the cloud, you're already lost around that. I said I'd take the story on this. While we were out there working on this get off the mainframe project, I found a room of about 100 people and they're kind of thrown papers around and doing the stuff I found who was in charge of the room because they let me run around organizations when I go visit them on this. And again, good, good stuff. So we looked at this and what they were doing was that the customer data coming off the mainframe was so poor, they were afraid to send the bills out. So they would take all the bills, intercept them as they came off the mainframe, put them in this group and this group would run around and they would change the date of the service. They would correct the date of service, the customer's name. They would correct the amount of service they provided. They would correct the cost that they provided. They would correct the date of service. It was provide lots and lots of things. The bills are always all wrong, right? And I got talking with the individual. So when do you think you'll be able to stop this? He said stop this. I'm getting right at another hundred people to this room. By the way, that was a six million dollar investment that had been somehow approved by this organization. And I went, whoa, no, you don't want more people. You are just treating the problem here. The real challenge is that you have a data quality problem that can be fixed. And since that individual was not going to listen to me, I went around and found the CFO and spoke with her and she said, look, there's simple equation, Peter, we're about a nine billion dollar a year organization. If you can improve cash flow for me by 30 days, that's worth eight hundred million dollars at a net present value, which is a really large sum of money. So absolutely, this is what we should do. And more importantly, we should look at the governance processes that allow a low level manager to increase the organizational headcount by a hundred people at a cost of six million dollars without everybody understanding what it's doing and why. And clearly, that six million dollars should have been put into cleaning the data debt up in that particular organization. By the way, a lot of times we find out that the data debt is not what it seems. It's more along the lines of the data is there, but it's not structured properly or fields are out of whack or people don't really understand what it is they're looking at. But data debt is data that is ungoverned, that is of unknown quality and that people are still using. And that's a challenge in most organizations and a very significant source of operational risk, more so for some industries than others. Again, great question. Thank you for that. I love how many topics and questions that the data storage topic was a huge topic. I mean, just all over the place. Yeah, I love it. So and thinking of changing the topics a little bit, you know, with regard to optimizing the integration of data strategy throughout off actions of business, any thoughts on how to better raise data literacy that goes beyond the division needs and provides more a more robust and team ownership that is aligned to business vision and mission. Fantastic. One of the things Steward should learn is where data comes from and where it's going, sources and uses, right? And if you don't, if you're looking at the data right in front of you, you can't do a very good job of being a data steward. So understanding where the data comes from is absolutely critical. And those ideas that data come from a certain place leads us to the ownership question that I know as we get back into in a little bit. And I'll just divert there for real quick. One of the things you want to make sure that you do as a an organization that's setting up a group of data stewards is to absolutely make certain that everybody understands the only ownership of this data is at the organizational level. Everybody else has a fiduciary relationship to that data, which means they are managing it on behalf of somebody else. It has been placed in their care for the purpose of being cared for well. So it's not just like we're throwing it in the closet. It's that we're giving it to somebody whose job is specifically to make better use of that organization according to the organizational strategy. So when you look at what's happening from an ownership perspective, the worst thing you can do is designate anybody in the organization as any kind of a data owner. Do not do it. It is the worst thing that you can do. You can own processes, but if you own data, you are setting yourself up for absolute failure in that area. I'm sorry, Shannon, I went off on my ownership tangent. Would you remind me the purpose of the question that I launched off into that? I love it. At least I admit it, guys. No, it's good. It's good. It's great. So, you know, you talked about the strategy a lot. So any thoughts on how to better raise data literacy? And that goes beyond the division and needs and provide some more robust team ownership that is aligned with business. Shannon, get ready to go mute, because, of course, what I forgot to do was put my own book on there, right? So hopefully next month, the data literacy book will be coming out. And we will see some topics around that, including hopefully some sessions at the upcoming DGIQ event that we're getting ready to hold in December around all this. Yes, the key for literacy there. And when I started this book and my co-author Todd Harbour and I started this book about a year and a half ago, we looked at what was being done in literacy areas and most of the data literacy discussions are about whether somebody with a PhD and a specialization in data science should have 10 statistics courses or 20 statistics courses in order to be called Data Scientist Class A, right? Well, if we're talking about people that are within the circle of the data literate, I'm sorry, I don't care. That's a really harsh thing to say, but that's not where society is. What we need to do is raise data literacy of everybody in society, in particular, those who are connected to the Internet with mobile devices that function as supercomputers. So absolutely, we cannot, cannot, cannot look at data literacy as only the data literate data literacy is a skill that everybody on the planet needs to have. And in the book, there are some very specific guidance and what I've described as citizen data literacy needs that will help organizations and in particular, knowledge workers, you already saw in the presentation that I tied knowledge workers directly to data literacy types, topics and that knowledge workers have to understand these things and stewards have to make sure that the knowledge workers are, in fact, literate at a certain level. So, yes, there are some ideas in there. I can't go into them right now, but I think the idea generally is that we need to stop focusing on gazing at our navel and instead look at how we are playing a role in larger society and how we can help society all the way around. Just think about explaining pandemic math to people. There's been no question that people are having all sorts of reflection about the way in which society responded to the pandemic by not understanding exponential increasing growth. Right. If you don't understand that, that's like it starts out. I've got three hospital beds on Monday in a 48 person hospital. And if the number of covid cases are doubling every day, I have three beds occupied the first day. I have six beds occupied the second day. I have 12 beds occupied on Wednesday. On Thursday, I still got half my beds available. But on Friday, all of a sudden I have no beds. And what am I going to do about Saturday? Not understanding what I call pandemic math has been a main challenge to people's developing intelligent responses to the the virus and everything. So, yes, literacy, not just of our data people, but literacy of our citizens is the area we need to focus on. Great question. Thanks for the plug, Peter. When you say since stewards own the results, they control the remediation process, how far should they be permitted to go? We are currently working on one department have identified the candidate data stores, but what privileges should the remediation entail? Well, again, there's you need to operate with an organizational guideline. So I'm not saying you go off and do things that are illegal or fattening in that context, but there are opportunities for some really innovative things to be brought in by stewards. I've seen stewards come to me and say, Peter, I've been looking at this problem that we've been working on for a little bit. It looks to me like if we eliminated this system here, everything would be better because this system tends to introduce data errors in it and nobody's really using the output. But nobody's looked at the system for a long time. So I think they just forgot it's there and maybe we don't need it anymore. And yes, turns out for them, that was a very good answer. The question is, can we from a remediation perspective apply the things that need to be remediated? That's a terribly redundant self-definition there. So let's see if I can think of another word besides remediation. Corrections, right? Of course. If your correction involves killing people, no, that's probably not going to work. But if your correction involves maybe reallocating responsibilities and moving things around, this is what I said. The soft skills are so important. It's not going to be that you're going to buy software package X and that's going to help your data stewardship. Stewardship is not about technology. Stewardship is about interacting with people and systems. And that's the set of skills that we need to make sure that we've got in our organizations in order to be able to do this properly. So I love the push for stewardship training and education. Our sewers are tasked with defining business terms. Do you have any education or training on defining business terms? There are a number of courses. I think you do some of the diversity on the governance thing about glossaries and things like that. Yeah. Yeah. So I don't personally have things like that. I've got some governance and stewardship courses and things like that, but nothing on the specifics of the glossary other than keeping an eye on it. Actually, there's a an interesting article. I'll write it down and I'll forget. I'll include it with the slides at the end about why a business glossary may not be the best thing to have. They really talk about it in terms of the data dictionary. And I think it's a reasonable question. So the idea of building a gigantic data dictionary that's going to have all of the terms that you need to have in it to manage all of your organization is something that we proved can't happen back in the 1980s. There was a group that decided that we could describe everything that happened within the Department of Defense in 5,000 key terms and that if we just defined them all properly, we'd be able to use that. And I won't go into it here, but we were able to make pretty short work of that proposal because there was simply no way that it was going to work for a number of very good solid reasons. Again, I won't get into them here. The key, though, is that when you look at data dictionaries, what we're really talking about is two things. When I say tank, does everybody in the room know what I mean by a tank? And of course, you can immediately start to picture. I've said US Army several times in this particular presentation. So you might be thinking the type of tanks with treads and and guns. And, you know, we just pass the Tiananmen Square anniversary. So maybe that that image comes to mind for some of you. If I'm thinking about a tank of gasoline, that's a very different piece. Another way of approaching that same process is through the use of something I call a control vocabulary. I'm not trying to discourage glossaries. In fact, again, a different talk. But the example that I've seen work best actually took this organization about five years to come up with a very, very good set of data glossary components that they use, and they didn't try to define everything. But when they found something and this is the key why it relates to people and process issues, so importantly, again, I won't ask you guys to respond here. But if you've ever worked in oil and gas industry, one of the concerns that they have is safety. So we start out all of our meetings in these industries with a safety net. Nothing wrong with it. Just keeps safety foremost in top of people's minds as they're thinking about things the same way that Jeff Bezos when he was running Amazon always had a chair at his table for the customer so the voice of the customer was heard in those cases. So it's a put it to the top kind of a thing there. The idea, though, around this was the process that they used to get to that dictionary. Now, just to let you know, I'll go ahead and tell you the company was Nokia, a very wonderful organization. And Nokia, of course, starts out as a Finnish company, but they wanted to play in the big league, so they told everybody that all meetings in Nokia, everywhere in the world would be conducted in English. So we'll take the poor Finns who are so multi-natural and so multicultural already and make them learn yet another language so they can get around in the world. And they did by golly, I was very fortunate. I learned a couple words of Finnish in my four years that I was there, but I was not very good with the language. I'm doing this in a long way, though, because I want you guys to hear the story. So what happens is in Nokia, when they had a question about a term, they would stop the meeting and they'd go, should this term be added to the Nokia term bank? And they would vote and if it was a positive vote that this term first thing I did look to see if it was there already. I'm sorry, I didn't start out the right place. And if it wasn't in there, then they take a quick little vote and they submit it. And once a month at the Friday afternoon somewhere with a little bit of alcohol, they get together and start talking about what terms should be added to the term bank and what definitions should be used in there. This was a formal process and everybody in the company knew it and understood it and did it. And it was baked into their DNA. It was a wonderful way of dealing with these glossaries and these types of problems on this. I have been to lots of hundreds of other companies and not seen anybody do as good a job of this as they have. And the main reason is because they want to go buy something and then fill it full of stuff, right? Well, if you fill it full of garbage, garbage in, garbage out, right? So, again, I don't want to discourage the idea of coming to grips with terms, but there are other ways of doing it besides buying a seven figure data dictionary that you need to have in order to get some results from it. There's lots of other ways to do it. And some of them are much more efficient and less risky. Good question. Thank you. All right. So do you have any recommended reading for someone who is data governance professional, but new to how to tackle stewardship in a company that has a history of very rudimentary approach to the process? It won't hurt you to read Dave Plotkin's book and I'll go back to the slide that has Dave's piece on that and John Ladly's book. So those are the two I would start with at this point in time. Again, David Plotkin's book here. Let's see. Let me show you to the right called Data Stewardship. Great title for it. An actionable guide to effective data management and data governance put out in 2014 on this. And again, he's done a fantastic job of trying to describe these different types of stewards and their roles that are within there. And for the price of the book, it's worth it because you may discover that the only things you need to have are domain data stewards. Again, I'm making this up as opposed to all the others. Again, I'm not sure how you discover a legacy data steward around it because my definition of legacy is anything that's in production on this. But the idea of understanding what these stewards do is a very good place to do. So certainly that one. The other one is John Ladly's book. As you said, Shannon, I want to tell a story about Ladly's book in particular, though, this is the second edition. I mentioned that in particular and I was talking to John just a couple of weeks ago on this and he said, yeah, you know, if you really want to see what's happening in the data governance world, I wrote this book 10 years ago and this new version of it is very, very different from the first book was the first book wrong. No, it was correct for the time is what he said. But we've learned a bunch more since then. So don't think that just because it's in a book, it's the right thing to do. Or it's the only thing to do. Keep keep in track with this stuff. And most importantly, continue to do this interaction to all are doing so well with us today at the various conferences that we are going to get started. Again, data governance will be up in December, first week in September, first week in December, Shannon. Yes, there we go. Thanks. All right. I think we got time for at least one more question here, if not a couple. So what is the best practice around identifying these stores? Ask for volunteers for starters. I don't do it that way, though. I don't walk into an organization. Say who wants to be a data steward? Because most people are like, huh, you might as well ask your dog that question. Right. So instead, what I do is I hold particularly if we're in the fall season, I hold like a data horror stories event or something along those lines. And you may as what comes out of the woodworks. If you can get generally good just, you know, hey, Peter's here and he just wants to get people together to talk about data for a little bit this afternoon, well, they will come out of the woodwork and they who are the data people who are concerned can tell you who they communicate with in management about this. And that's where I would go to look for that first round of stewards is to say who is both interested in data, but also understands how data works in the business. And again, just worth a little bit of a deviation on this. I was working with a data scientist a while back and she was telling me a great story, which was a learning process on her side. She went running into the the boss at one point and said, hey, I got an 86 percent match on something that I was working on and was totally unprepared for the response from the boss, the boss turned around and steam coming out of his ears as eyes are bugging out and says, we never do anything at this company less than 110 percent. So you go back there and get that 110 percent and I don't want to see you until you know that kind of response. It's like, oops, clearly another conversation needs to occur here in this. But more to the point as she was getting into the the business context of the problem she'd been given, she found out that she'd actually reached her threshold on this, which was about a 69 percent number would have given her the information that she needed to have. But that occurred two years ago and she'd spent an additional two years squeezing it from 69 percent to 76 percent. Whereas if we had properly understood the context of where this innovation needed to go, we could have put it in practice two years ago and started saving money or making new money two years ago. Again, it's just unfortunate communications that occurred in there. And as somebody has said, oh, and by the way, you don't need to solve the problem all the way. If you can get to a 69, 70 percent solution in here, we are good to go. This will help us tremendously. There was no conversation that was mentioned in there. So the stewards are the ones that are going to provide this context for everybody in order to come up with it. I love it. All right. So we do have time to just slip in one more here, Peter. Do you consider the data stores and data owners are overlapping or distinct roles? Oh, boy. So somebody said data owners. And if I was there in person, I kept keep a five inch nerf ball with me. And I whip it out of my pocket, throw it in your face. No data owners. That said, I'm sure that the concept that they were trying to do was to say, look, somebody is absolutely in in in the sense of most responsible for that. But yeah, I think that the answer to the question there is overlapping, I think they are the same same role. I don't think you want to have somebody who has an ownership role in data at all period end of story. But those that do get called data owners or that claim the day. I mean, think about it. What data does accounting actually own? Right. Accounting's data comes in from everywhere else in the organization as we do this. Again, great question. I hope I'm real clear on that. Absolutely. The word data owner is just not something that you can have in your organization. It is not a recipe for success. Yeah. And Peter, thank you for saying there are no data owners. But how do you describe the CIO? Is the CIO not a data owner? Where are, you know, what are the risks of mentally of, you know, we own this data? So most CIOs, nine in ten of them are chief integration officers, chief information technology officers. And if you ask them to do more with data, they'd have to drop something else off their plates, which means, you know, your mobile wouldn't work or your ATM would stop working or something else. So CIOs are generally not in charge of data anymore. We're now recommending that that be broken out into a separate data leadership role. Many people call them the enterprise data executives. The Gartners of the World decided a CDO should be the right title for them. On this, we have not resolved this issue, but it is clear that if we don't put a single person in charge of this and focus on it, remember, the data is increasing at an increasing rate. So we are not increasing our capabilities at a similar rate. We're going to be buried in this data avalanche that's going to do it. And only groups that can handle it really well are going to be able to survive. Everybody else is going to be sort of stuck at the mercy of somebody else. I don't want to paint a doomsday picture for you. There's lots and lots of you out there that can do this. And the good news is there's jobs available for everybody because we need it. I love it, Peter. Well, thank you so much. And thanks to all of our attendees for being so engaged in everything we do. Just really appreciate it. But it is all the time we have scheduled for this webinar. Just a reminder, I will send a follow-up email for this webinar by end of day Thursday with links to the slides and links to the recording. I'll get you all the additional information and resources that you were asking about. And that's it. So thank you, Peter. Thanks, everybody. I hope you all have a great day. We'll see you in September when we come back to talk about data quality. Thanks, Shannon. Bye, everybody.