 Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager for Data Diversity. We'd like to thank you for joining today's Data Diversity Webinar, Data Strategy Best Practices, sponsored today by InfoJix. It is the latest installment in a monthly series called Data Ed Online with Dr. Peter Aiken, brought to you in partnership with Data Blueprint. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. If you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the bottom middle of your screen for that feature. For questions, you'll be collecting them by the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag Data Ed. To answer the most commonly asked questions, as always, we will send a follow-up email to all registrants within two business days containing links to the slides. And yes, we are recording and will likewise send a link to the recording of the session, as well as any additional information requested throughout. Now, let me turn it over to Matt for a brief word from InfoJix. Matt, hello and welcome. Hello. Thank you, Shannon. And thank you to everyone at Data University. My name is Matt Gushwan. And thank you all out there for joining us today. I'm a Data Strategy Consultant for InfoJix. I was part of the Data Clear Royance Group consultancy that was acquired by InfoJix in 2017. And I'm the co-lead of our launch data strategy service, which is a fast-paced assessment of an organization's data management capabilities. In two to four weeks, we identified bottlenecks that constrain the organization's ability to leverage data. And we produce a strategy to address those bottlenecks. In a few minutes I have here today to speak about data strategy best practices, there's one point I'd like to emphasize. Data strategy should not be driven by controls or governance or barriers around data. The goal should be in 2019, it needs to be to remove constraints in order to use data to create value for the business. With that goal in mind, it's vital to take an ROI, a return on investment perspective to data. That means thinking about each data project as an investment that has a risk and a rate of return. So the office of data should aim to create a diversified portfolio of data project investments to balance risk and return over the short, medium and long term. We have a full methodology for collecting, assessing and choosing those data projects and then rebalancing the portfolio. And I'm not going to have a chance to go into depth there, but needless to say there is more there. You might be thinking that unlike a financial investment portfolio, an investment in today's data project will not just make or lose money, but it should also increase the organization's data capabilities and make tomorrow's project easier. That's of course true. And so the portfolio must be rebalanced every quarter to take into account improved capabilities over time. The larger point though is that the goal can no longer be to manage risk and comply with regulations. These are necessary but not sufficient goals for a data strategy. Today's office of data and its chief data officer need to generate value. In other words, lower cost and bring in new revenue. One fundamental assumption that we make or actually more usually recommend is that an organization has a centralized office of data that is responsible for data throughout its life cycle. An organization needs a chief data officer or a similar role, a person to have responsibility for data in the entire enterprise, not just bits and pieces. And with that responsibility though of course comes the expectation that investments into data will make the organization more efficient and it will drive more revenue. For several of the organizations that we have engaged with, they're faced with a complex situation actually really for all of them. They spend a lot of money on data management but the allocation of funds has sprinkled in pockets here and there and departmental silos of IT may have the lion's share of funds for technology, but there tends not to be a single locus of data management. Instead there are some folks in accounting and finance, maybe a few guys in marketing, a gal over in operations who work with data and try to organize the data the best they can and help others to access that data or you know a lot of times to not access that data. A centralized office of data should take responsibility for data wherever it lives in the organization and but again you know the firms we deal with are typically not starting from scratch. They need to efficiently grow an office of data while running today's business. This means thinking about how to start up or jump start an organization that's unevenly developed or continues to build with a limited budget. Our portfolio approach is designed to help build an office of data wherever they are in that development. So our ideal client has the stomach for a five-year plan that shows results in the first year of course you need results early on you can't wait till year five and say okay the results are coming but then with bigger gains in years two and three and then moving toward a longer term transformation where the office of data becomes a money generator rather than unnecessary but unwanted drain on resources. The first year can focus on savings by reducing data or technology footprints. There are exciting new technologies like automated data discovery and redundancy discovery that can speed up this process significantly and after building some credibility the office of data can then sort of move on to more aggressive projects that might have a little more risk a little bit more ROI some more data science advanced analytics. Eventually the CDO needs to be able to demand the big transformational budget getting an office to scale to the size and ambition of the organization. This requires some strategic risk taking or shall I say guts it takes some guts and there's more to say about funding the office of data but I'm going to keep moving on to my last point of emphasis here is that the data strategy needs to make investments not just into technology but into people process and technology to develop an efficient data ecosystem. Peter will say more about the theory of constraints and how crucial it is to recognize the bottlenecks that are slowing down the entire system. People process and technology though are the traditional levers of course in an organization data connects them all though. People in processes manipulate or produce data through technology so investments into data of course will touch all three people will need to be trained or hired or retrained to accomplish new goals and processes and new processes will have to be developed to maximize efficiency and of course the technology should be should should enable all of these processes to happen. So there's much more to say about all of this and I'd be happy to address any questions during the Q&A at the end of today's session or you can contact me directly my email is there on the screen or check out our website at your local web browser. For now though I'll turn it over to Peter to learn more about data strategy best practices. Matt thank you so much and and let me give a quick introduction to Peter as you know he's our monthly regular series speaker. Peter is an internationally recognized data management thought leader many of you already know him and have seen him at conferences worldwide. He has more than 30 years of experience and has received many awards for his outstanding contributions to the profession. Peter is also the founding director of Data Blueprint. He has written dozens of articles and 11 books the most recent is your data strategy. Peter's experience is more than 500 data management practices in 20 countries and consistently named as the top data management expert. Some of the most important and largest organizations in the world have sought out his and Data Blueprint's expertise. Peter spent multi-year immersions with groups as diverse as the U.S. Department of Defense, Deutsche Bank, Nokia, Wells Fargo, the Commonwealth of Virginia and Walmart. And before I turn it over to Peter let me just say too Matt is going to be joining us in the Q&A portion of the webinar after Peter's presentation. So if you have questions for Matt, do submit them in the Q&A portion of the webinar there and we will be sure to ask him here shortly. And with that let me turn everything over to Peter to get his presentation started. Hello and welcome. Peter, are you there? More welcome everybody. We're going to be approaching the point somewhat soon. We're going to be able to see there's thousands of you online at least right at the moment. There's hundreds of you online and we're glad to have each and every one of you join us today. And Matt thanks for a quick great introduction there and as Chen said we are looking for you to join us at the end there so we can have some rousing discussion about these topics. And that's the first point that I want to make at this point is that when you look up the word best practice people say okay well it's a method or a technique that's been generally accepted as superior to alternatives. And I think that's what Matt was focusing on with his piece there as well. So best practice should produce results that are superior to those achieved by other means. And again I think Matt's point here Matt you can come back and address this at the end but was it it's important to get a sense for where the organization is on its current journey before you try to prescribe any particular course of action. My analogy on this one of course is that you shouldn't expect people who have very low driving experience to do well when you hand them the keys to the car and say go drive on the snow as their first experience to it. So there are ways of doing it and one of the things we've learned is it helps to drive on solid ground before you try to learn how to drive on ice. More importantly though we are at the infancy of this industry, this journey wherever everybody is headed. So there is no standard way of doing things. And so we can't look at the second piece of this because we have not yet developed those standards. That's what organizations like DataVersion like Daima International and others are all trying to get us there. So let's dive into the material here and take a look at this. The way I'm going to walk through this in the next 50 minutes or so is that a data strategy specifies how data assets are to be used to support an organizational strategy. There is no other purpose. Your data strategy is subordinate and supportive of the organizational strategy. Unfortunately many organizations are really confused as to what strategy is. So consequently they have trouble translating their version of strategy into a data strategy. And understanding how they work together is obviously crucial to that process. That'll be the first piece. Second chunk we'll look into that is to talk about the relationship between data strategy and data governance. There are really three folk eye here that we need to look at. One is to improve your organization's data. Two is to improve the way people use their data because even if you have the best data, if people don't know what to do with it, it's going to be a problem. And three, improving how people use that data to support your organizational strategy. Then there are a couple of prerequisites. Once again, if you're handing the kid the keys to the car, it makes sense to go over what the differences between the brake and the accelerator are. Well, if the organization isn't ready for this, then it's going to be very difficult to recommend the latest and greatest in terms of technologies. So we need to also compensate for a lack of data competencies that we have worldwide. And that will be the 12th book that I'm working on is a data literacy book on all this. And Matt alluded to eliminating constraints. I've got a couple of barriers that we take a look at just very briefly in this talk, but there are things that are in the way that will prevent your organization from actually doing this well. When we get to the data strategy phase of this, it's very close to the end if they lather, rinse, and repeat. Not a whole lot of focus on it. It's find the thing that is most blocking you, fix it, and move on to the next one. It's really critical to have a balanced approach to this. You can't, as Matt said, go out five years and promise that you'll have five years worth of good results and then we'll give them to you at the end of the fifth year. The world doesn't work that way and it's very impractical. It doesn't also allow you to do any corrections in that process. Finally, as Shannon always said, we get to the Q&A right about 50 minutes from now and we'll look forward to your questions and answers. Let's dive into the material and get started. And the first place to start is with a definition of strategy. You can look at this Google timeline here and see that until 1950, only the military really used the word strategy. But around 1950, a bunch of business authors grabbed it and said, this is really great stuff and if you go Google lots of definitions for strategy, you'll find lots of definitions. And that's actually a problem. So the one I adopt is one from Henry Menzberg that says, strategy is a pattern in a stream of decisions. And let's look very quickly at two very easy and then a third more complex strategy. The first one I'm going to tell you is Walmart's former business strategy. It is not complex. You all know this. Their strategy for a number of years was to provide everyday low price. That phrase was inculcated in every associate. Every person who did business with Walmart, every person who came in contact with Walmart, understood that the goal, the singular goal of that organization was to provide the lowest price for their customers. Similarly, if you were an associate, and I did spend three years out there, very, very interesting company to work with, if you screwed up and people make mistakes, that's one of the definitions of being human, Walmart did not punish you if your screw up was to provide better prices in the way of the customer. So it is a pattern in a stream of decisions. Makes sense. I like it. It works. Next one, some of you may or may not be familiar with Wayne Gretzky, but his definition of soccer is very straightforward. He doesn't chase the puck around in the ice. He skates to where he thinks the puck will be. I'm open, pass it to me, and I can score a goal. Well, that helped him immeasurably and there's a wonderful Wikipedia article that goes into it. A little bit of this I should mention as well. Steve Overman will kill me if I don't. This is obviously coming from a book called Enterprise Date Executive and Strategy or something like that. We'll get to it in a minute on here. So those were the two easy strategies, right? Skate to where you think the puck is going to be and every day low price. Let's look at a complex strategy. Question, how do I defeat the competition when their forces are bigger than mine? The answer is of course divide and conquer. Remember this is the pattern in the stream of decisions. We're going to take a little bit of a look at this one because it's kind of a famous example. Napoleon when he was facing in the blue two armies that were bigger than him, in this case the British army in red in the upper left almost directly above them and the Prussians in black to the right of them. Those combined forces were bigger than Napoleon so he had to figure a way of overcoming this particular group. A strategy for overcoming this particular deficiency. One of the things that everybody understood in those days was that an army marches on its stomach. So when the army needs to march it's very conscious of where its supply is from. The British were supplied from Ostend. I've circled it on the map for you there. And the Prussians were supplied out of Lees. Well what that meant was if there was an issue that caused them to fall backwards they were more likely to fall backwards towards their food. So comfort, shelter, maslow stuff, right? Then they were to run away from it. So Napoleon's part one strategy was first to divide the two larger armies. And you can see that symbolized here it's actually an old history book that I have that I'm pulled these little graphics out of. And again you can see if Napoleon said if I can hit them exactly right both of those armies the red and the black will move into two different directions they will split apart because their supplies are in two different places. So that's a brilliant piece of strategy on Napoleon's part. However just splitting the armies did not actually win the war. In order to win the war you had to have a two-part strategy in place. The second part of the strategy was after you split them apart first go after the Prussians and then go after the British. Now all of this is a little more complicated than everyday low price. In fact as a complex strategy we'll pretend Homer's one of the soldiers of course Homer is not. But again let's look at it first hit both armies in just the right spot and hit them really really hard. Then turn right and defeat the Prussians. And then turn left and defeat the British. Now I want you to imagine trying to follow these directions while somebody is shooting at you with real bullets. Yeah this stuff is not easy. Now luckily we don't tend in our organizations to have real bullets shooting at us but your data strategy then should be a very high level guidance available to the organization that focuses on specific data related activities and articulated goal achievements. Again Matt mentioned that in his little intro as well that provides specific guidance that is directional when faced with a stream of uncertainty about organizational data assets and their applications in towards business. And I say that because your data strategy should really be a fairly lightweight version of this. Nobody is going to read a 100 page data strategy and yet I see them over and over and over again. They are wonderful plans. They are good thought processes but the idea that you're going to make sure that everybody in the organization understands a 100 page data strategy is just laughable. I've used also a distilled version of data guidance in this and so governance in this case if we look at it from my perspective is managing data with guidance. Now data governance managing data with guidance okay one of the questions you might ask is do we want to manage our data without guidance? Of course the answer to that is no. So when you look at it strategy provides context for the guidance and while you'll see things where people are looking at you know data governance issues and saying well how should the data be used and in which business processes and which data is shared among the users and what processes and procedures allow for this change and who approves what and all the rest of these things. Those are not the real important questions. The most important question of all of those out there is in what order should I approach the above list of questions because we can't figure them out all at once and I can't tell you how many organizations I've worked with where they sit around in meetings with lots of smart people who are trying to plan out something that they just aren't really familiar with. It's not a good idea. It does not provide your organization with results and the idea that you will be able to predict what the future is going to look like you're in the wrong business if you're doing data and you can actually do those predictions. So let's look at these two in context. Governance is always going to be an important role. Always has been an important role in this and data strategy of course is a relatively new role. However what we've got now is a connection that we can make between the two of them and say what should the data assets do to support our strategy and how can we get people that are involved in governance roles to support that process. And the feedback that comes back says how well is that data strategy working within that? I have to point out too this is the one figure in the entire book. It's the most important figure in the entire book and it's absolutely wrong. So if you're watching this and you have a copy of the book this is the first figure in the book because of course it doesn't stop there. It instead remember I said organizational strategy is always superior. Data strategy is always subordinate to the organizational strategy. So you look at the organizational strategy and you say what can data do to help that and then you configure your data governance around that particular process. Now in Peter's world data governance actually is superior to IT projects. IT project should be subordinated to this particular process. And then of course we have some organizational results, operational stuff. We'll put in some feedback loops in here just to make sure it's all covered. I wouldn't actually go that far. I'll show you a simpler version of this diagram in just a minute. But most people again they say well okay great we got an organizational strategy and Peter says that the data strategy should be subordinate to the organizational strategy. So we'll do organizational strategy, IT strategy and data strategy. And unfortunately I say no this is also wrong. And the reason for that is because IT is largely a project oriented discipline and it does not have the same type of cadence, the same type of rhythm as this. The correct way to look at this is that your organizational strategy will spawn both an IT strategy and a data strategy from that. But the data strategy should actually because it is more stable and easier to manage in the long run should be superior to the IT strategy. Yes of course there's a coordination loop that goes back and forth between the two of these but it is kind of an issue. I will tell you that I have seen lots and lots of organizations come to me with strategies. Many most common ones in today's environment are big data, data science, analytics. All right well I'm sorry they're just words they're not actually strategies that are in there and then I've also seen a lot of people look in and say well our strategy is going to be AWS. Again AWS is a fine bit of technology but it is not a strategy. So hopefully you've got an idea of what is strategy, what is the data strategy, and how do they work together. Now let's talk about how we work them together in a governance context. Again there are three pieces to this. Improve your organization's data, improve the way people use their data, and improve how people use their data in support of strategy. Again let's dive in. Most organizations are pretty easy to identify various types of assets but most are still coming to grips with the fact that data is in fact an asset. And I'll tell you a dirty little secret about data that those of you that are in the profession actually know already. Data that is better organized increases in value. The reason for that is precisely because if your knowledge workers are trying to find something and they can't find it they are wasting their time. This is the biggest source of untapped productivity that we have out there. Poor data management practices are costing organizations time, money, and effort. And 80 percent of the data that is in your organization is ROT. You can say this makes me very popular when I walk into a brand new organization and they don't know me and I turn around and say 80 percent of your data is ROT. First of all they go we mean like ROT ROT and I say no no ROT is an acronym it means redundant, obsolete, or trivial but it's still a problem. It's in the way and the only argument I ever get on this point is it's not 80 percent but a number higher than 80 percent. My wife by the way corrected me she said you really should call it riot because it's redundant, incomplete, obsolete, or trivial but we won't get into that just at this point in time. See data assets are very different. Data is the most powerful yet underutilized poorly managed organizational asset. It's our only asset that we have that isn't depletable. It's the only asset that we have that doesn't degrade and it's indurable in nature which means we plan to invest more into it and treat it as an asset that if we invest more into it we will get more out of it. Now that gets us down to a level where data assets really do win when you compare them to other types of assets. People wear out, buildings degrade, blah blah blah all right. Now you will see a lot of people that are saying out there in fact if you google this phrase you'll see five million hits. Data is the new oil. I so don't want people to think about data as oil. It's the wrong way to think about it. So I ask that you just add sometimes somebody says blaze the new oil just go up there and write on the board and say it's the new soil. There's two things that are important about this analogy that data oil doesn't do. Oil is a production function and it's a commodity. That is not the way to think about data but data as soil has two things that are very very complementary. First one is you don't just randomly walk around your yard and throw seeds all over the place and hope the good things are going to happen. You prepare a careful plot of soil. The other part of it is you don't plant things on Monday and expect to eat them on Friday so there's a time dimension in there that is much kinder than oil refinery in that process. I don't care if you want to call it bacon it's whatever works in your organization in order to get it to go. But because of these unique properties data deserves its own strategy. It deserves attention on par with other organizational assets and it needs professional ministration to make up for the past neglect. Now I thought I was going to show you an easier version of this. I would never show this to management because it'll probably get them very confused. Here's the version I would show to management. What is it the data assets do to support strategy? Well strategy tells what those assets do and the governance group is responsible for implementing. What that means is that your data strategy needs to be expressed in specific tangible business goals because if we don't have things we can point to as data successes we have no ability to attribute the success of the operations to our improvements in data and that is very very important. Similarly the data strategy is working. The language of data governance should and continues to be metadata. If we don't have metadata as the language of data governance there is a disconnect between the people who are developing data governance guidance and the people who are actually trying to implement it out there. It's very important like I said I wouldn't show anybody that previous diagram but this one I think is a very reasonable one to share with people. When you look at data strategies as I said before there's sort of three reasons. You need to improve your organization's data. Four-fifths of it is ROT which means getting rid of a bunch of it will be very very helpful to you but data in general points to where valuable things are located. It has intrinsic value in and of itself and it has inherent combinatorial value as the bad guys keep discovering when they go in and hit Equifax and combine that with the Ashley Madison data breach and the OPM data breach representing the biggest threat to U.S. national security that we have ever experienced. Similarly your people have not been trained how to use data. I'm sorry that the college and university communities and I'm not talking about your data science community I'm talking about your average knowledge workers they don't have a clue they don't have to use data to manage change to manage change or to motivate change. It is not part of their educational system and that is a failure on the part of the U.S. educational system to put these into place. Only when we have better data and people like know how to use it should we then talk about using that data and the new knowledge that we have in there to create what we call a sustained competitive advantage for the organization. I'm going to show you an example with Rolls-Royce and I just want you to think about how long and what sorts of changes the organization had to make in order to accomplish this particular little vignette. So Rolls-Royce makes a jet engine. In general we don't worry about the fact that the planes are going to not get us where we want them to. It's the safest form of transportation we have ever devised. The old model for Rolls-Royce was to sell these things jet engines to airlines and we would put them on planes and then run around the world with them. Well the problem was Rolls-Royce couldn't have other conversations with the airlines precisely because they were a vendor. They were treated as every other vendor. We could buy GE engines or we could buy Rolls-Royce engines and we'll take whichever one works best. But the problem when you are in that kind of a scenario is that you're across the table from people instead of on the same side of the table. So Rolls-Royce developed a new model. Completely changed their business from a product oriented business to a service oriented business. And the service was now we're not going to sell you our jet engines. What we're instead going to do is to sell you hours of powered thrust. They had a catchy name for it. Power by the hour. Sounds great right? I need four hours of jet airplane thrust to take a flight from oh let's just say Atlanta to San Diego. Right? Well the problem with a power by the hour model is that you don't get any payment when there's a need for downtime. And so consequently there was no emphasis before when we were selling things to try and solve that downtime problem. Well I want to show you a little sort of clip here that allows you to see the advantage of this. And it's a lesson that was learned from NASCAR and in fact Formula One. So there you go. 67 seconds to change two tires. Now we're going to look at a more updated version of this. And of course in our new updated model they changed four tires in four seconds. Now my point in showing you this is that that conversation was not even possible because Rolls-Royce recognized that as long as they were seen to be a company that sold things to airlines there was very little opportunity for collaboration. But now they're working on a process called wing to wing to get the jet engines changed. Which means if you're next time sitting in Chicago or one of the many spoken hub points around the around the airline system and your plane engine goes bad they can probably replace it maybe not in four seconds but certainly faster than they used to do this. Now if I was at a live event here I would ask you guys all right when do you guys think they invented that particular piece? Most people say oh 90s must have been very cool right? But turns out that that technique was invented by Rolls-Royce in 1962. And in 2012 they celebrated their 50th anniversary of it. So the idea here is that by changing fundamentally the way in which data strategy worked within the organization they were able to improve the data to improve people's use of the data and come up with a new way for data to support their organizational strategy completely transforming this division of Rolls-Royce and not in any way that we would tie it to something that was inherently modern. 1962 remember we had relatively few computers in those days. So this was not a computerization type of play in order to do this. Again improve your organization's data, improve the way in which people use their data. It doesn't do any good to give them more better data if they don't know how to do it. And only when you have better data and better people capabilities back to again maps people process and technology triad there that we both like very much can you then use data to support your organizational strategy. Let's move on to the fourth section here now. This is a series of prerequisites that you will need to fix in order to do this the way you want to. Data strategy needs to be implemented in two phases. And when I say data strategy what I'm really talking about is using data strategically in your organization. It's not so much the thing itself as the direction that we're trying to do. And we need to move a couple of barriers first. So again remember this is what the data assets do to support the strategy. And I've already said phase two the last part of this talk is a lather, rinse, and repeat cycle. Once you get to that place it's kind of I don't want to say easy but it's not as hard as it seems to be for most organizations when they're first starting out on this. But let's get prerequisites out of the way. First of all there's prepare for dramatic change and determine how to do the work. Second of all there's recruit a qualified knowledgeable data executive. I don't personally like the term CDO even though a lot of people think I invented it. The problem with CDO is that you will end up with people in the organization who the first question they'll ask when you propose this is do we really need another chief around here. And that of course derails the conversation, sucks all the oxygen out of it, and people talk about things that are not really the focus in there. We do need to have, and I like to call them enterprise data executives but it's okay if you want to call it a chief data officer. The point is it's a leader of data in the organization. And finally there are some specific deadly sins that need to be eliminated. That's an entirely different topic. And Shannon if I remember we're going to do this one in December so you may have to wait a little while or by the book in order to come up with it. So let's take a look at each of these individually. Again change is very important for organizations. Now I've been running around for years saying things and again this is an attribution to me. I try not to make it quite as blunt as this. Peter says CIOs aren't. That's a kind of a true. That's kind of harsh too. See the I in CIO really stood stand for chief integration or chief information technology officer but they do not manage information as an asset in 9 out of 10 instances that I have measured and reported on in the literature. That means 9 out of 10 of your CIOs are doing other things in addition to making data the highest priority that they have. And that's perfectly reasonable. It's absolutely insane to think that somebody can do all of this stuff but now you're introducing a CIO and a CDO in the same organization. Oh my goodness. That could be a problem. And in fact when you do that there's a wonderful Gartner piece out there. I've got the note to it here. You can find it yourself if you need to but it says the Mario Farah. Good friend in there. When you do this it introduces confusion, uncertainty, fear, doubt, and uncertainty into the organization. Resentment again resistance CDOs need to rise up to this challenge and there's the name of the report. If you google that you will find a copy of Mario's piece out there on the web in order to do this. The challenge of course in all of this is that when we do this we are actually asking the organizations to rethink what they've been doing. For years and years they have had an organization who is the chief information officer and about 50% of the time when I walk into this situation the CIO says yep you're right. I've got plenty on my plate keeping track of the information technology that I have to manage. And I'm very happy to hand it off to a CDO and now it's your problem. Good luck kid. That's sort of the general approach for about 50% of them. The other 50% however say exactly the opposite. Wait a minute my title is Chief Information Officer. Why are you coming in here and telling me I need to do more with data? That's implying I am not doing a good job with my existing data. Well look around your organizations without any detriment to your CIO. I'm pretty sure most of you are not going to say your information, your data is in the shape that you'd like it to be in. And it could use some additional administration as I said earlier to help make it better. Even if it's just eliminating the rotten, leaving the better stuff left over it will make things measurably better. But in all cases when you have fewer items to focus on it's pretty easy to make them of a higher quality. There is a profession that handles this kind of major change. It's called change management and leadership development. And we need to make sure that we employ those professionals into that process because what we're really trying to do is change the way people do things. And the only way to do that proven over time is to make it harder to do the old thing than it is to do the new thing. Now in order to get change ready I use this model from Mary Lippert which is a really wonderful model. When I walk into an organization and I see anxiety I pretty much bet that there's a vision, incentive, resources and an action plan but that what they're missing are skills. Similarly when I see frustration I'm pretty sure I'm going to find vision, skills, incentive and an action plan but no resources. Yes that will lead to frustration. Of course you can use this diagram to figure out what's actually there but the point of the diagram is to show that just like putting a key into a tumbler lock only when you have the vision, skills, incentive, resources and an action plan do you actually achieve change in the data area. And it's not just about getting all those things lined up but recognizing the absolutely tremendous role that culture plays in there as well because culture is an incredible element in many organizations to doing more with data. I have a separate case study on that. It is available as a free download from the ACM. They allowed me to pay them enough money so you guys could go download it for free. And I'm just happy to report that it has approximately 10 times the number of downloads that other papers comparably get there and that's I think because you guys are finding this stuff interesting. So we don't do a webinar on this one but you are welcome to go out there and grab it. The links are live so you can take a picture of the QR code that's right there once here and send you the slides. Again, we need a knowledgeable staff in order to do this. We need knowledgeable leadership. And I'm going to show you a data strategy framework that I've used for a number of years. I actually caught this one on LinkedIn the other day and it was in Spanish. It's very gratifying to see somebody else take the time to translate your stuff into another language on this. But most organizations start out by coming up with some business needs and they say great and those business needs will be the things that we need to do to make data better about this. And I say that's wrong because it's leaving out the important component of where is your organization on its journey. We talked briefly about this earlier in the context of handing a Tesla Fob to a 16-year-old that had never driven before. Only when we have a good match of business needs and the organization's existing capability should we then come up with a strategic data imperative. The execution of that becomes another challenge. We'll come back to this diagram and you can see it's marked as part one. But let's just ask a question. What do we teach knowledge workers about data? Now my definition of a knowledge worker is somebody who works with data. And the answer to this of course is absolutely nothing. And yet they all deal with it daily. This is a problem and we need to work on this. But right now your organization is faced with a very problematic situation of people not knowing much about what data does for them and yet they have to use it as part of their jobs. It's even worse though if we go to IT. In general in IT you get one course. And that one course that says data is how to build a new database. Now if there's a skill we do not need anymore of on planet Earth it is how to build new databases. We are teaching the wrong stuff and we are teaching it wrong in college and universities. Two problems with this. One it's an opportunity cost where we could be teaching IT professionals a little bit more about data but we aren't. So they have to get into the workforce. They are hired by your organization. You all put your heads together for a while and somebody eventually says you know we probably ought to do more about data. But the more harmful effect is that IT professionals who then rise to leadership positions and realize that what they remember from school was that there was just one course in data and it wasn't how to build a new database. So they think well I don't need data people because I'm migrating databases. I'm not creating a new one or they think I don't need data people because I'm doing everything from a software package perspective. And I don't need any data people in there from my software perspective. No. Or I'm installing an ERP. Again we're not creating a new database and we don't need data management. We had a survey I think it was about 10 years ago where we asked ERP vendors and organizations that had installed ERP how much of that ERP they had consulted with their data people. And we had a good 30% that had never even talked to data people implementing an ERP. Unbelievable. Well again blame falls squarely on the college and university community. And what this has left us with is a situation where organizations have little idea what data they have they don't know where it is and they don't know what their knowledge workers are doing with it. And this leads us to something that I call the bad data decision spiral. The business decision makers and the technical decision makers are not data knowledgeable therefore they make bad data decisions which results in their data assets being treated poorly as well as being of poor quality. This leads to organizational outcomes. Again lather, rinse and repeat. If we don't change this cycle how can we expect things to work differently? So it's a huge, huge problem and we need to do better with this. Now I want you to imagine hiring panel in your organization says okay we listen to Peter we're going to go out and hire a chief data officer. Well how are they going to know what the chief data officer is qualified to do whether that individual can do or doesn't do the right types of things. If they don't know and they don't know that they don't know what are the chances that they're going to hire. So I've been to well over 50 CDO events in the past couple of years and I will tell you for a fact that half of the CDOs out there want to be CDOs but have no qualifications whatsoever. But it's hard to tell them from the others because they all make great speeches. This is one of the reasons that most CDOs are failing so badly. They start out they've got a great idea and they're going to do one thing that they know really, really well how to do and all of a sudden that thing doesn't provide the promise that they need to have. So the guidance at this point is to rent your first chief data officer your first enterprise data executive because when you rent them they can go through and make whatever changes are needed to the organization without beating up and losing organizational capacity. After they've made the hard changes then invite your second CDO in place to then make up for and start to make different corrections on the whole process. Now that's a little bit harsh. Those are your first CDOs unlikely to succeed and that has been in fact the pattern that we've been looking at. One of the other organizations I'm associated with and we'll probably have a presence at Enterprise Data World, our big conference coming up in March is the International Society of Chief Data Officers. If you're interested in joining that, jumping into some of these dialogues that we're talking about it's ISCDO, International Society, ChiefDataOfficers.org It's a page you can go out there and link to and sign up for it. We're also working on a LinkedIn group and some other things so we can get the community out there and do this. So I mentioned the last thing to get ready for all of this is the seven deadly data sins. They fall into some categories that are pretty easy to take a look at but a little harder to explain. So I'm going to take just a minute here and walk through them with you. First of all, there's the cultural and change management aspects. We did talk about that one for a little bit. There are a whole bunch of things in data that require strategic alignment sequencing some things before other things. For example most organizations make a very silly mistake which is easily avoidable but again not common wisdom. So they'll say I want to do more with my data and what they'll do is they'll take a look and say okay I'm going to go out and buy some technologies. Well technologies are good but remember they're only part of the people process and technologies triad that we talk about in order to make this stuff work. So they get some great analytical tools but the data sucks and then everybody blames the technologies because they don't understand garbage in garbage out. I would suggest that a better process is to actually use your data to save you some real dollars in the major piece. I could tell you for a fact that your organization is spending between 20 and 40% of its IT budget doing things because it doesn't understand these data sequences. And 20 to 40% of IT budgets can be considerable. For example Walmart spends $4 billion plus each year on information technology. 20 to 40% of that number is a large, large number. Matt also mentioned the five year plan and maybe we can talk about this at the end of the seminar but I've had lots of people that go through this as well and they say oh you know we'll be fine in five years. It's going to take us a while and it will take you a while to do this and to do it well. You've got to start, crawl, walk and run. But you can't say I'm going to do this in a long term. Let me just give you a very specific example on this. Let's pretend you've got five people in your data group and each of those people gets paid $100,000 so we're looking at half a million dollars a year. I do feel it's absolutely incumbent on those five individuals to as a group show the organization that they have provided at least a half a million dollars value each and every year that they are around. Many people disagree with me on that but I think it's a lot easier to keep your job and we all know that we're headed into a recession sometime in the next year or two and it's been that long and it's time for another one. We will have it and if people don't understand what you're doing then you tend to be the first group that gets laid off when we go through the inevitable reductions. My point here is simply to say that if you wait five years to deliver at a half a million dollars a year your delivery is two and a half million dollars. Somebody may come back and say well we invested two and a half million dollars and you guys saved us 300,000 that's good but I could have put that same 250,000 in a new product development and maybe come up with a number that instead of 300,000 it might have been three million dollars. So management is going to look at this thing from a return on investment perspective. Number four, very critical to make sure that your data program is aligned with your IT projects. If you don't know the difference between a program and a project it is important for you to learn that. Find a PMP on your staff and get them to help you with that process. You need to implement a robust program for sharing data. Now I'm using the word program there in the same sense as an HR program and that's what I'd like you to tie in your executive's mind. Oh I need a data program? Okay how long is it going to take and when you will be through with it? And the answer is we will no longer need our data program when we no longer need our HR program. Of course we need to make sure that the people who are leading these efforts have some qualifications. There are some CDO schools out there but most of the time I have not found busy executives willing to take time to go visit these schools and spend years of their life doing this. Finally there's a component of this called data centric thinking. And I'm not going to spend a lot of time on this just two minutes but I do want you to see that we are working on what it means to be data centric because if everybody says I want to be data centric and nobody has a good definition that's sort of a problem. So we've come up with four tenants. They are very similar as you might imagine to the Agile organization. Agile did a great job on doing this. We've got a website out there that's called thedatadoctrine.com. And the four tenants are data programs need to proceed software projects. Stable data structures need to proceed stable code. Shared data needs to proceed completed software and reusable data needs to proceed reusable code. Those are objective characteristics that your organization can demonstrate that it's doing and therefore say it is data centric instead of saying we've hired or bought XYZ and therefore we're ready to do this. So again it's a lack of organizational readiness. It's a failure to compensate for the lack of data competencies in the organization and failure to remove those barriers that will keep you from being able to do what you really want to do which is physically go through and look at project-based work guided by a program that will allow the organization to better achieve its data. So we're going to assume that you're right here in this cycle. Phase two, you've eliminated the prerequisites you've prepared for dramatic change. You've got a knowledgeable, qualified data exec whether it's a rent at one or one that you've grown yourself, that's fine. And you've eliminated the seven deadly sins. So then the next part of this is all built from something that some of you will find very familiar. It's the idea of theory of constraints. Identify the primary constraint that is keeping data from fully supporting strategy. Exploit organizational efforts to remove that constraint, subordinate everything else to this, alleviate the data constraint, and then repeat the above steps to go forward this. Now I mentioned this theory of constraints. Excuse me. There's the book. L.A. Hugh Golder a long, long time ago and it's been very, very useful. Obviously 30 years worth of anniversary around this. The theory of constraints simply says that within any system, there is something that is the most blocking you. Find it, fix it, and move on to the next one. The chain is no stronger than the weakest link. So find the weak link in the chain and fix it. Now that may involve a portion of something on the dembach wheel. We're not talking about the dembach wheel specifically here, but you may say, oh, I need to develop some master data management technologies or capabilities. Well, the idea is not to go out and spend seven figures buying a technology stack and then not understanding how to use it. Instead, let's start to manage some data in a master data management approach. Master data management has always been labeled as a strategy, not as a technology. But of course it's easier to sell those technologies. So our theory of constraint cycle goes identify the current constraints, the components of the system that are limiting the realization of our goals. Make quick improvements to that constraint using existing resources. We've got things that work. Let's try to fix them easily. If that does not work, subordinate everything else. It means you've got a structural problem and you now need to eliminate that particular constraint. If that doesn't eliminate the constraint, start over at the beginning. That's the generic version. Let's look at it specifically from a data perspective on this. So to improve your data, again, in the analysis of how your organizational data can best support strategy, this one thing is blocking it. Okay, we've identified it. Once again try to correct it operationally. It may be something that you can fix in a piece. I worked with one organization where they had a default admission code to an organization. And it was simply a matter of eliminating that default admission code and forcing people to pick something off of a list that got them better data because everybody understood that the default code would get you in. But the hospital director was eventually trying to tell everybody that they were doing knee surgery to an extent that they were not doing knee surgery because knee surgery was showing up on that individual's reports as being the most popular thing that the organization did. Well, of course once they discovered that they were able to correct that one operationally, but it may be a bit of a problem beyond that. So once again you subordinate all the constraints and find out what in our data process can we use to better provide information into this and repeat until the data better supports that particular strategy. That's what I mean by lather, rinse, and repeat. Again, if you actually followed the directions on your shampoo bottle, you would never get out of the shower. Now, aside from that being a good way to sell lots of shampoo, it's probably not a good way to do lots of data things. So again, get rid of everything else, set up an organization that will be able to go in and use this in the same way that firefighters, right? Firefighters don't spend a lot of their time doing other things. They do education around fire, they do battery replacement, they visit the schools, make people fire awareness, right? All of these things are good that we in the data industry are doing nothing around and we need to in order to do this. So I mentioned before we were looking at the data strategy framework part one I showed you again. Business needs doesn't do any good to come up with a solution if that solution doesn't match where the organization is on its current side. Only when you have a match between those organizational capabilities and the organization's business needs does that give you strategic data imperatives that you can then execute in the form of a roadmap. But even your roadmap needs to be balanced. This is the last point I'll make on the strategy piece. If you have business value on one side of it, then the organization sees very clearly that it's going to be pretty easy to say this is a really good idea. On the other end of it though, if you say wait five years and we'll have some cool new capabilities, you look to the organization like a science project and that will not survive the next recession. So very, very critical to make sure that you deliver some kind of return on that investment. Again Matt said his goal is within a year and I think that's a very reasonable target. Particularly since most organizations are leaving so much stuff around, it's just I wouldn't say easy to get it in a year, but it is absolutely doable in the vast majority of cases. Delivering bits of business value at the same time you are building new capabilities. Because if you don't build those capabilities, you might deliver the business value, but then they turn around and say that was great that you did that last year. What do we do next year? So we're getting back towards the top of the hour here. Again, just to summarize, a data strategy specifies how data assets are to be used to support organizational strategy. It's got to be a lightweight document. It cannot be, for example, something that is more difficult to read than the organizational strategy is. So strategy is a very simple set of guidance. A data strategy also then is a simple set of guidance. It is something that you need to make sure that you number. Your first data strategy will address the first problem. Your second will address the second problem. Critical, by the way, if you give them data strategy number one, they will automatically expect data strategy number two. But if you tell them this is the data strategy and then you fix it and move on to the next one, they're going to get confused as to is this the data strategy or was that the data strategy? All of these things are very problematic for organizations. So number your data strategies in order to do this and show how they work together. Show how your data strategy has implemented a process by which you are now helping to use data to implement your organization strategy. Of course, this also provides direction for governance. As I mentioned at the top, I've seen a lot of governance efforts that simply go off the rails. One of our biggest businesses here at Data Blueprint, and I'm pretty sure Matt does the same thing, is helping organizations get their governance back on track. The strategy should be focused specifically on helping your organization improve your organization's data, but it should also improve the way in which people use the data. Now let me just give you a very specific example on this. Walk into any office out there and ask the people to raise their hands if they know how to use Excel. Many of them will. Ask them then to keep their hands raised if they were taught at the same time that they learned Excel that they were also taught that there was a macro facility in Excel. And you'll see most of the hands go back down. So think about this for just a minute. People are doing good data work with Excel spreadsheets, right? But they don't know that there's an automatable process that can take much of the drudgery out of that? Oh my goodness. That's just the tip of the iceberg in terms of this. So if people don't have good data and they don't use it, how are they supposed to use data to support the organizational strategy? You need to get rid of the prerequisites in there. Again, lack of organizational prerequisites. They are not ready to go. There is a failure about data competencies. Blame squarely on the college and university. This is not something you should have to learn. It's a bit that you should have to be to be a contributing member of society in today's digital age on this. And again, eliminate those seven deadly data sins that we have out there. Phase two of this process then. Again, let's start iterating and let's get good at the process. The whole point of iteration is not that the first one is going to give you the big payoff. You should probably start with the first one being very, very quiet and silent. Do a couple of them and get better at it. Start to practice. We haven't had the 8,000 years that the accounting profession has had in order to get better at these processes in here. Once you do, however, you will get to the point where you have a lather, rinse, and repeat process where it will become second nature to your organization. They will understand that you will produce results. Everybody will be happy. Isn't that a nice scenario? Well, I leave it at that, but you do need to have a balanced approach. You've got to develop better internal capabilities and you have to develop better quality of data that's in the process. It can't be simply about one way or the other showing value without building capabilities. It can't be all about building capabilities without also showing value. So now we're at the last part of this which is the wonderful Q&A session that we're going to invite Matt back in on to do. Let me just, while we're getting ready to get him set up, tell you I've got a couple things coming up. First of all, our February webinar is data architecture versus data modeling. It was really popular last year, so we're going to do that one again. March we're going to do reference and master data and how to unlock business value with that. And then I mentioned Enterprise Data World. Before, on Sunday, we're going to be doing a session called How I Learn to Stop Worrying and Love My Data Warehouse. That sounds a little like Dr. Strange Love. That was intentional. And then on the Thursday of the event, we'll be doing something with my good friend Dave Eddy called the Data Management Brain Drain on this. And if those of you in New York City next week, there's actually a longer version of this webinar that I'll do for the DAMA chapter up there on Thursday next week. It is free for DAMA members. The DAMA New York members it's free and it's only $20 for non-members. So if you have nothing better to do next week, come on by. I put the link on that for that chart. And now we get to the Q&A part and we'll invite Matt to come back on and join us. Peter, thank you so much for this great presentation and just a reminder to everybody. I will send everyone a follow-up email by end of day Thursday for this webinar with links to the slides, links to the recording of the presentation and anything else requested. So it's just diving right in here to the question-video questions. It's been in the bottom right-hand corner of the Q&A section for us. So strategy. So is it so fundamentally yet so hard for businesses to understand? I think you addressed a lot of that, but it's a very simple question, but I think it's a very deep question. It is. It kind of goes to what we've seen in Apple's desire to things really well designed. So one of Apple's problems for years and years and years was how to get rid of the stupid, the one stupid button that they had on the iPhones. I don't mean it's a stupid button or iPhones are stupid, but it was just a design constraint to them. They had to have some place where everybody could go to do something. So that single point on the iPhone was there. And Steve Jobs to the end of his life worked on plans to get rid of that one button. It is hard work to design a great product. And that's why strategy is kind of hard. People say oh, it's easy. I just need a phrase, right? Well, no, you don't need just a phrase. You need the right phrase. And Matt, again, we're going to get you in here if you want to comment on this. Why is strategy hard for organizations? What do you see? Yeah, so one of the things that we've been noticing in the market is that strategy on some level is becoming somewhat homogenized. You can go to McKinsey, you can go to Deloitte, take your pick, and sorry to mention them by name, but you know where I'm getting at, the big firms. And they'll give you something that looks compelling and it has a lot of the same features. But then they go away and they send you a nice bill and then you're looking at, well, I could bring them back for this next stage, or I could just try to make sense of the strategy myself. And so they have to figure out where to put their budget money. So, you know, again, there's this compelling future, but how do you make the first step? Well, you know, I talked a little bit in my five minutes about this idea that we have sort of a tiered development. But when you're really at the first stage of it, what you have to do is you have to go around the business and see what business people are demanding. What's slowing them down? Where do they see the value? And if you can collect a bunch of those projects and find a few that you think you can accomplish today or with a modest investment, you can gain some credibility. You can gain some traction in the organization. So that's one of the things we really try to do is give them a buffet, if you will, a buffet of options that they can go ahead and get started without, again, making the huge investment that might be needed as you go or later on. I certainly agree with that. And again, the other part of it is what was it? Frank Perdue used to say it takes a tough man to make a tender chicken, right? So it's that kind of a process. Organizations that start out with 100 page data strategy, a very complex data strategy, the organizations, you're probably the only person in the entire organization who's going to be able to read and understand it. So while you may have done a good job on it, until you can distill that into a message that others understand, this pattern in a stream of decisions. And I will tell you, again, I spent three years with Walmart, but everybody that comes in contact with Walmart understands everyday low prices. If you don't, you're not successful in your interactions with Walmart. So it takes a lot of time to develop that particular process and come up with it. It's not just because it's short, it's because it's short and it's actually correct in there. I'm thinking of what, to latch on to what you're saying, it seems to me you mentioned, you talked a bit about change management, so that becomes very important. And then finding some internal branding mechanisms that resonate with people. So if you can get this distinct as Walmart and have that single vision, then you can build from that. But that's not a given in these organizations. And Walmart didn't start out there either. They took a long time to develop that. Go ahead, Jenna. Yeah, so just briefly, Peter, would you move it to slide 74? There was a request for that. Somebody missed that schedule. And then, you know, follow-up, just a follow-up on top of the previous question asked, does strategy change because of business needs or executive desires? Matt, you want to start off on that one? We have a coordinated this, by the way, guys. So we're just pre-flowing here. Go ahead. I just sort of missed the last part of that question. To strategy evolve, because strategy should evolve, does it change because business conditions change or does it change because the chief executive gets another wild hair? Maybe not paraphrasing that exactly correctly. That's about it. Sure. Well, you know, and this is one of the job dangers of being in a service business trying to get strategy. Your strategy is only as good as the buy-in and the commitment of the executive and actually, you know, operational support. So, you know, I'd like to think you could have, I'd like to think you could separate the two, that you have a compelling strategy and that it doesn't matter who the personnel are, but we know that a lot of the tough work in businesses and then, frankly, in our business and consulting and educating clients is to get that buy-in and to have some ideas of how you can get these strategies implemented. And so, you know, I mean, I think in a broad scale, yeah, we can say we can read Forbes or whatever and we could find some catchphrases that are going to resonate and some strategies that oh, yeah, we want to run after big data and we want to take advantage of that. Certainly, you can go that route, but, you know, we know personnel matters and finessing and getting along with and finding the messages that resonate with a given leadership structure is vitally important. So, I would absolutely agree with you. And what I'll also say is that what we're talking about in this particular webinar is putting in a process for absolutely allowing the executives to change strategy as they will. Now, yes, of course it can be arbitrary and capricious at some point. Matt, you're in Indianapolis. I'm in Richmond, Virginia. And, you know, we had a really interesting company named Figgy move into town because the chief executive's spouse wanted to live in Richmond, Virginia. Well, Richmond, Virginia is a lovely place to live and you know, may or may not be the best thing for doing Figgy, but they were here and they moved out the entire company. 500 people, corporate headquarters, everything else moved out after five years. I don't remember whether I think I heard rumors that the executive got divorced. So, maybe when the spouse no longer wanted to be there, they'd move out. Well, that's arbitrary, but the point is implementing something like this that is a clearly a needs driven cyclical approach. This will be a lot easier to change than it would be if you had a fixed piece that did not allow you to make rapid changes in the organization. So, your strategy should evolve with changing conditions. No question about it. And, of course, if your strategy evolves, your data strategy needs to evolve as well. And this repeatable process here is one that shows organizations how to roll with those punches. So, if it is arbitrary and capricious, you can still deliver value as a person there because you don't have much influence over what the chief executive, what they want the company to be or where they want it to be. So, you will see lots of things that are in there. On the other hand, there are many companies that go in and have a good idea of where strategy is and they find it's a terrible idea. They go down that path and somebody else comes up with a killer product that comes along and knocks them out of the market. Once again, this approach will make it much easier to recover from those inevitable bumps in the road that you will hit than other types of more formalized planning. I was going to put a joke in there, Matt. Again, we both like to pick on the big guys. But, you know, when you do get that 100-slide deck, go through it and just see if the last customer's name was completely removed from it. I was working through a deck this week and it was in the pharmaceutical industry and it was for, you know, one company and we were looking through another. And I said, oh my goodness, here's one of your competitors in here. Do you really want to tell them we did the same thing to the competitors that we did to you guys? That's probably not the best idea, you know. Yikes is right. Anything else on that one, Matt? Yeah, yeah. So I think the other part of this though is we want to build data capabilities that respond more quickly to changes in the market and to changes in your consumer base. And so one of the essential metrics we talk about that a CDO or, you know, chief not a chief but, you know, a big data executive would keep their eye on it's time to insight how quickly can you go from an analyst or an executive thinking about something in an office to actually having the data to support, you know, or not support their idea? How fast can you make that happen? Do you measure that with a stopwatch or do you measure that with a calendar? And that's a huge difference. I know, you know, Walmart, you mentioned Amazon, Google, we know that they can quickly turn these things around and then they can make business decisions off of that. So, you know, I'd like to think that a data strategy should enable a company to be a lot more agile, a lot more quick to respond to changes in the market and changes to their business model. Absolutely. I'll tell a quick little story here on one organization that we were working with. They had implemented a new feature that was basically taking balances off of other charge cards and moving it into their charge card at a lower interest rate. So that's something that should be attractive to the consumer. And they sent out a big marketing campaign on Friday and then called everybody in IT back in on Saturday and said, by the way, we just told them you could do this. How long is it going to take you guys to have it ready because these things are going to start coming in on Monday. A little bit of pressure there to keep them going, right? Sure. Shannon. There are so many great questions coming in here. So let me kind of say along the same path here, you know, in adapting a parent organization's data strategy to your own organization, what are the biggest challenge or what first steps would you recommend of them becoming familiar with the strategy they've sent you? So this is somebody delivering on high and saying, okay, we should do this. Well, Matt, I'm going to guess that you probably have seen this as I have a couple of times where an organization will say, oh, okay, you know, let's say it's a heavy technology focused strategy and that, you know, we are now going to implement it again. I'll just make it up. We're going to implement a big data lake and that's going to be part of our data strategy. Well, it is only a part of it because we remember both of us have said people, process, and technology and at least I will say that technology is the last thing you should consider instead of the first thing. But sales guys are really good out there and we're both probably dealing with lots of organizations that have been told a data lake will solve all the problems that your data warehouse couldn't solve and, you know, take care of it. I think that the results have been actually fairly poor around that. Data lakes can become very useful for certain types of problems, but they're not a general solution to everything. It's like saying, hey, aspirin will solve most of your pain, right? Well, if you've got a broken leg, it doesn't matter how much aspirin you have, it's not going to solve the broken leg problem. Matt, anything with inherited strategies? Yeah, I could imagine that that could be a very difficult situation. Again, I mentioned every organization has some sort of, they have built-in constraints, they have investments, they have political capital invested in certain people, processes, or oftentimes technologies. And so finding a strategy within that can be difficult. I would empathize with anybody that just sort of has to adapt to what is there to what comes from on high. But I would say part of me would want to fight back with the idea that with small P technology, with really Excel spreadsheets and things like that, there are certain things that you can collect metadata you need. I mean, this is kind of a micro problem, but let's say, you know, you're forced to not collect the metadata you need. Well, one solution is to just continue doing it with small technology until you can sort of make the case that you need to be collecting more metadata. That kind of thing comes immediately to mind. But, you know, we again, our strategy is always about adapting and I would hope you could come to common principles. I think that's a very good place to leave that one. The idea is that what most organizations have an idea of strategy, it should be based on something. Rather than simply saying, we need a data lake, you should actually be saying what is the data lake supposed to solve in your organization? You'll be very surprised in many cases where they're saying, I want a data lake to solve something that actually can be solved with a spreadsheet. I had one organization that said, oh my goodness, you know, when you finally pulled our data warehouse apart and took a look at it, it was actually there to serve exactly one user and we spent $30 million on it. Whereas, if we'd just taken, you know, half a dozen MBAs and locked them in a room for an afternoon, they would have come up with exactly the same solution at a much lower price point in there. Perfect. And, you know, I love all these fantastic questions coming in. You know, so what are your thoughts on evolving data ops if familiar, or is it more overlapping or complementary to data strategy? Did you say data ops or DevOps? Data ops. Yeah, so I don't know that we've got a good definition on that. Matt, do you have a good definition on data ops just yet? I see so many that it's been very hard for me to actually see what's the incentive behind that. No. I'm going to kick that one right back to you, Peter. So I think, Shannon, what we see in the marketplace today is that everybody is looking for solutions. And nobody wants to go to the real solution, which is how do you get to Carnegie Hall? And the answer is practice, practice, practice. Well, there are too many organizations that are trying to rely on these new catchy buzzwords. And so I've seen DevOps. I've looked at it. DevOps seems to be a nice way of incorporating and broadening the benefits that come in an agile environment to a more broader technology environment. I have not seen enough consistent definitions of data ops to convince me that anybody's actually got anything there beyond a little bit of, you know, nascent floating and, you know, sort of trying testing the winds in that area. I think we might as well, we're going to see other things. I've got some other friends that are coming up with gamifying data governance, right? And I think that's actually a great idea, but it means different things to different people. And until we can come up with a standard for it, it's really hard to describe any values for it. Well, it goes back to big data and analytics, right? I've never seen anybody come up with an objective definition of analytics, right? Oh, it's using tools and stuff beyond Excel, right? Well, okay, so what? You know, if we don't have an objective definition, it's very hard to describe value to it. So I think that one is too immature to actually to give any conclusions on. Maybe it will become more firm in the long run, but at least at the moment I don't think it's mature enough. I mean, I will say this, actually, that I think we're basically aligned with the idea of you should measure things as much as you can and you should measure data processing, data processes in the same way you would measure other processes. We talk about a data supply chain and so applying supply chain metrics to the way you handle data, the way you ingest the data, the way you process it, get it ready for consumption by your analysts and data scientists. I'm definitely on board with that. Now calling it data ops or whatever you're going to call it, I don't have a strong opinion on. So for either individually, so certainly individually, what are your individual opinions of strategy on a single page for a simple, easy comprehension? Are you a big fan of that? Are you not a big fan of that? Personally, I'm a huge fan of that because what that says is that we have actually distilled it. Now, I'll say distill it to a single piece of paper, but at the same time, absolutely make sure that it's numbered. Right? So our focus on data strategically is on this piece, whatever this piece happens to be. I'll put up Walmart's again just for lack of anything better because this is about as pithy as they come. Right? And this is listed, they're posters all over the Walmart environment. You walk in, you see this posted everywhere. It is the definition of the word inculcation. They have done a great job of doing that by making sure that everybody adopts that. So having that kind of an articulation on a single piece of paper is great. Just don't make sure that that single piece of paper is written in ten point type and it's all text because everybody will just walk past it and look for a pattern in there and think it's a hidden picture instead of actually something useful. Matt, one piece of strategy, any thoughts? Yeah, I think I generally agree with you here about people pitching movies in an elevator, the elevator pitch. You need that, but it should be the result of a lot of experience or a lot of thought done ahead of time or in the sort of backstage area. So I'm all for concise and being able to tell a story. At the same time you got to have the ideas and the sort of approaches in your store room to be able to execute on that one page and make it real. Absolutely, absolutely. A lot of perspiration has to go into it. Mike Hammer used to talk about the ratios of that and he would say it's almost a hundred to one. It's like if you use the movie analogy, it's kind of interesting. You shoot an hour's worth of stuff to come up with a minute of film time. Preparation and everything around that, and that should be the same thing. The picture the one page should be the result of your strategic exercise. It should not be. My strategic exercise was I wrote something on a single piece of paper. I hope that distinction is clear there because I think everybody, I think Matt and I are at least on the same page on that one. Yeah, we're not talking about a bar conversation in the napkin. Because that's good. I'm not opposed to that either. Yeah, we're all on that. I love it. Everybody, feel free to ask additional questions and more clarifying questions if you want more information there on that. Continue on here. How do you link your data program to IT projects and incorporate it into that? That is a tough one. We've had probably more pushback in that area than any other area working on this because there is no general agreement on where data is housed. My personal recommendation on this is that because we need to do something different with this, we need to make data separate from IT. IT is not well qualified to assess, for example, the value of the data because their primary concern has been connectivity. If people can't get to the data, they get yelled at, but the fact that they can't get to the data may or may not have an impact on the bottom line of the business in there. So I very much want to separate these two. IT works in a very we've been trying to get IT to work very well in a project mode for years and years. Data as a project does not work because you need that higher level programmatic management to develop shared data. If I have everything in a project mode as IT correctly is trying to do, then in order to get project 1's data to match with project 2's data, I'm going to have to have a third project that will integrate between project 1 and project 2 because project 1 is only about building project 1 and project 2 is only about building project 2. Project 3 is the one that integrates them and of course if you do that between all of your projects, you might as well just put in place the central data office that Matt referred to on his third slide. That is the definition of programmatic approach to data management. I think there's some interesting historical and cultural issues with where those boundaries are, what IT is responsible for in terms of data. It also points to one of the complexities that we over here talk a lot about data existing in various ways and locations that exist on paper and reports that were obviously exist in databases, but it also exists in people's minds and that's an important part. How does somebody in the organization interpret this piece of data? Now that doesn't exactly... That can be hard with some technical people, don't really want to consider that part of data management so that can get left out and therefore you need some sort of executive or some sort of office that can manage that, the differences between the business side needs and demand and the IT infrastructure support function. I think one of the things if you bring in an interim CDO, I kind of like that idea Peter, one of their jobs might be to bridge that gap to an extent to be able to connect. Again, business needs to technical support and the IT side. To take one for the team. And I think there's a good reason for it. This is sort of where we started out the presentation today. The accounting has been around for 8,000 years. They've had 8 millennia to get their act together and getting their act together results in things like generally accepted accounting practices. We're very, very happy those exist because it gives us consistency. We have not developed those for the data world. We need to. And that is something that's going to take us a little bit more time, which means all of you listening to this program are going to be participants in that development process. And that you will start to get better at this. But you can't assume that what works for General Motors is going to...actually let's do Sears. Because today Sears is going out of business. So hey, what worked for Sears was generally good for everybody right? Well, sorry Susan, right? Sears looks like it's not there anymore effectively from today. So that what worked previously is probably not going to be working what's going on in the future. So take somebody that can make these changes, bring them in as a change management. And then once things have settled down, then you bring in another type of executive. Let me tell you one more story on this, Shannon. I think we're getting close to the end here, but I do want to load this through because it is useful. The word, excuse me, the acronym CEO between the years 1880 and 1940 stood for Chief Electrification Officer. And between 1880 and 1940, businesses around the world were deciding what electricity was and whether it was something they should incorporate into their business processes. So the Chief Electrification Officer was very useful for that point in time at helping people. They developed specific expertise around electrification and could walk into places with specific knowledge and skills and abilities to say, hey, I can do this way of making these things electric. We may need the same thing in data. Maybe in 20 years, 30 years, we won't need Chief Data Officers. But for the moment, what we've been doing has produced the results that we have. And I'm pretty sure most people are not satisfied with the results that they have, so we need to do something different. All right. Matt, anything you want to add to that? Anything additional? It's a great story. It gives you some perspective on things. But yeah, the sort of uniformity of data management, I think we're, you know, every day we're getting a little bit closer. But it's an interesting problem because you want uniformity but you also want the ability to be flexible and respond to business problems. So how do you create architectures and processes that create the data well but don't inhibit it unnecessarily? It's a great problem to work on. And that's what makes it fun to be in this environment right now. Frankly, software engineering is boring compared to what we're doing, guys. All righty. Well, I love it. Well, that is, we are just closing in on the bottom of the hour here. But thank you both for this great conversation. It's been a great conversation. Thanks to all of our attendees for being in so engaged in everything we do. We love all the questions that have come in. Again, just a reminder, I will send a follow-up email to all registrants by end of day Thursday with links to the slides, links to the recording of this session. And again, Peter and Matt, thank you so much for this great presentation. Thanks, Dan, for sponsoring. It's been a great start to the new year. It's been a great webinar to kick us off. Good. Matt, are you headed for Enterprise Data World in March? I'm not sure if I'll be able to make it, but if I do, I will find you. All right, maybe that or we'll come to Indianapolis and find you at some point. Remember, Shannon's in Tulsa, so we've got coordination here. Just for now. All right, y'all. Thanks, Shannon. Thanks everybody for attending and participating. Thank you, Matt. Bye-bye.