 Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Officer for DataVersity. We'd like to thank you for joining today's DataVersity webinar. Strategy is where data architecture and data governance collide. It is the latest installment of 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 by the Q&A section. And if you'd like to chat with us or with each other, we certainly encourage you to do so. And just to note, the Zoom chat defaults ascended just the panelists, but you may absolutely switch that to network with everyone. To open the Q&A or the chat panel, you can find those icons in the bottom middle of your screen for those features. And 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. Yes, we are recording, and we'll likewise send a link to the recording of the session as well as any additional information requested throughout the webinar. Now let me introduce to you our speaker for today, Dr. Peter Akin. Peter is an acknowledged data management authority and associate professor at Virginia Commonwealth University, president of DAMA International and associate director of the MIT International Society of Chief Data Officers. For more than 35 years, Peter has learned from working with hundreds of data management practices in 30 countries, including some of the world's most important. Among his 12 books are many firsts, starting before Google, before data was big, and before data science, Peter has founded several organizations that have helped more than 200 organizations leverage data, specific savings have and specific savings have been measured at more than 1.5 billion US dollars. His latest is anything awesome. And with that, let me turn everything over to Peter to get today's webinar started. Peter, hello, and welcome. Shannon, it's always so good to hear you and it was great to see you last month out at Enterprise Data World where we had a really record breaking crowd and a really fun time of everybody getting back together after the pandemic so wonderful to catch up with everybody. Our topic today is the intersection of architecture and governance and these topics come directly from you all the audience who are asking Shannon, hey, can you put a program together that describes right and that's how we come up with these things so some number of you were saying, well, how does architecture work with governance. So I decided to add the word collision and actually I think Shannon had the word collision in there. And I added the word strategy on top of it, but this is what we're going to talk about today. Give you an introduction, talk a little bit about data confounding characteristics and leading to a very uneven understanding, even among data architects and data governance professionals. I'm going to link this back to the DIMBOK foundations that we're talking about, and then we'll move to the next section which really defines data governance the next section after that defining architecture and of course the last one says how do we do both of them at once because we need to. We'll finish up about an hour from now and look for the really fun part of the show which is where you guys get to try and stop the chumps appear on all of us so let's dive right in. I'm going to talk about to waste any of your valuable time on this and talk about data in particular so data has some very unique properties, among other things it doesn't obey the laws of physics, which is kind of a problem. Most people expect things to obey the laws of physics and data does not. And what is an asset and most organizations will say well that's a resource controlled by the organization as a result of past events or transactions from which future economic benefits are expected to flow so your pencils are assets but you don't expect a whole lot of benefits to flow from those pencils data is really pretty much unlimited in terms of what it does, but also not really visible. And again with the caveat there absent competent visualization expertise. This is actually one of the careers that the students in my program are getting very excited about data is also very cheap to transport I can take a 32 gigabyte USB drive 32 gigabytes. Yeah, that's right. Put tons of stuff on there will get all sorts of people in trouble. And of course making a copy is practically free Doug Laney uses the term non rivalrous which is a proper definition. Finally, we can always agree that data, when it is spilled is almost impossible to clean up. So they don't have a nice data remover stain remover. Another important characteristic of data is that 80% of it falls into the category of rot. It's an acronym that I did not invent but grabbed from somewhere on the internet and wish I could find where I grabbed it to give them proper credit for it but it means data that is redundant obsolete or trivial and the only argument I ever get from anybody about this is that you can go on the side and say, our data is 85% raw Peter, it's not 80%. Okay, I won't tell who you are on that. But, you know, it does lead to some really particularly interesting questions. And of course, a lot of it's of unknown quality to you want to be the organization that stands up at a meeting and says, all of our data is of unknown quality. It's probably not exactly the best way to present your data. And certainly your management wouldn't want you saying that as well. So, you know, the organization as well as generally non existent outside of it. And it's very inconsistently taught. Again, our standards in this area are really problematic and quite frankly between us chickens on this call here. Most universities don't even do a really passable job of teaching them the one thing that they know they're supposed to teach them about data which is how to build a new Oracle database. And I'm not plugging Oracle here Oracle still gives it away for free, which is why all of the universities teach it. We're also missing some business context as they're very happy to put up a database but what the database is used for how the data is used is not typically part of what their programs cover. And what that means is that every workgroup in your organization has had to learn about data, all on their own. Why is that a problem. Well, here's a fellow who was told to go off and play piano. And while he did an Eastern and while he did a credible job of playing a tune by throwing pink balls at a piano that's on the floor. It's not going to hit that quality measure if that's the important driver that we're trying to do in this area. So just, you have lots and lots of wallet Eastons in your organization. They have through their own initiative learn how to do something that works really really well but you know Wally. If you really want to learn how to play quality piano. Let's get rid of the balls and let's get you a proper keyboard sit you down in front of it teach you about music. But we won't go too far down that one that the real challenge has been that as a result of this confusion over the years it has thought that data is a business problem after all if they can connect to the server. My job is done says the typical stereotypical it person and the business thinks it is managing the data after all what else with that person whose title is chief information officer be doing, except taking care of my data. And there is of course, many, many other things CIS have an enormous portfolio, and data has not been one of their strong points so data has fallen into a chasm between business and it and our job as data professionals is to try to repair that and make it easier for people to understand, because unfortunately while we understand what the effects of hoarding are and things like that. The cost of visualizing data debt is really problematic because member data does not obey the laws of physics and is not tended to be visualized outside of the professional environment. So we have to have an understanding that data debt needs to be addressed proactively, and it slows progress it decreases quality it increases cost and presents greater risks. And if you don't do that let me give you one very specific example on this this was an article from Forbes magazine a couple of years ago during the pandemic, when the airlines weren't flying very much. The American Airlines was valued by people who wanted to buy the data in American Airlines a advantage program that's their frequent flyer program at between 19 billion and 31 billion dollars but the airline at the time was only valued at 6 billion. The United Airlines had a very similar experience here they were valued by the market at 9 billion but the estimates were that the data that is locked up in the mileage plus program was worth 22 billion. You had better believe that the CEOs of those airlines and many, many, many other corporations are depending on you all as data professionals to help them realize this value. In some ways you could sort of poke a little bit of fun at them and say you know hey I'll give you 31 billion dollars for American Airlines, and then turn around and sell it to somebody else at $6 billion and keep them keep the change but that's course over my pay grade we can't really look at that. When we look though how we are doing over history. This is a survey from Randy Bean and Tom Davenport not giving you the link right here at the bottom so you can go look at the state of yourself this is the most recent year. But it's the first time in about six years of surveying these folks that any of these measures have been greater than 50%. So, are you driving innovation with data is the question and the answer from most of these people 60% of the beliefs was yes we are trying to do that the first time and last year it was below 50%. However, all of the rest of these numbers are below 50%. Are you competing on data and analytics. The answer is 41% of them claim they are 40% claim they are managing data as a business asset. They're creating a data driven cult organization and 21% are forging a data culture. These numbers have not been improving in fact if you dive into a little further they've actually gone down and up a couple times, but they haven't moved a whole lot. As I said the first one driving innovation with data is really the first time in the surveys history that has gone over 50% of the organizations. But here's what I think is the really key finding from all of this. And that is on the same survey when we asked these people the same question over and over again year after year are your problems primary technology or they primarily people and process challenges. In 2018, you can see it was an 8020 split 2019 but look down 2020 1090% 2021 seven and eight. I think the thing to observe here is that the consistency here is that clearly, most of your problems in technology are people and process problems. And what other group in your organization other than data governance is going to be able to address these challenges in a way that makes sense for everybody. If you haven't seen this next chart here. This is our DIMBAK wheel. We're very proud of it Dima International for having created something that conceptualizes what's going on here. The challenge with this wheel and I'll go ahead and critique ourselves on it because it's always good to learn and improve is that this model this this representation of data management doesn't include the concepts of optionality, and it doesn't include any dependencies in there. So people tend to look at this and say oh I've got to do one of those pie wedges. Whereas the proper answer really is that it's going to take probably a combination of at least three wedges. So that data governance and data architecture highlighted you can see in the lower left hand corner there's some obvious cooperation that needs to take place, but really in order to do this right it's going to take a three legged stool in order to do this and that may be that you're doing a business data warehouse or you're standing up a metadata repository, or you're diving into reference and master data management, etc, etc. The key here is of course to understand that really a combination of these areas, not too many not too few is what you really need in order to make this work from a strategic perspective on this. That's our little introduction here let's now go into defining data governance. And once again I've critiqued this because most people encounter data in the same way as the blind persons encounter the elephant, the one with the tail says oh I looks like a rope here and one of the elephants the elephant's broad side says it's like a wall and somebody else up on the ears says no no an elephant is like a fan. And of course somebody at the trunk says it's like a snake and somebody hugging the, the elephants leg is saying it's like a tree. All of these people are correct but then none of them has the full picture. And similarly when people come to data, we end up with the very same kind of things. It's a story, it's pipes, it's statistics, it's a dashboard and the answer is once again they are all correct, but they're unaware of the rest of the components that go into this. A wonderful term that I like to use on these is invented by Tom Redmond calls them hidden data factories in your organization and the little sequence that I'm showing you here is that Department A delivered work products to Department B, but Department B they've gotten tired of correcting Department A's or trying to make Department A correct their pieces and what they do now is they simply rework that internally because it's easier than fussing about it and trying to get somebody else to do that. Well, once again just like Wally Easton and the other ways of playing piano that are certainly possible. Yeah, it's the same problem with bees work. Again, there's two data factories that are hidden there. And when it gets to the customers and comes back from the customers again incorrect. We also have a third hidden data factory in there in order to look at it. And these hidden data factors cost organizations time and money and reputation, and it goes on and on and on. The key of course to understand is that poor data manifests itself as multifaceted organizational challenges. And these challenges look different just the same way as the elephant looks different to the blind people that are working at it remember you can't see data unless you visualize it right so they have a challenge around that. But we really need to understand though is that the root cause of most business challenges in fact I've gone 35 years with not finding one that wasn't so there's a data component to each of them is to understand that that data problem that they have is always filtered through an IT system or a business process. So I'm showing you multiple business challenges out here filtered through various combinations of IT and business processes, and no realization at the organizational level that these business challenges are all related by poor results and the human data challenge around that root cause analysis is part of what we're trying to do for data governance and fix these problems. I'm a very strong proponent of active data governance as opposed to what I call regulatory or passive data governance, eliminating data debt requires a team that has specialized skills. So if you're telling everybody that you've got a team of 10 people and they're each doing data governance on 10% of their time here, they're not going to be able to build up the whole processes that you need to have the muscle memory, the knowledge of the tools the knowledge of the data itself and how the data is used by the organization without having a full time team in order to do this so oftentimes I'm offered 10% of 10 people's time, I will always take one full time person, as opposed to 10% of 10 people's time because of course the switching costs and other type of distractions are really problematic. So talking about data governance, let's look a little bit closely at what we mean by governance. And we'll start out with corporate governance for starters, which is the relationship of the organization to society. Now, interestingly, just before the pandemic Jamie Diamond and a number of other CEOs came along and said, you know, we're going to sign a pledge so that the relationship of the organization to society is not strictly defined in monetary terms. Now where that goes as an initiative I hope it goes further and then should go further. But nevertheless, we are seeing people who are saying, yeah, corporate governance is about the relationship of the organization as a society and that includes a holistic perspective of the organization wants to be a good neighbor and it's the resources, a good employer to the employees that work in the organization. So that's what corporate governance is about we then of course have it governance that goes along with it. And that's to make sure that the it strategy is aligned with the organizational strategy and to provide some measures of how it is doing, given that particular piece. Unfortunately, though, when we get to data governance there are sort of seven primary definitions of people use and I am not going to read these to you you get the slides. So you can certainly take a look at it afterwards. These are all fine definitions but what I want you to envision is the standard elevator problem that we have. I mean, understand this have encountered yourself, perhaps, where you're getting ready to get on the elevator and all of a sudden a boss comes by looks down at your badge and says hey Peter you work for me. What do you do. Well, of course, I'm trying to actually that you are adding value. It's always good to say to them, I make money for you, but they're probably going to ask question. As you're looking at this. So this elevator pitch is kind of an important piece. I'm going to start to put things in place so that everybody is singing off the same sheet of paper. And from a data governance perspective I've had a lot more success with this definition of data governance then trying to follow through with any of those others. So what is that definition data governance is managing data with guidance. The first question that you might ask is, would you want the only resource that you have that you can't run out of that doesn't degrade over time, and that is really classed as a durable strategic asset managed without guidance. I think the answer to that has to be no. But if you don't frame the question that way people, why do we need data governance again. That's a good reason. Also, I modify this definition just slightly by as I'm going up further in the management chain on this to change it from managing data with guidance to in fact managing data decisions with guidance, because many managers are involved in data decisions without knowing about it. I'll give you a couple of examples as we go a little bit further into the program here but data governance is important, because it costs organization millions each year in productivity, siloed and redundant efforts, poorly thought out processes, delayed information, making because they have inadequate information, sorry, delayed decision making because they have inadequate information, and being reactive instead of proactive. And importantly, you can look at your total it spend and say, gosh, if you guys would do data governance a little bit better, you've got an opportunity to reduce by 20 to 40% your it spending through better data governance on this. I'm surprised that many companies report making inaccurate business decisions based on bad or outdated data, and that unfortunately leads us into something I call the bad data decision spiral that is to say that business decision makers and technical decision makers are not data knowledgeable. Therefore they make bad decisions, and that results in poor treatment of organizational assets and poor quality of data with poor organizational outcomes resulting from that. I love my little sample of Morgan Freeman there thank you sir it's this is wrong is what he says and I hope you agree with me. We want to get out of this particular spiral. The most simple example of this that I've seen happen dozens of times in recent years is an organization installing a package called Salesforce, or any CRM for that matter but sales force is certainly a popular one. And what happens is the Salesforce implementation project is driven by it goals of getting the software installed by a certain date. Well let's just pretend it's December 31, so that on January 1, we want the sales force to start using the new Salesforce software. Of course if we do that we know that most it projects run long. We tend to sacrifice the training, the testing and the transformation of the data when it goes long with these projects. And so we now have the very real situation where dozens of companies have done this recently, they turn on Salesforce with data of completely unknown quality systems in there. Now, why would you do that, especially because our unsophisticated Salesforce, the people that are using the software Salesforce. Don't know the difference between Salesforce being a bad piece of software and Salesforce being good software filled with poor quality data. If they would just delay a little bit so that we could do a proper audit on the Salesforce and then turn it on and say we've audited this it looks like it's maybe, you know, 90% of the way there in terms of the quality that's necessary to this, then we don't have a much better expectation, but of course, most of the time it's rolled out with here is the new Salesforce software, turn it on and see how it works and I don't know they still got my name spelled wrong well therefore Salesforce is not performing the way it should Salesforce of course does perform. It's only as good as the inputs. So garbage in garbage out along that. There's about a couple things that pop up in data governance very often that are really crucial to this decision. There are a whole series of these slides I'm going to show them to you very quickly and I'm not going to bother to read them to you that tell what are all the preliminary steps that you need to take in order to have a quick data governance program. There are a whole lot of deliverables again you can see them listed right here roles and responsibilities that you need to push out in their scorecards which are going to develop in terms of your data governance piece checklists that are involved with components that all go together with this and I'm going to put them up there and tell you to do them, but don't agonize of them, instead, evolve what you're trying to do in a way that makes a whole lot more sense. I just finished a wonderful book by a guy named Tim Hartford who it's called adapt and it makes sense from this organizations need to adapt in an evolutionary fashion in exactly the same way that we and all creatures did by evolving through the slime that we've had. So while people want to get started in data governance and they look at this looks like a long list of things that they have to do. Think about it, take a step back. You're only going to do this once. So the inputs are important, but they're not critical. And if you have an opportunity, put your time and effort into the right hand side of this diagram, instead of the left hand side of this diagram. Again, I'll take on the Commonwealth of Virginia where I'm housed in a taxpayer right at the moment, and we're getting ready to kick off our third iteration of data governance in the Commonwealth here, because they have not addressed this they spent too much time with the left hand side of this diagram, and it's not enough side, excuse me time on the right hand side of this diagram, any of you with a quality control background on this will recognize the PDCA plan do check act cycle, which in 35 years I found that all methods tend to accrue up to that cycle. And then another little bit about governance and why it's important. Again, this is the concept of the princess and the P and if you look at the bottom of these mattresses hands Christian Anderson's old fable was if you have a lump down here at the bottom, and the princess is really not sleeping up here because of that lump that's kind of like putting out a bad data model and being stuck with it or filling Salesforce up with poor quality data. So doing a poor job with data governance locks in imperfection for the life of the application if you go buy a Salesforce software or CRM software of any sort, and it doesn't match the needs of your organization. You're always going to have to be working around. The investment benefits that you can get from data and it decreases the amount of data leverage that your organization can run I know I said this once already, let's get more detailed about it the 20 to 40% of it budgets, migrating converting and improving your data. And again, if you can find out what's going on with it you can eliminate many non value added components in this in order to look at this, because of course lack of governance causes everything to take longer costs more deliver less and present greater risk. Thank you again Tom DeMarco for those wonderful words on that. A little bit about data governance. Let's now talk about architecture and architecture is about things but it's about representing things in a way that communicates those things to other people so we have the things those are the components thank you Dr Seuss on these. What are those things do individually and how do they interact as a system. Amazing what you can find out there on the internet right but it's the things interacting on this. So organizations will do some attempt to manage some of these architectures. My numbers show that it's about one in 10 organizations that try to manage any one of these architecture so first of all, if you're an architect at one of those firms that does this realize you have nine chances of not finding an organization that does architecture if you change your job at that particular piece and the problem really is if management thinks all that's happening here is that you have a bunch of technical committees that are sitting around talking about not demonstrating value. That's a big big problem because all of these architectures exist in your organization. All organizations have a data architecture by definition, but some of these architectures are understood. And in order to be understood it has to be documented, because if it's not documented it can only be useful to the person whose head, we're using to run the architecture project out of. I've tried for a number of years to find ways of explaining this to upper level management and I finally found a BMW commercial. Yes, this is a real live BMW commercial where of course you can see at the top I've written, you cannot architect after implementation. And while that's certainly an important component of all of this. It's also important to realize that we don't build things from the top down. In fact, if the Pharaoh told me as the architect of the great pyramid that I needed to have a swimming pool I thought I'm up it after I've built a very large object made up of rocks sitting on top of shifting sand. There's not a chance that I'm going to be able to put anything in the way of an indoor swimming pool into this after it's done. Again, you need examples that are as visceral as this in order to make sure that management understands them. So how are these components these data items these invisible things that don't obey the laws of physics expressed as architectures well just like any architecture we organize the details into larger components. And that means we have a sense of intricacy that we're working with in here. Similarly, the large components are then organized into models, and that gives us formal dependencies. We can't attach a charge to a customer if I don't have a customer number that exists for them in the first place. And finally, these models are organized into the larger architectures, which now brings in the intent, the purposefulness that we have in order to build these things. So architectures should be developed for a specific purpose. Again, it's going to be as simple as faster, better, cheaper, or less risky. And if we don't focus in on one of those goals, the architectures unlike to complement what actually exists in your organization. So let's change this now to data. We have attributes that are organized into entities that gets the intricacy we have the entities and objects, organized into models that gives us the dependencies here. And the models are organized into architectures that gives us the purposefulness. And while this is important, and I've given you examples of the first two when I look at the last one. I'm here to look at an example of a data architecture because it tends to be a very big thing. I can recall back when I was working for the Department of Defense, we created something called the DoD enterprise process and data architecture. And it was complicated like this one is. You're not likely to see these things as they come out in a very nice and easy to read quick type of a process instead they're going to be exposed piece by piece, as we go through each of these things and you'll understand a fraction of it, but getting the entire picture is a wonderful goal but probably not realistic in terms of achieving it. We've heard all sorts of definitions around here. Let's get to some very specific definitions here. This one first definition is tongue in cheek, data are little circles. Information is the circles filled out. Knowledge is connecting the circles. Then we get to insight. Oh, insight. Okay, so there's two yellow things at each part. And then we want to do something about how to get those insights and exploit them so that's wisdom on this. And then you want to get to impact. Okay, wonderful. And then, of course, conspiracy theories. Now, that's a joke. I'm just kidding on it, but it's kind of a nice little piece. Here's a more useful model. Some of you may or may not know what the number 42 means and I'll give you three definitions. First one is from Douglas Adams Hitchhiker's Guide to the Galaxy, wonderful science fiction book that has as a subplot, the white mice and the dolphins turn out to be running the world with human beings being the experiment. Okay, they decide to set up a gigantic supercomputer to find out the meaning of life. It cranks out for 300 centuries and says the answer to life the universe and everything is 42. I'm sure some of you are slightly confused stick with me for a quick second, because 42 is also the number that was on Jackie Robinson's baseball jersey and the name of the film that documented his life around that there's a different definition for the number 42 Finally, we could take it and say 42 is my age 22 years ago. Well, if I'm trying to figure out whether Peter is able to consume adult beverages in the Commonwealth of Virginia, that set of facts will actually give you the correct answer. Yes, I am old enough to buy adult beverages. What I've just outlined for you all, of course, is facts paired with different meanings. There's nothing wrong with those meanings they are perfectly appropriate. What we need to do though, however, is identify the useful data out of all of that, not just all of the data because that's too much. So each fact combines specific meanings with this. And when we have that useful data, we can then differentiate that objectively by seeing what data is requested. We transform data into information. And it's quite obvious at this point that you can have data without information but you cannot have information without data. I still have some companies out there that are trying to manage these things separately it's like trying to manage metadata separately from data. Metadata is data so you ought to manage it using good data management practices around that let's take this to one more level though because everything tends to come in terms of threes. How do we determine what information is strategic in nature if our business intelligence is our wisdom our knowledge systems depending on which decade we're talking to you from. This is how we do it would take the information that has been requested already transforming it from data to information. And now we're talking about how it is used strategically. And that gives us the ability then to say what are the key performance indicators and other things that we need to put in place. Obviously, this is a structure this is an architecture in and of itself. And if we use it properly, we can now start to find objective definitions for how data is used in this context, and this architecture then can be used to support organizational data leverage efforts. And I use this example of plates here to illustrate another purpose on this so one says well how is it that a data structure or data architecture support strategy well first of all consider the opposite question. How are your systems explicitly designed to be integrated, or otherwise work together. And I'm just going to pause here for quick second because I'm in my office which is unusual for me these days on this and I have a little clock that people saw fused to give out, where they would show you that all of their systems are integrated and you can tell time around the world. It's a clock but when you open up the back of the clock, it is running three separate clocks on three separate batteries so not exactly the definition of integration that you want to use if you're a company that is selling integrated software. So were your systems explicitly designed to be integrated and if not, what's the chance that they will just happen to work well together mean answers of course pretty slim, because they can't be helpful if their structure is unknown. So let's take a look at a couple of separate strategies around this. If I'm in a restaurant situation, and I'm creating a brand new dish, as in the physical dish itself, either plastic or glassware or China or whatever it is we're making these things out of for each dish and others this is a separate dish for peach cobbler and a separate dish for apple pie right and I break that dish, but I still want to have a fast customer service goal I've got to go back in and not just find another dish to put the apple pie on but instead find another apple pie dish. It's going to be clearly not as rapid if speed is our goal as having everybody use the same stupid dishes. Right. And again, don't get me wrong, everybody likes to eat in fine restaurants but sometimes you just need the food and you want it to get there quickly. This data stuff becomes sand in our organizational functions again I showed you the example earlier, where the root cause of data analysis was there, but this is what happens when bad data gets into our systems they kind of stop working or at least creek, a little bit further and we're going to use that sandwich analogy to take this one more step further. I like to use this. I call it a data sandwich analogy, because the leverage point for all of your data has to be high performance automation with as little human intervention as possible, trying to do that, however, in an organization that has a uneven data supply, uneven data literacy levels on the employees and uneven use of data standards in the organization is always going to be problematic so we've got to be able to come back and fill these things, make them work so that they will work together on this and the idea is of course that if we make it into the sandwich, in this case it's obviously a pocket sandwich or some sort, it's going to work well without that sand in the gears sort of metaphor, but of course it doesn't just happen. Instead, it cannot happen without investments in engineering and architecture, and I had to go all the way to the city farm in India to see the sign hanging up on the back of the cash register which I thought was wonderful. I mentioned it to them and we talked Deming for a little bit quality engineering and architecture work products do not happen accidentally. And of course it's even more true if we're talking about data. When I was in my office this is not where I am today this is a picture of my home in Montpelier, Virginia, and I'm taking a picture of something that will eventually be my barn. When I say that you may get the clue as to where we're going here yes, there's a foundation for this barn, but why did I stop and take pictures of it and document it and the answer was very very simple. I was blown in order to buy, excuse me in order to purchase the materials to build this particular barn on this. Don't get me wrong I didn't build it I had it built I'm not that kind of a construction person here, but nevertheless, before the bank would give me any more money. I had a foundation inspection from Hanover County, the county in which I reside and the counter county engineers came out, tested this foundation and gave me a certificate that said I had passed the foundation inspection only then does the bank give me the rest of the money to build on to the barn. So it makes good business sense and there is no it equivalent of this. So when we're looking for data architecture and foundations there's a couple of key points to this and the first one is that a data architecture is a mixture of database as opposed to database assets, supporting the implementation of strategy, the architecture has to be arranged and consciously tweets in order to make it work in supportive strategy. Most organizations have data assets that are not supportive of their strategies, ie their information architectures are not helpful. The real important question is, how can organizations more effectively use their data architecture to support their strategic implementation. That is of course the task that is up to you all as data professionals in here. So what is meant then by the use of an information architectural is the application of data assets towards strategic objectives. It can be assessed by the maturity of the organization's data management practices, and it results in increased capabilities, flexibility, dexterity and awareness internally of those specific capabilities is going to be accomplished through the use of what we call data centric development practices including use of taxonomy stewardship repositories, etc, etc, in order to do that. So finally, from a summary of the data architecture perspective, how does an organization achieve better use of its data architecture. And the answer is kind of tricky is like a Zen, go on, the starting point is not the beginning, because only when you're a startup without any architectures at all do you get to create one from scratch. By the way, that would seem to call in the question the wisdom of us teaching students to develop brand new systems out there, knowing that 80% of what we're doing out there comes from reworking existing systems as opposed to creating brand new ones in this in the first place. The information architecture components must typically be reengineered and there's a formal definition I won't get into it here, but it does involve using knowledge of your existing system and then applying that knowledge incorporating that finding in the new system. And that's in an iterative incremental approach, focusing on one component at a time, and applying a series of formal transformations to the process. So, from a data architecture perspective, we now can understand that they are ubiquitous but also at the same time not well understood, kind of like data, and that keeping improvements focused on things that are strategic, as opposed to things that need to be completed is really a much better goal, because you cannot use what is not understood on this will take the last 15 minutes here now and talk about how the strategic focus and for the coordination and collaboration around that process. First question people ask is, what do we mean by strategy and unfortunately most people get this wrong, primarily due to Peter Drucker and the rest of the business management consultants you can see here. This is a Google mentions graph that just shows that the word strategy was not used a whole lot before about 1950s primarily characterized in a military sense but the management consultants got a hold of it. What cool we can do that make a grand plan or a master plan or a program or policy or whatever it is that you want to come up with and you notice I'm being a little bit sarcastic here because most of the time these things are not workable or used. It makes strategy into a thing. And strategy in fact should not be a thing so let's go back to the original definition of strategy which is the one that the military uses and call strategy, a pattern in a stream of decisions. Now that's kind of interesting it transforms strategy from a thing a binder 100 PowerPoint slides whatever it is that they've delivered to you. Instead, transforming it into a process so that it can be utilized throughout the organization and what it's doing and your data strategy then has to be the highest level of data guidance available, focusing on data activities. Excuse me, I took that incorrectly focusing data activities on business goal achievement. There's no point in cleaning all your data if it doesn't do anything good for your business. So make sure that you can focus that on specific business goal achieve. But when your team is faced with a stream of decisions or uncertainties, they understand what your strategy is, we're going to optimize for price quality speed or risk depending on what you're trying to focus data quality, most of all, this specifically articulates how data can be used to help support the organizational strategy. And this involves a balance of remediation and proactive measures, which should then be the focus of your data governance and data architecture efforts. Both of them will come together in order to work closely to try and help solve those business problems. But unfortunately, most people think about data strategy by saying, there's an organizational strategy. An organizational strategy will derive an IT strategy to make sure that our IT is aligned with the organizational strategy. And then your data strategy comes out on that as well. Morgan Freeman. Yes, it is. This is wrong. Have to throw up your volume a little bit to hear them in there. It's still a very low sample on that particular one. So how should it be? Well, some variant of this is much more correct. Your IT strategy should be developed separately from your data strategy. And quite frankly, when you look at the influence, the influence of the data strategy on the IT strategy should be greater than the IT strategy focusing in on the business strategy. Again, this kind of thing here is looks easy on PowerPoint, but is really difficult to do. These are the people and process problems that we referenced earlier in the presentation. So let's take a look at how this actually works in practice. Data strategy and data governance work together in a strategic context here. And we look at the organizational strategy and say that the data strategy provides support for the organizational strategy in whatever form is needed. But then we look at how data strategy relates to governance. We say, what the data assets? Excuse me, what can the data assets do to better support the strategy and how well is that working? Is it going well for us or not? We also can throw into the component here the data stewards. The limited number of stewards are going to be available, which means you have a limited number of bodies and cycles, if you will, to start working on the things that are the data debt. The proactive that you need to go to transform yourself from a reactive organization into a proactive organization. You'll also notice that I've said as before, the data strategy should be expressed in business goals and that the language of data governance should really be metadata around that. Both of those concepts have to go in to the work that the data stewards do because if the stewards don't have in mind the business goals that you're trying to achieve. They're not using the language of metadata to improve what they're doing. And let's add another component. We need some sort of a trusted catalog in there as well. A trusted catalog is something interesting. Many vendors will like you to actually spend lots of money on a trusted catalog. And I've seen organizations spend seven or eight figures in this context here to do it. You can create a trusted data catalog using a web browser and a single web page. And it's, I think, is another topic is the metadata topic that I did that told a little bit more about the detail and actually did present some of the internal workings that you have to see in order to do that. But you do not need to invest six or seven or even eight figures into this in order to get some value back out of this. Let's take a quick look at models and model evolution. We are talking about data architecture here and all data architecture problems, challenges can be divided, first of all, according to to be aspirational and as is what we currently have. We can also divide the same set of boxes that we have there into validated and unvalidated models. Unvalidated models means you're keeping your fingers crossed and hoping there's not a mistake in there. The unvalidated model has been at least vetted to some degree and let's change them yet again and say that these work in logical, physical and conceptual components in order to do this. And the way to take a look at this is to say, we start out with these requirements that are typically in a series of use cases. We make a model out of it sometimes and we do the physical implementation. But every modeling change in here can be mapped to some sort of transformation on this network. Your strategy is what are we trying to do and why on this so data governance needs to be focused in on these areas in order to come up with this. Let's take it one more step further. We tend to do forward engineering. Most of the time, we're looking at validated models going forward because we don't have anything that we're looking at. But again, we've done 20% of this 20% of it expenditures are building new stuff. Whereas 80% of them goes into fixing the old stuff, which means we need to spend more time learning how to do reverse engineering of our existing architectures, coming back from the as is to the design, and from the design to the requirements, and then moving that information so first reverse engineering the existing system to understand its strengths weaknesses, and then using that information to design the new system. I see so many organizations that say they're reengineering that aren't even close in terms of what they're doing here. Let's take a look again how strategy can work in the context of architecture and governance. At first your data leadership is not really going to understand architecture but they're going to set up some data governance they're going to say data is going to improve over time. So many people consider that to be very slow. We got to be careful with that, because we have to manage expectations carefully. Most organizations then come back after some time of saying it's slow and try to speed it up through something at least the US Army calls a data improvement project or a dip. We have better insight in there we can now put in place, our data governance structure that allows us to get things to happen and put in place, much better practices in order to do this improving the quality of the data. But most importantly, we've got to get better at saying when data things happen. We want there to be an equal recognition that organizational things happen so don't talk to people about cleaning data elements. Don't talk to them about improving the targeted advertising that your organization is doing data architecture components make better targets of these reengineering and digitization efforts. Finally, you can keep the focus going on these by looking at a subset of things from the grand subset of everything in the world out there that would further organizational strategy and everything out there that the business uses in data on this. And let's trim it still further. What sort of data skills do we need on our data teams and when you have a match of all three of those things that's kind of the golden circle or the golden triangle of where you really want to focus these things in really really well. There's a lot of components that are in the data community here. Again, we're going to have typically somebody will draw a line around the left hand side of this diagram and say that's our data organization that we're going to have but there's these other components. That go into notice, of course, it's all based on it. And there with that leadership is going to bring into place resources, data feedback and decisions that are going to be made those decisions are handed to the stewards for implementation. They then take some action, hopefully getting other people to make action as well and make a difference make things actually go better. We're still going to look for feedback ideas and other types of guidance that goes into all of this. But if we don't have a strategy that guides it. Again, the architecture is the thing that you use as your playbook, trying to figure out how you're going to be using these things. One other additional comment around this we talk about strategy being the place where these two components come together. And people think of architecture as, you know, sort of a passive type of thing I like to think of it as a firehouse, both governance and architecture can be likened to this. We all know what happens at firehouses. They don't sit around waiting for fires but there is a very proactive stance. For those of you that are old TV show base you'll know that the MacGyver approach to data governance would involve paper clips and duct tape to get it to work, because we don't have a lot of resources. Our folks are out there fighting fires trying to do things, but at the same time we want to first reverse engineer the system and use this information to inform the government the design of the system and this has to be a function of data systems to be able to sell this to everybody to make sure that it works the way in which we wanted to. One other critical piece from a governance and architecture perspective is, how should we govern all this data. And the answer is, we're not going to govern all this data the right question should be, is this data, includeable in the scope of our current efforts and initiatives. Because if we don't include it in here we're saving ourselves time and money, you all as the data professionals out there are the best judges as to whether something should be included in here or not, regardless of the decision by the way document why you're doing this. Another important concept to focus in here as well as the concept perhaps of defensive driving. Now, it is still taught I do surveys in my class and find out that some people are in fact exposed to defensive driving you can see the general principles that are there controlling your speed looking ahead, anticipating things that are likely to happen, as opposed to being surprised that somebody's not behaving correctly on this, but I find that defensive driving has another important component which is safety as well. And this is a little thing that you might see at your local state fairgrounds called the convincer from Minnesota Department of Transportation, if you've ever written on that it simulates a five mile an hour collision. And just at five miles per hour if you've ever experienced that you'll never forget to put on your seat belt. Again, so it's taught part of basic driving the behavior becomes part of a lifelong series of practices, and it's difficult to practice after driving has already been taught. So this is where the convincer comes in to get you to clip up your seat belt and remember that we're going to put it in place, so we can do this. Another key component of your architecture and governance programs is that they have to be programs. And I'm not going to read you this wonderful passage from the Project Management Institute in here, but instead just note that your data program is going to last at least as long as your HR program in order to do this. So we have a series of data literacy components that architecture and engineering should get together. I'll just mention them briefly because it's a subject of another topic but importantly, think about what people comprehend externally and the answer is not much. So we have data stuff that we do and we've already talked about architecture and governance so far. And most people don't pay any attention or care about any of this. So just refer to it all as your data program. If you don't refer to it as your data program, and you try to get them interested in the details of each of it, they will walk away. They are not interested. They're not going to pay attention. So don't try and tell them the difference between a reactive data steward and regulatory guided data steward around this. They're just nonsense externally. They're important internally, but if you try to explain them externally you'll get run over pretty quickly with derision around that. So we've covered in the last hour strategy is where the components of data architecture and data governance collide. And I started out by telling you that data has some very confounding characteristics, which means most people outside of the practice are unaware of them. They have an uneven understanding, even coming through good educational programs such as the one that I'm teaching in here at Virginia Commonwealth University, but do keep an eye on the DIMBOK as that is the basic set of guidance. In fact, the US federal government has determined that this is what they call best practices now. That's from the US government. It's not necessarily from us, but it's still flattering that we've managed to do this. And understand that when we look at data governance, you need to have an elevator pitch. The governance pitch has to be something that everybody in the entire organization can meet, managing data with guidance or managing data decisions with guidance, because failure to do that does not do anything to eliminate the rising cost of organizational data debt that we have in there. And it really does require an adaptive or perhaps even an aggressive rather than a prescriptive approach in order to do this. Your problems are your problems. They are not the problems of the organization across the street. If you find data architecture then it is ubiquitous but similarly not well understood and keep improvements practically focused on strategy. Very important, just the fact that you can get something perfect if it doesn't move the needle somewhere. It's probably not worth using or investing in. Finally, here, you can't use what you don't understand. You have to make sure these architectures are exposed. Your governance group should be very familiar with your data architecture, your data architecture group should understand that the governance group is interpreting strategic direction from the rest of the organization, and that that should guide the investments that are made in that architecture in order to improvement. Strategic focus then improves coordination. We need to up in the traditional we need to look at things like defensive driving storytelling, but about everything about the whole thing. And finally, I'll give you just a quick second to get ready for your Q&As, give you a couple of takeaways on this. The need for this intersection of data architecture data governance is increasing. Volume, new discipline, it's going to conform to constraints and there is no single best way to do this. But both of these efforts must be strategically delivered so that we can re-engineer components opportunistically and improve strategically, giving us shared focus gives us places that everybody will agree these are improvements out here. The goal is to improve these effectiveness over time in order to do it because the more data delivered at the organization, the easier it is to do the various transformations. Okay, I want 22 seconds over Shannon. You can dock me on that one. But welcome back. Your record's broken. No, Peter, this is great. Thank you so much for this great topic and presentation. Just to, we'll go into the Q&A here first. If you have questions for Peter, feel free to submit them in the Q&A portion. And just a reminder to answer the most commonly asked questions, I will be sending a follow up email for this webinar by end of day Thursday with links to the slides and links to the recording. So diving in here, Peter, do you consider a data governance roadmap the same as data strategy? If they are divergent, we have a problem. If they are complementary, we have less of a problem. I don't know that I would go as far to say that the data governance roadmap is a strategy, but it's certainly how through data governance you propose to take some steps towards that goal. It's a real key for strategy. And again, just go back to, I didn't say this particular part of it, but there's a saying by Mike Tyson, everybody has a plan until they get punched in the face. In the military, that concept means the plans go out the window the moment the enemy is engaged. You have to think of it that way. It's got to be as simple as always turn to the left, if that's the guidance that you want your organization to do, or let me give you a very practical version of it. I did a couple of years with Walmart, really fine organization, and their strategy was everyday low price. So if an associate that was working with data did something and it helped enforce the goal of everyday low price, they were never disciplined. They might be coached, they might be have some additional further complexities involved in the process, but nobody ever got fired at Walmart for helping the organization achieve its strategic objective of everyday low price by managing data with guidance and making the data architectures were optimized to provide the lowest possible cost to the customers that were out there. Really great question. I hope what I'm teasing out here is the fact that a roadmap should be only slightly longer than your data strategy and your data strategy can really be quite, quite short in terms of his guides. Again, another example that we use oftentimes is skate to where the puck is going to be. Right. If you're chasing the puck you're never going to get anywhere but if you go to where the puck is going to be, you can use that as a strategy similarly data should also be in there I'm working with an organization. This was a year this week that was putting in a CRM. They didn't really have a good handle on what their data was. So that's going to be a problem because CRMs are about managing customer data and trying to figure out where it goes. Again, thanks for the question a really good one. Good one. So, Peter, where do you, how or where do you see reduction in IT spend related to better data governance. What are the primary areas that shows up where you can actually track it. Fantastic. I actually have a book on that. I'll just flip to the next side is that one up there called monetizing on there. So I'm going to go up to Canada day-to-day in a couple of weeks and present on that particular topic for any of you that are in the area of Ottawa and participating in the day-to-day on here. The question is how do you make this tangible for people? How do you make it and the only thing that most people in the corner office you can guarantee that they understand is some sort of currency. So we'll recall at the beginning, Shannon, when did you introduce me? She said I've got a lifetime total of one and a half billion dollars that I've managed to put out in definitive savings acknowledged by the organizations that are there. There's several examples of this. One of the things you may find is that you have a piece of software that doesn't work the way your organization does. Again, I'll be very precise about this because I can recall the example. We had one system that was being replaced and the system that was being replaced was being replaced by a PeopleSoft implementation. Again, just coincidentally, I talked about them earlier. They're not bad or good. They're simply a big piece of software that tends to work pretty well around this. So the PeopleSoft version of the process that was replacing the custom created piece in the organization. The custom software that was originally created there had all the data that they needed to service a customer on one screen. So the customer service rep could deal with somebody face to face and have access to everything that they needed in order to satisfy the customer. However, the PeopleSoft version of that same process implemented those 23 data items across, excuse me, those data items across 23 separate screens. Now I don't know about you, but I'm too old to be able to integrate 23 screens of data on the fly while I'm trying to help a customer. So we had to go back and redo that and that came at a cost. And that cost was very tangible to the organization in order to look at that. There are lots and lots of other examples of these just Google monetizing out there you'll see a lot of good authors that are writing on this or grab a copy of my book. Again, thank you for the question. We do need to take both the architecture and the governance components and relate them to business things that are happening so that everybody understands we're not just cleaning all the data items. We're cleaning data items so that the marketing can be better so that the quality of the end product can be delivered whatever the business objective is that we're trying to do in order to come up with this again. Thank you. Indeed. So, Peter, do you think adding to your definition managing data with quote unquote inform guidance would help improve it or provide more authoritative footing that follows defined standards. Of course, the key is to find out what's going to work for your organization. And I've worked for a lot of different organizations mom and pop shops all the way up to the Department of Defense. So there's there's lots of answers to that question. You are the best person who can judge that if it works better to say informed guidance should be there. That implies that there's some sort of uninformed guidance that could also be influencing it and that might be very valuable in that particular organization. I find that most people think of guidance as just sort of wisdom. In fact, interestingly enough on my trip to China earlier this year I found out that the word dama in China means the wisdom of the elders coming down. And I think that's a pretty good way to think about it. So, yeah, we'd like it to be good guidance but if I have a definition that says managing data with guidance, and it's implied that it's not good that's going to be a problem. Definitely take your point on that. But I think that most people say guidance is good enough for us we do want some guidance there. Now let's talk about what the guidance should be in order to do that. Yeah, if it works for you though by all means absolutely use it there. What is data product owner versus data owner versus data custodian or how best to distinguish data architect who is most familiar with the data structure from the data governance leader from business leader who is responsible for the data asset. A lot of confusion amongst all the roles. Yeah, I'm really articulate question about that too. So, let's first of all deal with the concept of data ownership. I'm old enough and cranky enough that I simply will not work with any organization that allows parts of the organization to own data, because data is a shared resource and it is the biggest barrier to understanding how in particular data governance works. Just me, there's lots of other people that will work with those concepts but I find that they are the biggest, most harmful concept that can be introduced if you want your data governance efforts just to fail right away I mentioned that state of Virginia here is going through there for third time on it. I won't say whether they use governors not they had other problems around that. So let's take a look at that that ownership concept if somebody really in this on owning something, rather than owning the data you can absolutely give them ownership of the data requirements. From the time the data hits your well established process, until the time the data leaves your well established process, which implies there may be different data requirements for different parts of processing your data as it goes through the lifecycle of your organization, but owning anything other than the requirements is an extremely harmful concept and one of the worst ways of implementing data governance out there. If you don't believe me, there's a couple of good case studies that are written up on it that really get into this. Now, the question then went from there. Data owners, they're going to interact with people who are data governance people. Remember from our slide on data governance we have data governance professionals but we also have data stewards and they're depending on how your organization decides to implement. The bespoke concept that we talk about for being data governance, and certainly there should be a data governance lead in there, but that lead if they're settled with ownership is going to be a big problem. The data governance lead should make sure that data is is appropriately covered that the important data items have somebody in there that takes care of the requirements for them for that particular stage of the Germany that they're going on. Similarly, your lead data architect that you having your organization has to be a key person in the table because if they are correctly reorganizing re engineering the organizational data architecture component by component as I put into the presentation there. Then they need to make sure that those components are guided by some sort of strategy. Yes, I could develop this architectural component in any way, but if I'm told that optimize for low risk. I'm going to clearly take some steps that are going to be completely different from an organization whose goal is speed in there. So we've got three different groups in there the owner, the data governance lead and the data architect lead and they all need to be in there somewhere. I like to tell people that the owner of the organization, excuse me, the owner of the data is the organization itself. So that data belongs to the US Army or to target corporation or the city of Orlando or whatever happens to be the focus of what we're doing in there. And it's really critical to make sure that all three of these people are on the same page so having a data governance roadmap should have hooks into data architecture re engineering as well and data architecture re engineering plans have to be coordinated with the data governance group, all of which of course report up to some kind of corporate management in there as well. A real complicated question I did my best to try and get it if I didn't please ping me back and love to further elucidate on that copy. Thank you. So, Peter, what is the relationship or dependency between data architecture and data strategy. How did they play together. It's almost inconceivable to me that they can't or that they don't play together. And I guess I'm just sort of taken it back by the question. Okay, let's go back to the basics of it data, any type of an architecture is organized for a purpose. I'm sitting right now in the school of business at Virginia Commonwealth universities we have our own separate building. It's co located with the school of engineering. So that's great we've got the school of business and school of engineering co located the purpose of that co location was literally to engage both of these sides of the in this case the university in collaborative projects and I was literally sitting in my office, which happens to sit literally at the corner of data architecture of business and engineering, but also of course data architecture in there as well. And they brought people from the General Assembly and the governor by and said yes this is why we have built this building this is what your investment in this in this organization is for the key to it is all architectures have a purpose. If they don't they're not properly designed. So intent has to go into that I think I did have a couple slides back there that talked about this. If nobody has a purpose than any purpose is the right answer and we know that's clearly not going to get up to our business goals. So start with the very basics, faster, better, cheaper, less risky. Those four pieces are the things that management will pay attention to. So when you're going in and arguing for money so that you can re engineer another data architecture component. You say this will help us because you've told me that speed is the issue, and this current component here is not going to be fast enough for us. As we increase our sales or the number of employees or again whatever the conditions are that go down the road so I hope I really made that point clear. The architecture is way you take purposefulness and embedded in your technology stack. Again, lots of things you could do faster or cheaper, or whatever but you've got to make sure that you're aligned with the organizational strategy. And of course your data strategy is the link between the architecture and your organizational strategy. And the question I'm glad you asked it clearly means that I've got to beef up that part of the presentation and make it better for the next time through and thank you for the feedback. Indeed. So many great questions here Peter so and continuing down the list we've got about 15 minutes left lots of time here. So what terminology do you see most used most effectively to determine to differentiate core demand data domains like customer vendor material from more function specific data domains like finance supply chain planning. The beauty of course is in the eye of the beholder. So, while it's both are going to be important, but you're eventually going to be able to say, Okay, I took sales force calm data, and I improved the data overall from a, let's just look at a quality measure that said it was at 80% and I moved it to 85%. Well without anything else happening in our organization sales have gone up by 15%. Again, you'll have to get these numbers for yourself and find out. So there's clearly a relationship between improved data quality and improve sales here, and everybody understands that so a really important part of all this is communicating these components out to everybody else so that they understand this as well. In order to do that. It's just so important to make sure that you have the ability to articulate these things and if you have trouble articulating it. So there are data scientists are data engineers and data architects tend to be not as as articulate as perhaps they should be, but you can send them off to training classes go through some of the wonderful data diversity events that you run Shannon and things like that to get some training in there, and you'll find out it's not that they're incapable of it they've just never been told, it's part of their role. It's kind of like learning. I did when I learned linear algebra I learned how to do it but it was slow and tedious, you know you're multiplying matrix variables back and forth and all this sort of thing. And I sat down for my first test on it, and they called time after three questions and there were seven more that I needed to do. Oh, I not only needed to learn how to do matrix algebra I needed to learn how to do it rapidly. Right well that became a requirement on their same thing here. This purpose is the thing that's going to help you in your organizations, focus in on these areas and get to where you want to be on this and if there is no articulated purpose, or if nobody articulates it even if there is a purpose is a problem, are it people have not been trained to understand that they need to be understood by everybody else. I was lazy when I was young. I used to say oh yeah they beat me and I'll get around to fixing the main frame when it needs to get fixed on that but you know nobody else knew it well at this point, lots more people know we can't pull that old stuff that we used to do. And so it's really really very critical to make sure that people are able to articulate this, which, again, managing data with governance works really well from a rhythmic perspective. It works just as well managing data with informed governance if that's what you need to have in your organization, but get everybody on that same message, so that then they can realize that the other things they do are being guided by the thing that they've been saying all along. Once again great question I think that was really insightful. We need so many great questions and we're going to get to as many as possible here. So how do you keep data governance, quote unquote real data governance can sometimes be seen as the policeman that no one wants to engage with, especially if it is a separate team, because they will tell you to do something that will take longer than you want will cost more and is in the short term harder to do. I hear this a lot. Yeah, and I sympathize because what we've done is we've told people putting in data governance will help improve data. Of course if we told you then it's going to take five or six years before it actually comes into play. Many people are not as excited about it as they are and I'm going to skip ahead here already narrated you guys through this chart one time but what I want to get to is this last piece here so we put in place the data governance organization, and this tends to be where the discussion stops, data is improving over time or data is improving as a result of a specific focus. Notice what I've used there is the approximately equal to sign, right, we're not as good at this as we should be this gets back to the articulations and other things here. Data things to happen not to celebrate them because data things happen but to celebrate them because data things happened, and that caused us to sell more to be less risky to be faster to be higher quality, whatever those drivers are. The more your teams practices improving this, the more meetings they'll get invited to the more appreciation there will be as people go through this again it's just very very critical and that right hand side of that diagram to not say. Hey, I cleaned up all the a's that were in our data dictionary. Did that result in improved sales. Did that result in decreased costs. Did that result in any sort of improvements in the organization. We have to ask those questions and we have to actually be driven by those questions so once again great great question on that thank you. So, you recommend any certifications on data architecture and other data management aspects CDMP and similar ones. Well, it turns out that data diversity is one of our trusted research educational providers and, and get you guys set up for these at the events that they have coming up including DGI q, coming up in December on this. There's lots of opportunities to go by the way for a limited time to we're also doing this thing where you pay for the exam only if you pass the exam, which is kind of a nice way to try it but the question was about certifications in general. My understanding is that there are a couple of competing certifications I think DGPO has a data governance certification that is understood to be very good. Our own CDMP is is focused in that area of a specialty exam on the governance and what we're starting to see happen is that people are starting to put these qualifications in job racks. So I say yes that certification is becoming more important. I got one the other day though it was kind of interesting from the federal government they wanted somebody who had had their CDMP certification for 20 years. The certification hasn't been around that long so it was kind of an impressive that they thought we had more in there than we do but at the same time, when we see these in a job rack we know that people are looking there to say hey, I want somebody that really does understand this as opposed to just being able to spell the term data governance which is unfortunately where a lot of people are at. So you do have a specific specialist on data architecture. Yeah. Yes. Yes. Yeah, you can be a specialist in addition to the CDMP you can take it further right and become a master in data governance or data architecture. That would be right and obviously here the key would be most people, they go down one path or the other. And that's one of the things we're trying to do with this particular webinar is to say that yes we should have somebody in the data architect role would love to have them certified we'd love to have somebody in charge of data governance and again have them certified as well. But the two of those folks ought to be best buddies at the workplace right there. They'll be longer there. They see each other once a month that ain't going to work. This is close collaboration needs to happen here, particularly in the storming and ideation phases of reengineering projects. Oh, this also applies 100% to everything digital going on. How are you going to go digital. If you don't have your data straight, and yet I see it organizations after organizations. I go out and buy software and that's going to take care of my digitization initiatives, and I'll meet my objectives and all this other sort of stuff. And it turns out. It doesn't work out so well when you put it in play. Any digitization efforts have just been dumping money down the domain. It's just unfortunate. It really is. Well, we've got another question here Peter we've got about seven minutes left, you know, back to kind of like the KPI is a monetization that you were talking about you know are there any additional key metrics or KPIs to measure the organizations effectiveness of moving the ball on top focus items to know when to move on to more focus items. I realize you have periodic assesses and evolve your strategy. That's a very good question though. Unfortunately, what you're going to have to look for is internally in your organization. So I true story I went to one organization at one point in time to work on their KPIs. And I kind of got a hold of the person who was in charge of it I said so what's going on here and they said well, we have 1400 KPIs. And I said okay I understand what the problem is here there's a lack of focus. You cannot say that 1400 things are critically important in fact saying that 14 things is are critically important is a problem. Three is a really good number to start with. And we'll get you into that process. So taking three items and saying let's just look at what's going on. It sounds completely silly but true story I had one organization at work for for a couple of years, consulting with them, sort of armchair consulting if you will, on this and it wasn't until we had talks for two years that I found out the main problem with the company was that it wasn't profitable. Hello, that's the place I'd start. You know if we don't have enough money coming in there's a limited runway for how much longer this organization is in fact going to be around. So when you talk about key performance indicators what you're really trying to say is what are the things that I can do where the X's are on the diagram that's showing that will turn into dollar signs on the other side of it. And yes there's lots of things that can do it, but what are the ones that make the most difference. What are the things that are happening there and if you're having trouble figuring them out on their own. One of the things you can do is look at any sort of regulatory filings that the organization has those filings are required in most cases by the governing organizations to talk about business objectives, and how the organization is going to continue to meet the mission, whatever that mission happens to be. So it's not a whole lot of fun we call it k one diving in order to do it and it's, they're not so many documents that are fun to read but gosh they sure tell you a whole bunch about the organization. And if you learn to read between the lines of them, you can go back to them and say hey, it looks to me like if you measure these three things better, you would be able to achieve more of your strategic objectives usually the first question I get is, who told you that. Nobody told me I read it in your k one filings ago. Oh, do we say that to the regulators. The answer is yes you have to say that to the regulators. Now if you're not in a regulated business, you can still find out what are the things that are on the C levels list. If you have a board to find out what the board thinks are the key performance indicators. The board will understand you can't manage using 14 or 1400 key performance indicators, it's got to be a few, and they've got to be able to provide the leverage that you need to have. Maybe we should do one of these on identifying KPIs Shannon that'd be an interesting one. Indeed. Because we do you know we get those questions a lot. So we got a final question here and so we can fit in the last three minutes, some data activities take much longer cost more than the business would like it to take how do you keep the business at bay while you build a solution properly. Lots and lots of expectation management. One of the things that happens when you go into an organization and stand up an organization is I've outlined here, whether it's on the architecture side or on the data governance side. It's still going to be working with your legacy environment. Your legacy environment is simply anything that's in production. People don't like to be called that but it nevertheless is a reality that that's how objectively determine what is legacy. In there. It's very important to say like things aren't going to get better right away we're at the bottom of Niagara Falls water is pouring over the falls at a rate of millions of gallons a minute. We're not going to change anything right away but through careful work and careful planning and identifying judicious interventions in there. We can find ways of making this work better for you, but it's going to take some time now. In terms of your strategic initiatives that you have, we're talking to the organization. What are the things that are really important in your roadmap over the next couple of years. And let's try to get in front of some of those projects we can't fix everything all at once. We certainly can't clean all of the data in, you know, by Friday. So we've got to have some sense of bringing this in and saying we're going to give you limited pieces but it will ramp up quickly. And here is how we're going to approach the task. It is a, not a task for the faint of heart. And in fact I was just talking to a Dama colleague just before we got started here Shannon, they said you know I think I'm going to stop doing this because it's just hard work always swimming upstream. And yes, it is hard work swimming upstream but the words are unbelievable when you get out there and see some of the things that some organizations have achieved in all of this. Again, great questions. Thank you everybody. That's great questions. And again just answer the most commonly asked question just a reminder I will send a follow up email by end of day Thursday with links to the slides the recording and anything else requested there. So, thank you all Peter thank you so much for another great presentation. Shannon we will talk again next month if not before. Indeed. And thank you all for being so engaged in everything we do love the questions and comments coming in throughout so hope you all have a great day. Thanks so much. Thanks y'all.