 All right. Well, here we go. Welcome. Hello, everyone. My name is Paul Diaz and I'm the Webinar Production Assistant from Dataversity. We would like to thank you for joining today's Dataversity Webinar, Data Management versus Data Strategy. It is the latest installment in a monthly series called DataEd 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 via 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 or questions via Twitter using hashtag data ed. If you would 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 for that feature. And to continue the conversation and networking after the webinar, just go to community.dativersity.net. To answer the most commonly asked questions, as always, you will send a follow-up email to all registrants within two business days containing links to the slides. And, yes, we will record recording and will likewise send a link to the recording of the session, as well as any additional information requested throughout the webinar. Okay, then. So now let me introduce you to our speaker for today, Dr. Peter Akin. Peter Akin is an internationally recognized data management thought leader. Many of you already know him or have seen him at conferences worldwide. He has more than 30 years of experience and has received many awards for his outstanding contributions to the profession. He has written dozens of articles and 11 books. The most recent is your data strategy. Peter has experienced more than 500 data management practices in 20 countries and consistently named as top data management expert. Some of the most important and largest organizations in the world have sought out his expertise. Peter has spent multi-year immersion 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. Thank you, Paul. Send me a picture. We'll get you up there on the marquee for the next one of these things. Hi, everybody. Good to be with you. Thank you for taking your time to learn a little bit more about data and data management and all that sort of good stuff. Today's topic is data management plus data strategy equals interoperability. It's a little poetic license for some materials, all the exactly the same. What we're going to talk about today are some very important data properties that need to be understood so that you can get the rest of the problem. There's a serious deficit in data literacy worldwide that we have to address, unfortunately, and there's still confusion as to whether data is a business or an IT function on this. Those lead to the question of where are you going to put your data management program, which of course before you understand where to put it, you have to understand what it is. Why it's important and let's talk specifically and frankly about the state of the practice. We'll get into some functions that are required for effective data management. Then we'll look at a piece of data strategy as well. There's a structural approach that we need to take a real emphasis on simplicity and not on writing on thinking. There's some foundational prerequisites that are going to be absolute barriers to being able to do this correctly. And we'll finish up the strategy section with a little focus on the theory of constraints, which is a really good way to set about practicing the intersection of the both of these. Because as we've said, data management plus data strategy equals interoperability. And the key is we talk about them oftentimes as having to work in action, but what we really want them to work is in concert. And so that'll be a key takeaway for everybody as well. We'll get to the idea that coordination is a necessary prerequisite in all of these, and then the Q&A as well. Let's dive in on this specifically. It's a really good idea to be able to understand what we're talking about from a data management perspective, how much we're really talking about. So this is a wonderful graphic of the company DOMO.com. I see the reference is right down there in the bottom. They do this every year and it's a wonderful thing and I'll show you why in particular, but just for last year, every single minute of the entirety of 2009, pound sign love was posted 23,000 times a minute that number going up or down could be an indicator of things. Netflix before the virus in 2019 streamed 700,000 hours of video every minute of every day of the entirety of 2019. You get the picture four and a half million YouTube videos are being watched at any one minute, 180 million emails that 55,000 Instagram photographs 10,000 Uber rides. Tender being swiped back and forth watching lots. I gosh, I hope you didn't invest in cryptocurrencies because we had 1.25 of those created every minute of 2018. Now, let's take that and take a look at just a couple of the numbers over time. So I just showed you the 2019 numbers here and what you're looking now is how the numbers have been reported prior to that. Again, this is the number of YouTube videos. So over I can keep them on the same scale. I picked all of these gigabytes of wireless information that's going back and forth. The number of jiffy just served. I have to tell you, I do not know what a jiffy jiff is, but there should be a lot of them and Google searches. Of course, everybody knows what that is key to this is that we've got information. Unbelievable exploding. This is a chart that shows that most of the information that exists today was not did not exist until very recently, and it's expanding at an expanding rate. The real challenge is what are we doing to address this amazing expansion. The answer is not enough when we measure that 50% of the nation's unemployed youth are functionally illiterate. They certainly are not data literate around that. The government actually does measure some of these stats in a way that are useful to us they measure three different types of literacy. Again, ability to see and use and respond to written text numeracy the ability to use basic mathematical and computational skills and digital problem solving which will fall into our area very nicely. And the problem with the data that I'm showing you here is it is statistically unchanged between the last time it was measured 2017 and the prior time, which was for some reason labeled 2012 2014. I think I had a switch over at that point. It was what it was a problem. This is important just because of course not all data is equal and we do have to look at the process of separating the wheat from the chaff. So I hope you agree with me that the basic premise that better organized data increases in value. Imagine being handed a pile of pages and told that you could reassemble them into a book, but they've had neglected to mark them with the page numbers on the individual pages so good luck with that right in a similar analogous fashion, poor data management practices and therefore costing organizations a lot of time, money and effort around this Tom Redmond refers to them as the hidden data factories around your organization. I'm really sad fact about all this though is that minimally 80% of the data in your organization is rock. So if you're looking to relate to yourselves, what am I doing listening to this crazy person on this webinar who's calling my data rot well it is an acronym. Rot stands for data that is redundant obsolete and trivial. My wife actually corrects me on this and says it's redundant incomplete absolute trivial but I'm already insulting everybody enough by calling it a rot much less a riot. So the problem is getting people to take me seriously around it and by the way the only argument I ever get with this number is that it isn't large enough. I've had people tell me as much as 95% of their organizational data falls into the category of rot the question is, what would you want that much stuff that says roughly speaking you've got five times the amount of data that you need. So we need some way of, first of all, identifying it so we can tell one from the other and then second of all deciding whether we want to make continue to maintain it or not. Different questions will get around to those and just a little bit. Another component of this is that those assets that you should be taking care of the non rat data become your data assets, but only with a lot of efforts. These data are your soul non depletable non degrading durable strategic asset that we have in organizations where we compare these types of assets to financial assets other types of assets that we have in the organization. And they don't possess the same quality. These are unique among the strategic assets that we have at the organizational perspective. And this, of course, leads people to glowing things and say things like data is going to be the new oil. I really don't like this phrase. And the reason is because data is not, excuse me, oil is not considered to be a reusable component, whereas data is much more valuable on the reusable side of not reusable side. So I like to change the language around this for just a bit and say, data is not the new oil is the new soil. There's two components to a soil here. Those of you that are gardeners will understand that you carefully prepare the soil that you put this into. You don't just ran which are your seeds about the yard and expect good things to happen. And secondly, that you don't plant things on Monday and expect to eat them on Friday unless you live near Chernobyl. It doesn't matter what we do as data people, we have to sell this stuff. So if you're going to call it bacon that works perfectly fine. Long story short, as such data as a strata strategic asset deserves its own strategy in terms of tension on par to similar organizational assets and professional administration to make up for passing the black. Because you see, when we look at a knowledge worker, the way I define a knowledge worker is somebody in your organization who works with data. It's a pretty objective criteria. And yet, we teach them nothing about data as a general practice. And of course, the percentage of them that deal with it daily is 100%. Even worse, when we look at what happens in our colleges and universities and I'm speaking as a 10 year university professor here, we teach them one course in how to build a new database. First of all, if there is one planet we do not date, excuse me one skill, we do not need more on planet earth. It is how to build a new database. The real problem with all of this is not just that this is the only thing we teach undergraduates about, but other it professionals who have been through our programs, get the idea that data is a technical meaty skill that is needed when you develop new databases. So if they are integrating ERPs, if they are creating new software, if they're doing process reengineering they think we don't need the data people involved, because they are not creating new databases. I can't stress the importance of this, but it is a huge problem. One of the second portions of that huge problem is that we've taught them exactly how to use a hammer. And the problem is when you only tool you know is a hammer every problem is seen as a nail with apologies of course to Abraham Maslow, given all of that. And this leads to really astounding pieces such as a question being asked of somebody in one of these classes, come from a textbook, you know, calculate the sector access time the disc rotates blah blah blah blah blah. It's a nice math problem and it's very easy and faculty gravitate towards these, because they are easy to see whether they get the correct answer or not. The only problem with all of this is two fold one the discs no longer rotate. So as soon as you say that the students understand that the teacher does not understand this, and that immediately diminishes the unfortunate instructor in their minds. But this is a true statement the original focus of data management on database design and database operation still continues to be the large component of what we teach the undergraduates around this. And yet data management has continued to expand over the years. During the time that I was heavily involved with the Defense Department, we were using it for requirements analysis and modeling the enterprise data administration phase, if you will, came along. Again, these are not well defined, but you can see a clear pattern of expanding operation. And yet in spite of that, we still end up with confusion. I T likes to think that business is data problem. The general role if they can connect to the server than my job is done is not untrue about a lot of the way this works. After all, who would be able to connect us. On the other hand, I T excuse me business thinks that it is managing the data directly, who also be taking care of it other than somebody whose title was chief information officer. We can get some time when we can get together in person and I'll tell you the story of CIOs who aren't on this. The point is that data for too long has fallen into an enormous gap between the business and it. And this has led to a whole host of challenges what we need to do as data professionals is to reestablish the partnership between business and it by facilitating it. And the way we can facilitate it is we provide them the language. That is the value. What we call the data, the metadata that we describe is the value that we provide the two of these organizations so that they can communicate better overall. But if we don't fix this, if business decision makers continue to not be data knowledgeable and technical decision makers continue to not be data knowledgeable. We cannot be able to stop the too many bad data decisions that keep occurring in our organizations respectively. These bad decisions about data lead to poor treatment of organizational assets and poor data quality, which lead to poor organizational outcomes. Unfortunately, something else usually gets blamed other than the data. But the real challenge with all this is that we are stuck in a repeating cycle. And unfortunately, it reads like the back of the shampoo bottles, lather, rinse and repeat. How does one break out of the cycle? But it turns out that for most organizations, they 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. These are really pretty important questions that data management attempts to answer to the extent that it is relevant for what is going on with respect to the organizational interoperability challenges. Look at that a little bit more closely. One of my favorite Deming's quotes is quality data or products do not happen accidentally. They actually cannot happen accidentally. The more complex our society and our technology gets, the less likely it is that things will happen to work together. But what we can observe is that data management actually defines what a workgroup is. Data management, we say, works pretty well at the workgroup level. A workgroup is defined by the ability to exchange data privately speaking within their characteristics. On the other hand, without organization wide guidance, what are the chances that all the workgroups are going to be pulling towards the same objectives, and particularly with respect to the data that they have. So consider the time spent attempting to support what have been up to this point in most organizations in formal practices, as opposed to sitting down with them and making formal the process. The data interactions or lack of interactions become sand, chiefing the inside of the machine, preventing smooth operation and exchange, and really facing your organization with death by a thousand cuts that have been difficult to account for unless you got a pretty good idea of what sort of things to look for. We'll talk about that in another webinar for the monetization topics on that. So the key is with the organizations and the individuals lacking both the knowledge and skills around data, formally done. The data management is required to provide the how and the data strategy provides the why. And in our case, we're going to talk specifically about priorities. So let's talk about a quick summary of the data properties that we've talked about so far. First of all, there are generally low data literacy, even among data specialists, they know there's specialist part think of it somebody specializes in kitchen stuff, but has no idea what the hallway does. There's lots of data that exists but most of it was created very recently and the good stuff while it's uniquely valuable. Most of what exists is not really very valuable. Organizations have not cared well for their data in the past. There are two worlds and I had a wonderful exchange with a colleague who was writing a forward for one of my books, where he said specifically I don't know why you have to tell people to do this it just seems like it's the right thing to do. And of course it is, but gosh, if we could all get there we wouldn't be having these webinar discussions right. So there are what I call second world data challenges that exist out there. These second world data challenges are kind of important. We'll talk about a couple of them here. First of all, most organizations if they haven't been doing this, and I estimate it's about 90 to 10%. So 90% of the organizations out there need first before they can start to move forward to get back to zero. And that involves undoing existing stuff, skewering people sacred cows moving their cheese requires new skills. And if you're at zero, you need to start from scratch, which means you typically are going to require some sort of annual proof of value. And right now you need to get good at both because almost all data challenges involve interoperability and there's very little guidance at optimizing data management practices around that. And there's very little guidance on how to get back to zero. So, let's move on a little bit further here. And if you look at data management component within their data management when you go to Wikipedia, gives you a bunch of words and words are good and it gives a note saying it's a broad definition and doesn't really talk about the technical details of it, which is important data management generally tries to stay up what we call above the technology line, even our own dim buck in Dama calls it the development execution of architecture policies practices policies that properly manage the full day life cycle needs of an enterprise. And again, wonderful. I think we all aspire to this and I say about 10% of organizations really do make progress towards that on an enterprise wide basis. So what's left over then well, first of all, there's a general misunderstanding that if we data people could just label everything, we would be happy and then we would shut up and let the world go on. It is a valid stereotype in the sense that too many of us insisted on being pedantic in the past and not really being value focused. So many people perceive us as modelers and we just have to understand the relationships between all the things we've labeled on the left hand side of the diagram, and that would be great and this is a Microsoft. For some reason advertisement of how they thought about data management in their day. Again, clearly an old thing but I'm not sure what point they're trying to make here. I do sort of wonder that they at least found it was a good area to make fun of people in. So let's go back. I show briefly on the previous screen up there a couple of times. This icon here it is in big form this is the dim buck. We call it the data management body of knowledge after the Timbock which is the project management Institute body of knowledge. I'm sorry it seems like a good idea at the time if you have a better idea for it we'd love to hear it. Anyway, the dim buck as you can see consists of the same words on the previous page but this is a friendlier way to present the information. I'm going to actually flip it back to last year's the last version of this because I'm going to use these slides as we go forward. But the only difference between this and that aside from some really good writing and editing is that we added a new section here and I've outlined it for you. Look what it's called interoperability. So let's go data management is typically focused in on an area if we go even smaller than data management software engineering might be focused in in a particular area as a program level and an underutilized data modeling effort might also look at the data model relevant to that program. The data management effort is going to try to take a broader view. And what we'll say here is that the brown database that is showing controls and this is where you share data among the three sets of programs A, B and C. So data management effort would be at least that broad in terms of looking about it. ERPs and commercial off the shelf software and of course all cloud services are similarly marketed as being integrated in the same fashion. Ask questions before you go and buy that. So the better utilized modeling effort is to store the data structures once in the brown area and reuse them three times across the three programs A, B and C. And of course this works fine as long as everybody knows that that's what the scope is, but if they don't realize that the scope should also include the green and orange databases. Then you really end up with a significant challenge around that because if you don't have the ability to manage all of that individually, it means it has to be managed at a more granular level, which takes long costs more delivers less and presents more risk to the organizations. And if you try to manage it at the global level, in fact, the better way to represent that is to look at it here as broader than either software architecture or database architecture. The analysis is on the system wide use of it. And more importantly, focus your problems, the things you need to fix in your organization on the interchange the interface problems that are getting in the way of achievement of strategic goals. We'll move into that section just a bit, but hopefully you see how data management heads up, because it's quite important. If we don't look at it from an organization for a wide business and understand this. Getting both the current and future needs making the data efficient effective, we won't be able to leverage things and notice that leverage is a holistic effort that requires process people and technologies. And of course, the more you reduce the rock, the greater the leverage that you have in your organizations. So one final component understanding all of this. There's the definition I read that to you on the previous slide. People when they look at this, look at it and understand that they're seeing parts of data management, but not the whole picture and they don't understand that they're not seeing the whole picture. It's just like the blind people in the elephant. This one a fan, this one a snake, this one a tree, this one a rope and this one a wall, and of course all correct, but nobody has the full picture on it. I'm going to try to walk through that briefly with you here and see what you think data management we've always said is concerned with data, which run between its sources and its use and that's a good big definition. We need to get a little more descriptive and just starting out here with data science which is where most people have started in the past, because thank goodness they're actually talking about data which is a good thing. Data science looks at it, but that's only part. If you compare to me if you pair a data science with a data engineer that can cover the activities of collection evaluation preparation evolution access and storage. The data scientist will be more productive in the long running you'll see all sorts of blog posts for people discover this but in addition to that. There's a whole series of things that we do for data exploitation includes delivery presentation and storytelling, and this is what it means to take data from sources and get it to uses. However, remember earlier I said the best data is reused, not used and reuse is entirely different set of skills than most organizations currently have. Our specialized skills and all of them are covered by a governance ethical use framework in there to make sure that we have the ability to govern these tremendously important assets. And when I say they're important assets importance of data can be described thusly bad data. Plus anything awesome is still bad results or more succinctly garbage in and then garbage out. Yes. If you have garbage data, it almost doesn't matter whether the model is perfect or imperfect because you're still going to get garbage results based on the garbage input. And that is also true if you change that perfect model to a data warehouse to a machine learning algorithm to any form of business intelligence blockchain artificial intelligence master data management data governance analytics technology of any capability. If it uses garbage input it will achieve garbage output. If we don't understand and replace that garbage data with quality data will never have the opportunity to reduce duplicative data flows that we've already talked about. But in addition to that of course get what we're always trying to get to good results on the other end. I like to call them quality in quality out we call them whatever you want. But here's an objective statement I have not seen good results beyond the government ones that I showed you earlier in this presentation. They describe where data management is but we did a study between 7 and 12, which was the era of big data, if you will, and found that the results again were statistically unchanged in there and this does represent the state of the practice when we aggregate it to the large levels. So, they said we've got these levels that don't quite work all the way. Let's move them for just a minute and look at again the second world data challenges. It is consumed with interoperability almost everything we get is because something doesn't get from place A to place B or get transformed in the way it should. We tend to assume that all data sets are perfect just as they were in class when we showed them in the first place, and we have not been teaching the skills that are required to undo the mess that we inherited. Again, let's move from data management on to the third section here, data strategy. I'm going to start with the second world challenges up front here because I find this a little bit easier to present the materials this way. First of all, there is way too much focus on the strategy itself on the document. In fact, many people ask me to read their data strategies and I'm always happy to do so. But usually I can tell a couple things when they tell me it's a document, the links and what size font and doesn't have any pictures. Those are usually good additions to make sure that your data strategy works. There's not enough focus on the processes around implementing data strategically and data capabilities are really what you're implementing data by itself only enables business value does not provide business value. And I'll show you how to tie all this together with something that we call the theory of constraints cycle and those scope. That tells you how big a chunk you're taking for this cycle to do this amount of practicing that would make sense in just a bit. So let's dive in when I've talked to organizations about strategies. The top three that are mentioned are first of all science and big data and analytics and unfortunately they are not well defined and consequently not certainly strategies that occur in there. In addition, the next top levels that I get are strictly technologies, FAP, Microsoft, Google, Amazon, you know, we'll fix everything. But again, it's not. And let me let me draw the not line even more clearly. Most organizations practice by saying organizational strategy, IT strategy supports organizational strategy and data strategy supports IT strategy. The problem with that is that data strategy is implemented on a project by project basis without the governance of a continuous ongoing project structure. Consequently, it cannot deliver the results that are needed at the project level. It can only be delivered through a programmatic level data strategy has to exist in a completely different fashion. This is incorrect. If I could do a Morgan Freeman imitation, I would say this is wrong. Of course, she says on the other side, you know, as you write, so strategy wise, IT strategy, yes, important, but it should exist parallel to data strategy and quite frankly, many things in the data strategy determine IT requirements as opposed to the other way around. Let's look at strategy in particular strategy as a word that wasn't really used a lot outside of the military until about the year 1950. Then the business tax got a hold of it and went, wow, this is really cool. We can use that and sell out the business tax. I'm being facetious, of course, but nevertheless, there is a correlation there. My favorite definition of strategy is a pattern in a stream of decisions. It is important when you think about strategy to understand that you're trying to get the entire organization to move in the same direction. My livelihood comes from Virginia Commonwealth University. I am part of an organization. There is more than 50,000 people. If they implement even a 10 page strategy, it is a long time before all 50,000 people understand that strategy at the same level. Strategy has to come from a very simple place and a pattern in a stream of decisions. I'll show you over these next three examples are very, very key to making sure that people actually follow strategy. The same is true for data strategy. I'm going to show you two simple examples and a very complex example. First simple example here is Walmart's former business strategy. Every day low price. Pretty easy. Most of you didn't know that you knew that, but they have taken that slogan and inculcated in every associates level. In everybody who does business with Walmart, and most people who come in contact with Walmart, whether it's customers or some other types of interactions with them. It is a very simple strategy. It takes a long time to make sure everybody knows it, but guess what? You know it and it worked. Let's look at the second version of strategy. Wayne Gretzky's definition of strategy. If you don't know Wayne Gretzky, he's the Canadian soccer great many, many awards and things straight from his Wikipedia page. His definition of strategy was that he became the most scoring person in soccer league by skating to where he thinks the puck was going to be. After all, if you're chasing a large piece of plastic that is moving faster than you on the ice, you will forever play catch up. That is, not only just inappropriate, but also inconceivable as far as being a good idea. So with this two simple strategies, let's look now at a complex strategy. The strategy in this case is how do I keep competition when their forces are bigger than mine. The answer, of course, is by dividing and conquering, remembering our pattern in the stream of decisions. So let's spend a minute here. What you're looking at is a map of the battlefield that existed at the Battle of Waterloo. There were two lines of supplies. Napoleon in blue in the lower half of your screen is about to attack the red, which is the British in this case. And they are supplied out of a stand, which is on the French coast. And the Russians, right, the two combined forces are bigger than Napoleon's impressions are supplied out of leash. You can see where these is on the map here and Napoleon's strategy was that he understood that when you're hitting the face you're more likely to run towards your food, then away from your food. So he instructed his troops to first divide the two by hitting them strong in the middle. I'll show it a couple more times. No, your screen is not stuck. Hit them exactly right. If they move, they are more likely the British to move towards a stand and the Russians to move towards lead, providing a separation of the two forces. Then conquer, then everybody in his troop needs to remember we all turn to the right and turn on the Prussians and then turn to the left and get the British. The unfortunate result of this was that the strategy didn't work, but it is still taught as a brilliant example of strategy. I want you to just consider yourself as a soldier in the French army. And you're told, first of all, hit them exactly here, exactly where exactly here. That information better be pretty precise. Second of all, everybody turn to the right because if half of you turn to the right and half of you turn to the left, get the British instead of getting the Prussians, we will all be dead. Somewhat like that actually did happen. Long story short, a strategy that winds up on the shelf is not useful. The key is you have to have it at your disposal. I move forward. I hit them exactly in this position and we turn to the right. By the way, they're executing that strategy with live ammunition going over them. Yes, the reason you need to keep strategy in mind as a stream of decisions. Now, let's look at a couple of quick prerequisites that we need to look at in order to be able to do data strategy. Well, and I do that by showing you where I live in Montpelio, Virginia. These are photographs of the barn that I built. What's called horse husband if you don't know what that is catch me offline. But the nice part about all this was that these pictures were taken to document the existence of an event and the answer was, we borrowed the money to build the barn and that gave me exactly this much money to start with. It wouldn't let me go any further until I showed them a foundation certificate. This foundation passed its certification. These are part of the documentation that the county inspector took when he came out to look at this and see if it was ready to build more things on. If I build a good barn on top of a poor quality foundation, the bank understands explicitly that I will save the horses before I pay the bank back and consequently have major, major challenges around that. So the bank encourages me through this process of building only on top of good foundations and a good barn will be built on top of a good foundation. My point in telling you this story is that there is no IT equivalent. We do not understand the data foundations of our projects before we get them started and make sure that they work. Second important foundational piece of this has to do with our friend Maslow who I've already mentioned once Maslow was a psychologist back in the 50s. And if we were at food, sheltering or clothing needs, we would never be safe. And if we are never safe, we would never be part of something that is bigger than ourselves. If we're never part of something that's bigger than ourselves, we never understand ourselves with respect to how we are our others and that never allows us to achieve what we call self actualization. I say this to you because data is an awful lot like this. There are things in this golden triangle that are largely technology driven that have very, very little to do with the foundational practices that are required because these technology things that things that you read about and flash in the papers are just that they are what we call the hype cycle and the foundational practices consist of these five practices. Quality, strategy, platform, architecture, that's one word, and then operations on the other side of it. I'm going to do a magic transformation here in a minute here but these are more not technologies but capabilities you have to have people that understand what they're doing in order to make these work. If you don't, the things on the top will, in this case, take longer, cost more, deliver less, and present greater risk. In fact, the most surprising thing about the big data technologies movement has been how unsuccessful it has been, has been only as successful as all of the other IT initiatives taken during the same time. That certainly does not speak to the promise with which it was sold on this. Now, there's our wonderful transformation here. This is something else from my colleague Melanie Mecca, the CMMI, the author of the DMM, the data maturity model here. And the reason we use this is to help people to understand the interdependent nature of these five components. The first one is to manage our data coherently. We want all of those work groups to be pulling in the same direction. If they are not, then what are the likelihood that they are all happening to be pulling in the same direction? It's not. It doesn't work accidentally. You need to manage the assets with a professional set of data governance. We've had data governance long enough now that we can talk about professionality within there. We can talk about doing it with the right set of operations, the right set of quality controls, and the right set of technology stacks. All of these things are important. They also require supporting organizational processes. And when we look at the supporting organizational processes, they all have to be there in order to do this. But most importantly, all of these are held together with a weak link in the foundation. Excuse me, I'm going to start again. The weak link in the chain metaphor, if you will. The chain is only as strong as the weakest link. And organizations not understanding this do some terrible things. So let's write these things according to the data management measurement model. First, everybody gets one point for initial. If your process is managed, if you have some way of telling people how it's done, that gives you two points. If you've written it, the existence of documentation generally gets you three points. Four points if you measure anything that happens on the documentation that you have created out of the process that you have managed. And finally, if you use that information to change, evolve, make better the entire process, then you are all five points on this. Now we're going to make each of these threes. The data governance, the data quality, the data operations, the platform and architecture are all threes. Now, I've never met an organization that actually had all threes. Most organizations are somewhere less than this. You saw the numbers earlier on this. If, however, this organization does not have a data management strategy, it could literally invest $1 billion into data quality and not achieve the results it's looking for. Because the three, the one has to be made into a three before any of the threes can get better than three. Does that make sense? If not, please hit me at the questions. I'd love to talk about these things, but it makes sense to me. Let's now turn our attention to the theory of constraints. The theory of constraints is the idea from Elijah Golderath based on his book, The Goal. And the way the goal works is it tells the tale of Alex Wogan and Unico in a series of very, very interesting and illustrative paradigms that allow organizations to see organizational systems, all systems, as being limited by some goal. And the working process here that I'm showing you, the middle individual is holding up the process. The teacher, the writer, not doing anything. And one on the left is definitely problematic in this area. There's always one constraint. And theory of constraints uses a focusing process to identify that constraint and restructure the rest of the organization to address it. Again, the chain being no stronger than its weakest link in this instance here. So when we look at this, the theory of constraints actually does show up in this fashion. Identify the constraint, exploit that constraint, try to fix it, make it greater than all the rest, elevate it out of everybody else's components, and repeat the process until you've eliminated that constraint. If we transform that exact component into data, which we did in the data strategy book, it's the idea of finding, as a constraint, the way in which organizational data can most easily be unblocked to support organizational strategy. That's got to be the thing that you focus on. If you can find it and you exploit it, try to fix it rapidly without restructuring by correcting it operationally. If you fail to correct it operationally, improve the existing structures with a singular focus on that current objective, restructure to elevate the constraint, and repeat until the data support gets better. The key to this is to go through it as a process. And if you understand this process and focus on this process, you will get better at this process. And that is more important in data strategy than the actual document that you produce. I know that sounds completely heretical, but stick with me. Let's look at how we're going to pick the specifics of this. Oh, yes, that's right. We're in lava rinsing repeat territory. We didn't get that part. This is the key here we use about for the lighthouse project. There's three things that should be intersecting here. Things that further your organization strategy, profit or nonprofit, you all have a strategy, you all have something that data can do that will help it. And that intersects with data that is used by the business, looking for opportunities to just generally improve the way things work in there. And the idea to practice our needed data skills. We simply have been not practicing on both floor again because of lighthouse project because you focus this on one specific area, and you get better with that focus. Let's look at example. First example of this might be a data strategy that takes components from three of the DIMBOK wheels. These three wheels are data quality data governance and data warehousing and tries to do some working here. This organization starting from zero has done each of these things once what they've tried to do is create a data warehouse by doing some data quality and some data governance within there. They may have then identified the second version of this. Second version of this might look like this. Data warehousing still. We've now done that one twice. Metadata management which we perhaps neglected the first time through and data governance which we have also executed twice. So again the focus here of the second lighthouse project is on the intersection of these three components trying to get better at each of these things. Think of them as 90-day type of activities. We can't get too expensive data. Data does not evolve that quickly. Third version of this might also involve data warehousing. By the third time through we ought to be getting good at this. And data governance again we should be getting good at that as well. But now this is our first time through with reference to master data management and consequently we may be learning from that particular process as we go through it. So this piece gives us a different perspective on what's actually happening in our organizations. And when we look at that, it becomes something that people generally get a little different idea towards. So let's look at the putting this all together. We take organizational strategy, which is what the data should provide for organizational support. And the second aspect of what you're doing. 50% of capital investment by organizations today is in IT. Unfortunately, nobody knows what percentage of that is data that I have a sneaking suspicion is higher than most people think it is. Data asset support for organizational strategy must be the driving component there. Data management. People haven't seen that in the past as being connected in the way in which we think it necessarily should be. So this connection is a very, very big challenge and we saw that with data strategy strategy and focuses on what the data assets need to do to support the organizational strategies that transition function between organizational strategy and data management. We cannot fix all data management at once. And as I've said to you, most organizations are already in the second world problems. They're not at zero. They're at a minus something. Now I don't mean the minus on the DMM scale, but I mean that their data management has been less than fully funded or paid attention to expensive other things in the past. If that isn't corrected, you will still have death by a thousand cuts of organizations that experienced too many people trying to do their own thing with data management as opposed to what the right thing is. Again, I can tell you a story on this that we saw at one point with an organization whose chemical engineering staff had an enormous investment in 100 of them, and they were paid $100,000 each. We just rounded to make it easy. So that's a $10 million investment. And with that kind of an investment in there, these were PhDs in chemical engineering. They were supposed to create the next new products that were coming along for this chemical company. And the challenge that they ran into was enormous because without the ability to go in and understand data, they simply did what they thought was best. They were smart people, but they've never been trained in this technology or these capabilities. And consequently, the entire group went through enormous enormous challenges. Specifically, there were a ton of things around spreadsheets and spreadsheets are one of the hardest things to govern, but they do fall under data data management and the idea is we'd like to have fewer spreadsheets. I have worked with several organizations that have eliminated them entirely over the years. Very, very big challenges. So before our story here, these, these wonderful engineers who didn't know anything about data management were made more productive by the addition of data management in here, and it helped them to understand the data strategy that they were doing too. They understood the speed in some cases was optimized over other types of risks that where they were facing, depending on what the organization was doing. All of these things were not explicitly described earlier and consequently were much more difficult for the organization to understand. The feedback from that is of course how well is the data supporting the strategy. If the data is supporting well, then you'll typically get more of that. One of my favorite CIOs in the world is a person who who every year asks for a certain budget from the organization and clearly returns to them to X of the budget. And I keep asking her if I can invest money with her because I think it would get a similar kind of return. Again, how well is the data supporting the strategy if you can demonstrate this, it is critical. By the way, the organization that I was describing earlier there the chemical engineering organization, their own management decreed that they were $25 million a year more productive. As a result of that being $25 million more productive on a $10 million annual investment is a significant achievement. So my hats off to those guys. But again, you can see the links here though organizational strategy is only connected to data management typically through a data strategy and consequently, we need to make it explicit rather than implicit in order to do this. From data management is an interaction with it projects and each of the it projects are going to have some components of data after all what is the purpose of software but deliver data from place A to place B. Remember data means videos and images and all the rest of this in today's environment. And the question is how well does it support the strategy and you can see why these two things should be separated because they do manage different aspects of the organization strategy. We could have some feedback loops to the whole process and get them all on track. I quite frankly wouldn't show this picture to most everybody in the organization because it's a bit of a challenge to understand all of this. I would just draw the link between organizational strategy data strategy and data management to help people really understand what's there. You keep the bigger picture in mind, but not so much for what they're looking at. So I've got a kind of a long finish on this. So we're going to just sort of review where we've gotten to up to this point. Again, the key for all of this is we've moved our schools from the strategy now to sort of take away the better in there but we started out just an hour ago. So I'm going to go back. We're going to start it up. Oh boy, I am going to hang on. There we go. Sorry. We started out with some important properties of data and the key is data is as an organizational asset but under resourced all the way around with people whose capabilities can help apply it to the business and even who owns the function of data is still in dispute in 2020 and that's a very challenging situation for all of us. We've gotten the idea that data management is the idea of between where we get the data and where we use the data, something has to occur that adds value to the data so that we know we've got the right data at the right time for the right decision, whatever the constructs are that you're using in there. And consequently, the most organizations exist. It's working. Big banks are making payments and insurance companies are delivering right the world is running outside of the virus of course, and then, given all of that, why do we need to make it better and the answer is, you see things that tell you that 20 to 40% of it costs are spent, and I don't know a single organization that wouldn't like to save 20 to 40% of their IT costs on this. So again, if that sounds interesting, give us a shout all the way around that the key to this is to say we can't fix all of it at once and no importantly we can't fix we've got to get to zero before we can start to add classes on this. So how do we make up for that deficit and the key is the theory of constraints cycle, using an applied data strategy repeatedly to this will help organizations to get there. Key to this is coordination everybody's got to work in concert, or else it won't work the way it should. So let's talk about some takeaways here that we'll get to the top of the hour where we'll take your questions. I didn't mention before, but I did mention my wife before and she's a accounting professional and one of the things she likes to emphasize is that we in the data world have not had the 8000 years that it takes to formalize practices come up with the generally accepted accounting principles that they have in the accounting world. The gap is an important component. When an organization has an oopsie in the newspaper, and they're discovered that they don't have they don't follow generally accepted accounting principles. The first question everybody asks is what are they hiding as a presumption that they're not doing the right kind of thing. So, because this is new it's not acceptable for us to have it as an excuse but we can recognize that the profession. Maybe has 250 years if we give it a lovelace as our founding. Second, is that your data is likely a mess. And it does require some professional professional administrations to make up for the past neglect. One of the biggest questions that we get is, why is this hard for me it's not what I was taught to do the answer is yes you're right. It wasn't what you were taught. Not at a bunch of times it can be very difficult and make mistakes. Experience is what we're trying to do in our various communities that we have data diversity and the international society, the chief data officers is. Your organizational knowledge workers likely did not know how to use or improve data effectively. You know, it's kind of awkward to say it but if you have choices in knowledge worker employees coming up with many unemployed unfortunately. This is a good screening capability we've got a chapter in the new book the new data literacy book that hope will be out later this summer. We're focusing specifically on what knowledge worker capabilities should be. And if you use those as part of the screening process. We believe that your organization will become more data literate quicker. Your folks don't know currently how to use it or improve it effectively. And the problem is such that we just haven't thought literally anybody anything for 30 years except how to build a new database. We just didn't need a new program. First thing is that it's got to be a business program business program is required, because it has not done well with this in the past. It doesn't mean that it is bad, but it means that it wasn't educated and didn't make it a priority. And consequently, we have 10% of organizations that do this well within it and 90% that are struggling. Another aspect of it is that it has to be a program by program. I mean something that lasts longer than budget cycle that has its own funding requirements that doesn't have to be put on the chopping block each and every year. Your data program needs to coexist with your HR program. So the next time they ask you when will you be done, turn around and ask them. When are we going to be done with HR? Have we hired the last person? Have we brought the last piece of data into our organization? Are we never going to need it again? Data program is an ongoing concern for ongoing concerns. Data strategy, data management are the major components and they must work in concert. Because if we don't, if we just improve organizational data, that won't help. If we just improve the way people use the data, make them more data literate, that won't help either. We've got to have both better data and better people literacy. Because only then can we show people how to better use data to support strategy. If we don't do it in this fashion, we will end up with failures, disappointments. I've seen a lot of people posting recently where they say, are we ever going to have successes? Yes, there are tremendous successes that are out there. I can't tell you the number of panels I've been asked to be on over the past five years where people say, can you put a price on data quality? Yes, very, very simply. Different, different webinar, but it's still part of the value proposition for all of this. So again, the components here are, we've got to have good data. We've got to have good people to use that data. Got to have people that understand how to use that data. If they don't understand how to use that data, they can't be helpful to us. I mean, when we have good data and good data literacy of our people, our knowledge workers in our organizations, can we improve how people use data better in support of strategy? One last point here. The only way we can accomplish this is using an iterative approach. Focusing on one aspect at a time. We can only do so much. We only have a small program. We only have limited resources, but let's find something and fix it. And the thing we're going to fix is the interoperability problem that the organization needs us to fix so that they can achieve their strategic goals. And when we get that one, we'll find the next biggest blockage. I've not found any organizations that have run out of things to do, but I've seen lots of organizations that can't get this idea that the data program in their organization has to exist kind of like an HR program, kind of like a fire program fire. It's an organization kind of thing, particularly volunteers where I live in rural Virginia. The volunteers, yes, they are in the fire station sometimes. Sometimes they're doing some other things like preventing fires and making sure battery programs and smoke detector checks and education programs in the school. There's a proactive and a reactive component to all of it. And that's why you want to get some people good at data in a data program fashion, as opposed to trying to do it for everybody which hasn't given us what we're trying to do up to this point. It is a very, very tough job to inherit a data organization. Many of you have done it many, many times. And those of you with many times with the experience, we urge you to share that experience because that is what these organizations are about. And you'll hear Paul describe this in just a minute or two when he talks about our community that we have out here. So I hope this has been super, super helpful. I'm going to finish just a minute early here and talk about our upcoming events. We've got lots and lots that are coming up on the webinar schedule all the way through the end of the year. Gosh, it seems like 2020 is passing quickly. I know I think a lot of us were meeting for 2019 to finish and we got 2020 instead. So, hang in there everybody. And let's turn it over and see if you guys have any questions for us. Thanks for listening. Excellent. Thank you, Peter, for the great presentation. Do you have any questions, please submit them in the Q&A box. Also, 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 slide. And yes, we are recording it likewise in the link to the recording of this session. So the first question we have here, Peter, we have, so there's one person who has a constraint and their constraint is that upper management refuses to address data management challenges in a strategic measurable way. Strategy is their weakest link. So any suggestions? Again, hopefully the material here has been helpful. The key, again, where I see organizations having trouble. Can you imagine trying to wade through 10 pages with a disinterested manager of a data strategy? It's a very difficult proposition. People who don't understand data, it just seems to be a very binary function, haha joke. But our data, they either get it or they don't. I've had lots of organizations actually work on this and try and find out if there's a way you can identify a data person or not. I think enthusiasm is one of the chief characteristics about all this. And that's one of the reasons we have such fun on these events and with all of the rest of this. So if management isn't paying attention, the only thing that they're going to pay attention is their own self interest. I hate to be pedantic about it. But we as data managers have to translate our success into something that means something to them. You may be a charitable organization and you may be looking to increase the amount of service that you provide. You may be an organization supporting the military and you're going to increase the amount of support that you have. We as data people have to take that step to translate good things happening with the data. We have to translate the good things that happen with the data into good things that happen with the organization. If we can translate that we'll have a more effective area. The other interesting part about this is I've been working on it for quite a bit and I'm starting to get some focus around management. What does management do? Management makes decisions. So I've got another talk maybe, Paul, we can talk to Shannon about doing this sometime later in the program where we talk about the types of data decisions that are made by non-data people. And that is an interesting piece. We're going to hit a little bit of that in the book, as I mentioned before, the data literacy book that's coming out. So those will be two sources we can use to do that. Again, all of you are welcome to just pick up the phone and call me. You know, we're all kind of stuck at home these days and it's kind of fun to get a sense of what you guys are doing these days as well. So hopefully that's helpful. Paul, I'll turn back over to you for the next question. So we have someone else who's asking that they were recently asked to centralize strategic data management, Peter. So what kinds of organizational structures best support this kind of effort? And what talent does a team like that need? So I think the talent part's the easy way to answer that question. If you look at the dim box, again, I'll put that slide here. Give me just a second. The areas are pretty straightforward. I'll just pick one of the representations that we have here. So we can have a shared reference hall. Please, my friends in the data management community and get a straight version to the version one. I'm back to my slide. Okay, so you're looking now at the dim box. And what you might do is look at your organization and say, first of all, do I understand what each of these means if you don't. There's a wonderful book. If you don't want to get into the dim box, which is a little bit dense. Laura Sebastian Coleman has written a wonderful executive guide to this. What it's called, but her name is Laura Sebastian Coleman. And I'll make sure we put a link to the book and the thing we send out to you guys on this as well. But anyway, identify what these things are, right? And then do we need them? Are we doing this kind of function? So you can use sort of a heat map approach to this chart and say, you know, at least for the first couple of years, we're going to be doing a lot more data modeling or we've got a mess with a little bit back to our data warehousing or maybe we had a data security breach and we have to fix it, or maybe we're running out of data storage. By the way, just a quick side note, nobody's ever saved money by running your data into the cloud. It's a separate topic, but I'm not going to be fully on that one. We've not done well with metadata. I interestingly enough, I talked to a big bank where I knew they had a fantastic metadata operation. And I got a call from another friend who doesn't even know about it. But you need to call this person in the city and they will answer all your data questions, believe me. Anyway, thank you for the question. I hope that helps. If it doesn't, then reach out. And Peter, what's one example of data strategy that you would recommend? Well, you should beat me up because I didn't answer the first part of that individual's question on that. Let me go back and address that and then I'll come back to the second part of your question there. Suggesting a structure for your organization would be completely inappropriate because I don't know anything about your organization. Well, I may have seen a lot of organizations and done a lot of work for them. Your organization is what should dictate that and you're probably best suited to do that. That said, I'm sure there's lots and lots of organizations where you can go and take a look at some resources of data diversity to talk about specific types of things. Another aspect of this that is a slightly different twist on it, but one that most people are not aware of is that lots of us in the data community have put forward a series of patterns. So when you get into actually doing the data modeling, you don't need to start from scratch. There's lots of existing patterns that you can use. Again, another talk entirely, but something that will certainly be helpful for you. I'm sorry, Paul, and I didn't answer your other questions and I think it's the same question, which is what made me remind you something about the structure, right? It's a person would like to know what you would recommend as a strong example for data strategy. So, again, the services company is going to be different. I'm sorry, I can't recommend it. What I can do is say that your data strategy should be absolutely clear and understandable by the business and IT. And of course, it should be measurable as well. So those are some good parameters around it. And something else I didn't say this in the presentation, but you're generally reminding me of it with the question. Make sure that when you start talking to your organization about data strategy, that you number it. I did number them on the examples. I didn't describe that because I was going through because I wasn't sure I was going to have time to give you guys all the information that I plan to give share with you this afternoon. So let me get to this real quick. See, there is data strategy version one left hand corner, and they're going to focus on these pieces. Everybody got one, we did a data quality management exercise, we did a data governance, we did a data warehousing exercise. And there's version two. Now, the reason you number them is because as soon as you number them people expect there to be a second number. But if you have a data strategy, you look at it and I was pretend I suggested one to the individual that asked for it here. You know, I think you should go with saving costs, right? Completely inappropriate, likely. I mean, nothing about your organization or your industry. I may have done some work in it, but again, I don't know it at this point. But the idea here is that you've done this and people then expect there to be a version and the version will have a result and we can put to the result and say we achieve this. And again, remember key, this made this difference in the business. So, again, I'm sorry, I just like, you just got to give me more to work with that. And I'm not sure how much what Patrick Paul's got today on that. So back to you Paul, did I get that one? Thank you, Peter. And thank you. And I'll follow up if we get more information and context to that question. So the next question we just received is asking for a data science approach for the organization and don't understand the lynch pins of data management. So, which slides of yours, which you recommend we'll get back to the bosses. Sorry to laugh. And we do say this. So please take that as a friendly laugh. These slides are for you guys to use and key to this is that we don't have to reinvent the wheel, but better still you guys have actually given us lots and lots of improvements around the whole process. So the question asked to the way this process came about that I'm showing you on the screen right now. And that is that most people's exposure to data is because they've heard of this thing called data science. Well, a leftover from this residual. Remember data science fell off the hype cycle in 2015 in Gartner's area. Data science has done. I'm not saying it's not good, but it's another complication that we have to deal with. I watched so many organizations try to run their payroll on Hadoop. Anyway, data science, they've got to understand is just part of the bigger picture that's here. And again, even pictured this way, we're leaving out the really important parts, which is, we've got to reuse, and we've got to put governance around all of this. So this would certainly be a slide I would share with them and say, look, data science is this piece. And Peter's got stories. In fact, I think you can buy one of them. I think that yeah, the chemical stories in the advertising book. So you can get a copy of the book from your safari subscription and show your boss right there is the story. But this has really been the realization of data science and just do a troll through the blog. There's a couple really good ones out there where people are like, I've discovered that having a data engineer for a group of data scientists can make the whole group of data scientists, much more productive. They've got to understand, you know what the biggest complaints are about data scientists. They're more allied with their algorithm. They have no interest in learning the business, and they are not very productive, because it takes them about three years to become familiar enough with the business, and get the data in the shape that they can actually start to do work. That's not a measure that most people want to hear. Hopefully that's helpful. Excellent. And, Peter, we have a so one person wants to know they have nuances. What would you take into account for a data strategy in the case of a national statistical office whose businesses is data as opposed to the most organizations for which data is a means from proving whatever its business is. Wow. So a national statistical organization. I think the first thing I would do I can't tell from the question whether they're part of the federal government or not. They're not part of the federal government. If you're an NGO or something, the federal government passed a law recently, specifically addressing the way in which the statistical agencies interoperate. There's a number of parts to it. I won't try to give you the entire lecture here, but I certainly could send you a white paper and again Paul add that to my little notes here. So I'll give you guys all a copy of this paper. Let's talk about the main tenants of federal law. So this is now in effect for the federal government which occupies one third of the economy on a good year. The, the tenants are that all data in the federal government is open by default. So data management, all of a sudden got really important to the federal government. Data management, excuse me, data is now must report to a non it, non political, objectively qualified chief data officer. It is against the law and the federal government to make the CIO into the CDO. Now, not everybody's complied yet and we're still working on a lot of good, good movement in those areas. Third piece of this though is really interesting. There are several organizations in the federal government that are designated statistical agencies and apparently they had to ask permission every time they shared data. So the law says to them, you three agencies should make your data management operation operate as one because of the interoperability requirements that you all have within here. So it is explicitly addressed the law and my point of telling you this if you're not a federal government agency is that if it is good enough for the federal government and it is a good step forward. It ought to be good enough to guide us an industry here as well. So again, we're offering the same sheet of management. We're not offering to conflicting opinions right now. Now, one third of CDO's report to the CEO, one third of CDO's report to the CIO and one third of them report to some form of CXO and operating officer, a finance officer, a risk officer, something along those lines in there. It's a fun experiment, but gosh, somebody's paying a price somewhere for it and we're not really collecting data in an even-handed fashion. So we're not going to read about it in any of the academic papers real soon. I went a little off track, but hopefully that helps and applied for will be useful for you. And what is your recommendation for identifying non-existent data evolution activities? There's two parts to the question. There are non-productive data, so the rot that we're trying to do. When you hire a chief data officer and you look for the guidance that's out there from Gartner and everybody else, one of the things they'll tell you is that you need to do a data inventory. So again, nobody has ever completed a data inventory in the history of the world, but you can start to understand what data assets that you have and what you still need to uncover. So again, make a start towards that data inventory and part of the data inventory is what are the uses of that data. There's a wonderful analytical tool called a CRUD matrix, create, update, use, and delete. In there on the CRUD matrix is a really good way to tell what parts of your organization, what business processes are using, what data sets as input and output. Those flows of data will tell you a lot, a lot. When you understand the flows of data, you'll start to see the redundancies start to go immediately. Another way of approaching the same problem is to look at data profiling tools, where you'll have lots of data profiling tools that are working on your thing and your data profiling tool will suddenly come up to you and say, hey, this data over here looks an awful lot like that data over there. Are they the same or different? And again, wonderful ways of going through and doing that kind of architecture. Any type of reverse engineering activity will also yield similar kinds of results in there. That's great. Thank you, Peter. So the next question we just received is, where does data architecture fall in relationship between data strategy and data management? Really good question. Let me jump to the slide on that one. So I don't show it on the slide. I'm certainly not going to try and draw it for your freehand, but it's a good question. I'm sure the questioner can actually answer it as well. We've got a lot of people like to, I stumped the chump up here and I'll just play the chump. But anyway, here's our chart. What are they going to communicate back and forth here as they're talking about data strategy and data management? The piece that they have to use to communicate between them, they have to have a shared understanding of the organizational data architecture between them. And so really good question. I should have shown it on the chart there and I'll add it to the next one. A good example of doing this in real time, folks. Data architecture is that vocabulary that you speak. Again, you can imagine, increase the number of shirt order sales, right? Well, if you pay salespeople based on the number of shirt orders, a good salespeople will make every shirt order contain exactly one shirt. And if they could fractionalize it, they'd get even more. They'll respond to behavioral clues. And that's what you want to do here is to use the architecture components to drive the discussion around this. It'll tell you how big a project to take. It'll tell you what the interoperability challenges will tell you the types of skills that you need to have. I'm going to go back and add one more piece to the person that asked about the skills, too. One of the nice measures that you can use when you're checking out an organization to potentially go work with them or for them is to ask them, their HR department, what types of data categories do they have in there? The federal government only maintains two right now, a database architect and a data architect, which is really unfortunate because we're losing lots of data in there. We've tried to influence that process, but we have not succeeded just yet. So think about it. If we're not measuring it, we can't possibly manage it. Check out when you go to the HR department what they're looking at. What types of categories they have? They've got 12. You've probably got a pretty big, robust department. If they've got one, you may be a member of the founding team that's in there. Both are funding charges, either way. So anyway, yes, I will add a piece to this diagram right there. This is the data architecture is the vocabulary. I also get onto a rant about the nature of our definitions around this. And I've got another slide that I use where we go through and blow up a bunch of names. Because management business doesn't want plans and processes. They don't want diagrams. They want results. And what we've got to do is tell them that if we're not speaking the same language, the results take longer costs more deliver less and percent greater risk to the organization. And if we just all agreed to speak English, if that's what we're deciding, we're going to know. Great question. Thank you. Excellent. So Peter, in order to obtain commitment for all CXO in a government organization research center. How can we materialize the impact and benefits of data strategy when money is not the final goal increases in service achievement of mission. It's a very big challenge, but all organizations have some measurables that they keep track of. Maybe life saved. In some cases we did one for a bone marrow donation center where we were able to over a period of seven years, double the number of bone marrow transplants they were able to achieve. So good success stories like that are just wonderful. Now, I'm not claiming we did it all, but we were part of the team that was in there working with them. Again, making sure they had the right date architecture. By the way, they started out with a There's an old database that ran on one of those toaster Macintosh's long ways ago. Sorry, I get distracted Paul. We are very cold. And all this very useful information. So for this one person, their organization is moving away from RDBMS DBS into other data technologies. Do you see more widespread usage of new technologies increasing in the adoption of or heightened sense of urgency for a more mature data practice. So again, the new focus on big data and I say new focus because it's been the last 10 years. But have the ability to work on certain types of problems in parallel and achieve astounding breakthroughs in analysis more quickly by being able to transform the way in which the search goes, which is a Long search or query based search to a massive parallel search using, you know, hundreds of thousands of nodes. Yeah, we've been able to achieve some really significant advantages doing that. But at the same time, we're not going to run our payroll on it. And so the key is to understand from your perspective, which are the activities the capabilities that your organization needs. If it has a need to massively understand and analyze, you know, incredible complex pieces, I would suggest rather than buying into it to rent it for a couple months from Amazon. It's very inexpensive on a relative basis and stands up like that and try it and see how that works as an experiment. Of course, you know, you're probably doing classified stuff and none of this is possible. But again, not knowing the basics of it, you can try cloud stuff really quick. I've just never seen anybody move to cloud and save money. I've seen them move to cloud and achieve increasing success. And that gets back to where the question started out. If your mission isn't to earn money, thank goodness, actually a lot of corporations are saying their sole mission isn't only to earn money. There's a little bit of a break in the wall there. Then it's focused on service and mission and what are the things that you need to work on within your environment that will help you better achieve the success that you've already achieved and direction that you're trying to go. Hope that's helpful. Most discussions seem around data strategy focus on alignment with support of business strategy and treat it as similar to developing a functional strategy as opposed to data as the basis of competitive strategy. Your thoughts, Peter. That's a great question and I'm going to flip up to my slide here so we can talk about it. The reason I say that a data strategy is really superior in many ways and particularly in terms of precedence to I see it strategy is because the data is pervasive. One of the nice things about getting old is you can visit organizations, many times across a 40 year process. And you know what those organizations are still dealing with the same data elements that they were dealing with 40 years ago. Data evolves more slowly around that. So if we try and align data around functions, that means that we're going to and could potentially get to a very nice interaction where we understand what functions if you will are consuming what aspects of the data and then our strategy would be around either improving the quality of the data or improving the throughput. I didn't mention this in the other part of this but the question brings up a very good point. Sometimes your data strategy also involves repurposing some of your IT assets. We've been in many cases where we find out the only purpose for an entire class of machinery hardware was to take data that did this and make it look like that. I don't know what this and that are because I can't really articulate them to you, but I understand the context for it. We've been able to eliminate entire classes of processing through data analysis because what we say is what do you have and what do you need. If we can produce that need for you in a shorter pathway with less processing involves that represents savings for you that you can devote to other activities. Perfect question. Fantastic and Peter for one person they hold. I want to know who holds the business intelligence and business analytics program keys and the organization data management or something else, including data governance. Well, my definition for it would be absolutely included in there. If you think about it, if you separate them you run the risk of making improvements to your bi functionality, but don't get reflected back into data management. And so you, again, create these wonderful hidden data factories that do lots and lots of work that's really good but unnecessary. And that's what we'd like to do is eliminate unnecessary work all the way around it. How do you foresee recent increases in data privacy regulations changing data strategies and or data management practices. Practically speaking, organizations are going to find partners to work with that help them comply, because it's a big, big challenge and if we do it in the states, the way we're responding to the coven virus with 50 different processes. I would look forward to federal guidance in this area, but of course we'd like in some other areas and it hasn't been forthcoming there either, but we did get the people all past. So, I'm not entirely sanguine about the prospects. So data strategy strategy should be based on a business problem to solve data quality data delivery, etc. Would you would you agree Peter. Well, let's go back to the lighthouse metaphor. The idea, particularly as you're starting. If it if you can fix a couple of things simultaneously. That will be first of all easier to find reactions to the business value. But secondly, true value from your project as well. So again, I like the idea that there are things that further our organizational strategy whatever they might be there's a big university out there let's take a subset of those that also need to be improved that the business has already said you know if we could do that better it would achieve these business results or mission oriented results and ideally. If you can get the data skills that you need out of that as well and say wow we've you know we've never done a an exercise around be I for example. That would be a really good opportunity for us to pick one of those that works now again this is assuming all things are best. You may have very specific operational needs such as we need to be GDP compliant by Friday. Right. Well, I guess what's going to be your data strategy, keep your job. That's too quick, but hopefully it's helpful. Okay, and, and Peter your thoughts on new technologies like schema on red versus steam on right. You know preference preference of one over the other. No, no, it's not the way to think about these things it's not that one is better or worse it's that, depending on what you're attempting to do one may be more appropriate easier. Better suited than the other and your job as the engineer is to understand both the capabilities of the technologies but also the business things that you're doing, I work with a lot of nonprofit organizations and I had one that recently spent $20,000 on a lawyer to evaluate a $5,000 decision that was just an unfortunate, you know, wrong, wrong way, emphasis on that we should not have spent, certainly more than we were going to spend on the decision on the lawyer. Okay. So it looks like that was our last question Peter. I'll give folks on the line, you know, since we are approaching the end of the, the webinar today. If we have any final thoughts, any final questions they want to submit this would be the great opportunity to do so and as usual Peter your presentation was very informative. And is there, you know, with the remaining few minutes here anything else you'd like to contribute. Yeah, first of all, I thoroughly enjoy these and really enjoy the participation and the stump the chump nature certainly encourage anybody to reach out directly and talk about this but most importantly join us for the upcoming webinars we've got coming up on this and look forward to seeing everybody in a month. Excellent. Well thank you once again Peter for the great presentation and q amp a session. Folks, I'm afraid that's all we have for time for today. Just to remind everyone, we will be posting the recorded webinar and slides to data diversity net within two business days. And we will send out a follow up email with the links to the recording and slides. Thank you again, everyone for attending today's webinar, and we hope you all have a great day. Thank you. Thank you. Thank you everybody.