 Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of DataVersity. We'd like to thank you for joining this month's webinar, why your data management strategy isn't working and how to fix it. It's part of the monthly webinar series sponsored by IDERA. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them via the Q&A in the bottom right-hand corner of your screen or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag DataVersity. And as always, we will send a follow-up email within two business days containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now, let me introduce to you our speaker for today, Ron Huzenga. Ron is a Senior Product Manager of Enterprise Architecture and Modeling at IDERA. Ron has over 30 years of business and IT experience as an executive and consultant spanning a diverse range of industries. His hands-on experience in large-scale enterprise initiatives includes enterprise and data architecture, business transformation, and software development. His background provides practical, real-world insights to enterprise data architecture, business architecture, and governance initiatives. And with that, I will go to the floor to Ron to get today's webinar started. Ron, hello and welcome. Hello, Shannon, and welcome, everyone. I'm glad you can join us today. And with that, let's talk about data management strategy. I'm sure a lot of you are seeing varying degrees of success with your data management strategies and programs in your organizations. So we'll take a look through and look at some of the things that you can probably identify with. First, we'll look at information capability in organizations. And basically, this really provides some basis into why I think data management strategies are broken in companies. We'll talk about a couple of industry studies that are out there. I also want to contrast to the types of things you should be doing in terms of looking at data maturity and how organizations kind of compare along the data maturity scale and some of the activities that they do or do not do, depending on what level of maturity they're at. What I really want to address as well is some misconceptions or things that can be misinterpreted that organizations are looking at in terms of things that they latch onto or what they're trying to do for their data management strategy, and just making sure that we're dispelling those myths and making sure that we're going down the right path. Then we'll actually turn it around and talk about how do we actually implement lasting change in things like our data strategies and data management programs. We'll talk specifically about what I call the people problem. We'll also talk about strategic alignment and, of course, architecture and governance is the means to get us there as well. Once we've done that, we'll actually go through a bit of a debrief and just summarize what we've talked about and then we'll open it for questions. So let's talk information capability to begin with. Generally speaking, companies are actually failing in their efforts to become data driven, even though we seem to have increased spend in these areas and increased spend in the technologies that we're actually using to pursue these. This study came out earlier this year in February by Harvard Business Review, and what they actually identified is the number of firms or percentage of firms identifying themselves as being data driven is actually declining. Over the last three years, we've dropped from 37% in 2017 down to 31% this year. And while that 7% may not seem large, it's actually a fairly disturbing trend, especially when you look at the larger organizations that are typically implementing these types of initiatives, and it was larger organizations that were the subject of this study. Another study that they happened to reference is another one that was done by new vantage partners, which was called the 2019 Big Data and AI Executive Study, and some very interesting findings there that are consistent with other things that we've been talking about in the past as well. 72% of the participants have yet to forge a data culture in their organizations, and that means a culture that's really focused on what data can do for the organization, data quality, and making data the lifeblood of the organization on a day-to-day basis rather than treating it as something separate. 69% very similar in number. They don't have a data-driven organization, and 53% state that they're still not treating data as a business asset. It's just basically being viewed as a byproduct. 52% are not competing on their data and analytics, and what that means is they're not getting any competitive advantage against other organizations in their industry by utilizing and getting full use of the data and analytics capabilities they have in their organizations. A very telling statistic is that 93% of those respondents say that people and process issues are the obstacles that they're having trouble overcoming when they're actually trying to implement these data management principles and practices. The difficulty of cultural change has been underestimated in organizations. 40% identify it's a lack of organizational alignment, and we'll talk about strategic alignment a little bit later on. And also 24% really cite cultural resistance in the organization as one of the leading factors contributing to the lack of business adoption in the organization and the data strategy as a whole. We need to become much more serious about this, and we really need to address the human side of things rather than chasing technology if we're really going to start driving the meaning benefits out of our business strategies. What I've seen him in this study is really tells us that we're kind of in a bit of a spiral dive here. We thought we were doing a little bit better, but now we're actually seeing a decline in organizational capabilities, and that's something that we really need to address. Another study that I've referenced before was the 2015 PWC Iron Mountain Study, which was called Seizing the Information Advantage. A few points here is, again, very consistent with this other study that just came out this year. Very few organizations are utilizing information to its full potential. There are deficiencies in technical capability skills and lacking a data culture in those organizations. We've heard that phrase on the previous study as well. A lack of investment in value driven information strategies in the organizations. And again, very few of those organizations really understand how to derive maximum value from the information. And again, that really is going to erode corporate value if we don't correct that. So we kind of pulled out of that spiral dive, perhaps, but now we've actually crashed and burned on the runway because we still are not executing. I'm going to do a follow on slide here just very quickly. And those of you who have seen my webcasts have seen this before, but I'm going to go through this one very quickly. And this is kind of a follow on from the PWC study. And this really looks at a couple of ways that categorize the organizations. They call the misguided majority, 76% of the respondents that they had in their studies. And here's some things that they saw that they had in common. Many companies were informed but constrained in how they could implement their data management, while other ones were uninformed and ill-equipped to do so. A key indicator here was that data was seen as a byproduct or taken for granted. And that ties in with that other study where they said organizations were not recognizing data and information as a corporate asset. A low comprehension of the commercial benefits really means that you're not utilizing and managing your data properly. You really need to look at it as, like I say, the lifeblood of your organization. It's something that you can leverage for competitive advantage to really gain traction in your industry. Some companies were constrained by legacy approaches to the way they were doing things. We've all heard this before of this is the way we've always done it. We need to knock down those barriers and excuses and really start to adapt to doing things in new ways to really take advantage of the information. Others are constrained by regulations as well, they're in highly regulated environments, but even so there are ways to actually utilize the information to full potential. This is a telling when that is weak analytic capabilities in those organizations, or potentially companies may have had strong analytic capabilities, but they were lacking the value focus or focusing on the wrong things to really drive that value. So that really comes down to understanding what the important data is in your organization and making sure that you're aligning your efforts to take advantage of that. And again, a lot of them information volume is increasing. So organizations are becoming overwhelmed by that data volume. We're actually really looking at trying to harness the power of information, but we get more and more information coming into our organizations at any given time. So it is easy to get overwhelmed. The important thing there is to not try to do everything, but focus on what's important and that means you need to be prioritized. The other thing is that organizations that view data as the domain of data architects are really in this larger group. We really need to make sure that we see business ownership of the data and business decision making based on that data. Data architects help to facilitate, but the business owns and makes the decisions based on the data itself. And again, initiatives that are IT led rather than business led is also an indicator that you're in that misguided majority group, rather than really having the business taking the lead and actually driving out what you're doing with the data and making those decisions. This can also be characterized by what we call spreadsheet hell, where you've got a lot of disparate information sources trying to manage by spreadsheets rather than having consolidated information repositories and well aligned data stores in your organization. By contrast, we'll now very quickly talk about the information elite, which is the top 4% of organizations that was surveyed in this group. These organizations were very proactive and active in using things like diversifying their business models based on their data and leveraging the data in their organizations, really focusing on proving operating efficiencies in the companies and also using data to identify and implement new market opportunities for their organizations. They did this through tying in tangible data values, so they had organizational key performance indicators and they were linking the data value to the execution of those performance indicators. If you don't have a scale to measure how you're doing and you don't have objectives to see how you're doing, it's impossible to measure, so setting up organizational KPIs is extremely important. And again, exploiting that data for competitive advantage. You really want to be able to do that to really become part of the information elite. That means going beyond operational data usage and really using it for strategic advantage. And again, we need to have balance in our organizations for anything that we're doing. Obviously, security of data is extremely important, but you always want to balance the security requirements and ensuring that you have the data in the hands of the right people to maximize the value extraction from that data as well. And again, they really adopt a holistic approach. Governance is just part of their normal business. It's not something that they view as separate. It's just ingrained in the structure of the organization and the fabric of the organization. And day-to-day governance is always what is top of mind as part of the concerns that they're dealing with. And again, a well-defined information strategy that is aligned and tied into the business objectives is extremely important and that's what the informational lead are doing. Let's switch gears for just a second and talk about data maturity. The data maturity scales are typically from a one to five. I actually implement a zero on this because I see organizations that are struggling and really have no data maturity and they don't necessarily know where to go, which is what I consider the zero level of data maturity. I've put this chart together because it gives you at least a kind of a qualitative approach to try to assess where your organization may be in some of these different categories along the data maturity scale. The interesting thing as well is when you're measuring data maturity, it's virtually impossible to be a one or a zero in one category and a five or another. So as you actually start to move up the data maturity scale, you'll actually see that things are actually fairly closely imbalanced as you're moving through these different categories, where one or two may be at like one cell ahead or behind, but generally you're moving along this axis in unison with these different areas. So let's look at things like data governance as an example. Low mature organizations do not have data governance. Then as you start to grow, you'll see things starting in on like at a project level to get started with data governance. Eventually you may have a program level, the division, and ultimately you'll be at enterprise wide and that's where you want to be to make sure it's ingrained in the organization itself. Data governance is not a project, but it is a place that a lot of organizations start to get going on it. Same type of thing with master data management. At the low end of the scale, you see things like no formal data classifications, whereas at the far end of the scale, you'll actually have moved evolved through things like having fully integrated master data with master data management repositories. You'll have a key focus on data management services, and you'll have things like data stewards and stewardship councils in place to make sure that you're always looking at that data and making sure that it's taken care of. Same thing with data integration. Ad hoc point-to-point interfaces is typically a characteristic of low data maturity, which sometimes some of us call the integration hairball because you've got all these interfaces going all over the place. Eventually you start to get to a point where you're looking at common integration patterns, common technologies, and those types of things, ultimately through things like middleware and enterprise service buses, and really having data integration built in with things like service-oriented architecture and that type of thing at the top end of the scale. And again, data quality. You may have siloed, scattered data in your organizations and immature organizations, but then as you move up that scale, you're recognizing and doing something about those inconsistencies, data cleansing. When you're in a managed organization is your cleansing consumption, but what you really want to do ultimately is you want to build that data quality into your practices at point of capture of the data rather than trying to cleanse after the fact. And that really comes through having a full data quality management practice baked into all your processes. When you look at general organizational behavior as well, at the bottom of the scale, you may be unaware or you may be denying that you actually have a data management problem. As you're moving up, you'll see things where you start to become somewhat reactive, but only at the top end of the scales when you actually achieve some stability is where you actually understand the level of data maturity. And when you're at an optimized level, you can be very predictive about understanding what may happen with the data or what's going to occur just because you're so used to dealing with the data on a day-to-day basis. When we look at organizations as a whole, there are also some very high level indicators of this as well. If your primary IT focus in your organization is focused on technology and infrastructure, you're very likely to be at the low end of the data maturity scale, but if you're focused on information and strategic business and enablement, you're more likely at the higher end of the scale. Part and parcel of that is looking at things like risk and value generation as well. Low data maturity is high risk, whereas high data maturity is low risk. And the flip side of that is if you're at the low end of the scale, you're generating low value, but you're generating high value if you're at the high end of the data maturity scale. So again, and I'm talking about value in terms of your business output and business throughput as well. So we're talking about, again, aligning to those organizational KPIs and driving real business value from your data and utilization of your data in your organization. Let's now look at some misconceptions or things that could be misinterpreted about things as well and things that you may actually be doing and sabotaging your data management strategy in your organization by looking at some of these behaviors. First of all, there's data governance. I still hear too often that people think they can go out and buy a solution, implement it, and now they've implemented data governance. There is no easy button for data governance. You can't buy it, so you really need to stop it. People need to get over it and you really need to roll up your sleeves and get ready to do the work to fully implement a data governance program. As we look at the DIMBOK wheel on the bottom right there, there are a lot of different aspects to data governance, encompassing everything from data architecture to modeling, security, data integration, data warehousing, metadata management, and data quality just to mention a few of them. You can't just go out and buy a solution that's going to do that for you. You really need to focus and prioritize your efforts and focus on the right areas to get the maximum benefit out of data governance. It's also not a project. Like I said, on a low-data maturity organization, you may start governments with a project, but you really need to have it baked into your organization as a whole. Governance is hard work, and you need commitment throughout the organization. You need executive sponsorship to make it happen, and it really is a balanced approach. You need to focus first on the people that are implementing it, the processes, the technology, and you need to instill that data culture to make sure that governance really will work. This next one, I like to call cloud or judgment. Again, there's a very high rate of adoption of cloud. In fact, if you look at things just this year, if you look at just database deployments and those types of things, if you look at Microsoft, the Azure Revenue, which is in Microsoft Division, grew 73% in Q1 of this year. Basically, that means there are about $9.7 billion overall. When we look at AWS, which is another large provider, their revenue grew 41% to $7.7 billion in the first quarter of this year. That means their annual run rate is going to be more than $30 billion this year. Obviously, cloud is not just limited to deploying cloud databases and those types of things. We have SaaS solutions and other things that are deployed to cloud that type of thing, but there's a misconception out there that, again, I hear this more from business users that aren't fully versed on the technologies, but cloud is being touted as this magic thing, and cloud really is not magic at all. We need to get back to basics and realize that all that cloud really means is that it's running on somebody else's computer or computers or data center rather than on-premise. That also has some implications tied to it. First of all, that means that you're exposed to the Internet. You're able to get to it through the Internet from your data centers. That means it's exposed to the Internet as well. That means that you're responsible for the security and your organization is still responsible for managing it. The provider will provide the infrastructure and obviously allow you to scale up and those types of things, but you have to manage those environments yourselves. Like I said, cloud deployments are on the rise and we're seeing misalignment and mismanagement of those deployments as well. Just last week, I don't know if you saw this article at all or not, this came out of a Cloud Edge article, which is the URL that I'm showing at the bottom of the page, but there was a database out there that has now been deleted but had 80 million account details leaked. That was 80 million households across the US and that comprises over half the households in the US. The cloud database was deployed out there and it required absolutely no password to access. If you could actually get at it to the URL, you had full access to data that was out there. The conclusion that was drawn from this article was they basically stated that put simply many organizations don't have the expertise to secure the data they keep on Internet connected servers. The laps is creating opportunities for exposure of a sensitive data. We're seeing this time and time again. There isn't a week that goes by where we don't see a lot of security breaches. So again, cloud is great. It helps us to scale. It helps us to bring new technologies into our organizations, but we need to make sure that we're fully managing things correctly. Just throwing it over the wall to a cloud vendor is not the way to go. There are other considerations as well about cloud that people often forget to think about. What about your backups? Are those being managed properly? What about regulatory compliance? You may or may not have sensitive data in those cloud deployments. And depending on your jurisdictions, you may need to make sure that those cloud data centers are not in jurisdictions that cannot have, for instance, customer or personal data about your country's citizens. Under GDPR, for instance, there are certain countries that they do not allow storage of customer data in those other countries. So you need to do your homework with your cloud providers and make sure that the data centers are compliant with where that data is allowed to be kept. That not only means the main servers, but it also means the backup servers, and that means a lot of work. Another thing that people tend to forget about, and again, when we're looking at the big vendors, this isn't a likely possibility, but what happens if you have some type of a cloud deployment, whether it's a SaaS solution and that type of thing, and the vendor of that solution becomes insolvent? Are you protected? Have you got the legal contracts in place to make sure that you can recover that data? Or have you got backups of that data in-house because you need to start asking yourself the question if all of a sudden that provider goes away, how long can your organization survive without access to that data, or how critical is that data to your organization? So make sure that you have access to that data, whether it's on-premise or whether it's actually kept in the cloud environments as well. Data modeling and data science are not the same thing. I hear a lot of misconceptions about this where sometimes organizations say, well, we're not data modeling, we're doing data science right now. Or business users think that when they hear data scientists talk and they talk about modeling and data science, they think it's the same thing as data modeling, and they're two totally separate things. When we talk about data modeling from a data architecture point of view, we're really talking about managing the metadata, the entity relationship modeling, including conceptual, logical, physical, data flows and lineage and those types of things, and really understanding how the pieces of information in our organization relate together. When we talk about data science, data science uses models as well, but with data science, we're not talking about the metadata, we're talking about the data content. So when we're talking about modeling and profiling there, we're talking about statistical modeling and analysis, including things like correlation, regressions, looking for patterns in the data, and we're looking at trends and algorithms that we're utilizing in the data as well. We're really talking about data visualization and how to see the correlation of things in the data, and data scientists have a major focus on data cleansing as well. Again, one is not a substitute for another, we need both, and in fact, you need the data architecture and modeling to really give you that playing field so that you can properly implement data science by making sure that you have a good data architecture in place to then take advantage of that in your data science initiatives in your organizations as well. I don't know how many of you were at the Enterprise Data World Conference a couple of months ago, and there was a interesting statistic out of Michael Stohmbacher's keynote, and he was basically talking about data science. Data scientists spend about 90% of their time finding and cleaning data. Then they spend 90% of the remaining 10% checking the cleaning. That leaves 1% overall to actually make decisions based on the data that they're finding. One thing that we need to stop doing in our organizations as well and kind of stop this confusion from arising, that actually kind of drives me crazy in our industry. Quite often we invent new buzzwords and acronyms for things, but then we also use an overload terms like data model to mean totally different things. So in this context, sometimes people are talking about data model and we're talking about the former, whereas in a data science context, people may be talking about data model but they're really talking about the statistical modeling. So we really need to make sure that we're clarifying our terminology and making sure that we're talking about the same things, particularly when we're talking about to our business users because they are going to get confused. Let's talk about machine learning as well. We see, again, from that earlier study that there's been increasing investment in not only big data but also mean machine learning. Again, machine learning is not a substitute for data management. We use machine learning to go out and find things. Let's talk about a definition of machine learning to start. Machine learning is a branch of artificial intelligence and what it really is described as systems that learn from data so that you can make predictions. Based on those predictions, the machine learning can then act autonomously or semi-autonomously, in other words, make recommendations that actually not pull the trigger on those recommendations in response to what it has learned from that data. When you look at that, it means it can eliminate the need for someone to continuously code or continually be manually analyzing the data to solve a problem or make business decisions. However, to be able to harness machine learning, you need to have sound data management and you need to have a high level of data quality. It's not something that you do instead of data management and data quality. High level of data management with high data quality is a prerequisite to make this work. Thomas Rebent of Harvard Business Review has this quote. He says, if your data is bad, machine learning tools are useless. I have a different quote on this. I basically say if your data is bad, machine learning accelerates the garbage in garbage and I don't cycle. You simply achieve disaster faster. Again, if you're turning things loose to automation, but the data that you're feeding that automation is making decisions on bad data, you're going to have very bad results. So again, we need to take all of this with a grain of salt. Machine learning is great, but we need to have the proper discipline in place before we actually start to utilize it. The other thing is don't take expert reports and opinions at face value. Some of them are great. They're a great source of information, but again, be very critical when you're reading any reports, opinions, and those types of things. They're not necessarily industry-wide consensus. In case you're not aware, most of those studies can often be biased. And many of them, especially things like industry rankings, are often paid to play. In other words, they rank the vendors that actually subscribe to their services and those that don't subscribe to their services, they may not rank at all. So when you're reading these types of things, don't bet your company's future on a recommendation that you see in one of these. And all I'm really saying there is do your own homework, make sure that the types of things that you're considering are aligned with your organizational needs. And again, even if these studies are expensive, that doesn't mean they're worth what you're spending on them. You always have to make your own decisions based on your own requirements that are a fit for your own organization. I had to laugh and I had to share this one because I looked up things like Expert, and I knew the first one, which X is a has been inspired as a drip under pressure. Urban dictionary has a very cynical view of this and it's quite funny. They also say an expert is anyone with a blog or they also talk about experts as being a contract liar. And they basically do that in the context of experts that are brought in as expert witnesses and court cases and those types of things. I think it's kind of funny, but again, all I'm really saying is just beware the expert opinion that you're reading out there is really a fit for your organization. And now just kind of a catch all. Just don't do these types of things. The cartoon on the bottom right is something that I've used for a number of years in different webcasts, and it really is people trying to solve a problem. And in this context, they didn't really know what big data was, but everyone else was doing it, so that meant they had to do it as well. And all I'm cautioning against is don't chase the shining ball or the next big thing just because everyone else was doing it. Evaluate it carefully and utilize those things that will actually bring value to your organization. I call this strategy by InFlight Magazine where you're just being reactive and you hear about the latest, greatest thing and you have to choose it with your organization. Other words forward are chasing the shiny ball and other things. So we need to make sure that we're guarding against that and have a well-founded reasons for actually chasing the things that we're doing, whether it's things that we're trying to implement from a procedural point of view in our organizations. Again, the new technology or trend isn't the solution to everything. Also, buyer beware. If something's touted as a replacement for all of your existing technology, run as quickly as you can in the opposite direction. Technologies are incremental and if something was good for everything, then everyone would be using it. There is no silver bullet. The only thing that silver bullets are good for are werewolves. And again, let's stop using the big butters words. If we use the term big data, I think most of us in the industry know what it means, but it could be a confusing term. We need to deal with data, whether it's big data, small data, metadata or whatever. Data is data and we really have to basically focus on data regardless of its source, regardless of the volume and those types of things. And another term that I personally don't like is digital transformation. You get 20 people in a room and you'll get 30 different definitions for what digital transformation is. Digital economy now, every organization is using some form of digital if not the so far behind it, the thinker ahead. So digital transformation has really lost its bite as a word because it can mean so many things to many different people. So let's focus on what the specific implementations are that we're talking about. So how do we overcome these misconceptions and how do we actually start changing behavior in our organizations and the people? First and foremost, and as we saw from those earlier studies, it's a people problem. We're probably aware of Tony Robbins whose self-help guru has been around for many years. So let's look at a little bit of the wisdom of some of the things that he has to say about people in general. We really need to overcome human nature and when he looks at things, he says 92% of the 17 million people that try to quit smoking each year fail. 95% of people who lose weight fail to keep it off long-term. 88% of people who set new year's resolutions fail those attempts, and he says that only 10% of the population has specific well-defined goals. Even those that do, only 7 out of those 10, reach their goals 50% of the time. So what we're really dealing with here is a failure to execute, so we need to find ways that we can actually fix this behavior. Obviously we're talking about personal behavior here, but that translates to our organization because our organizations are comprised only of people as well. In many of his books that he's had over the years, he's kind of brought up a basic point, and he says, two forces really motivate people. One is to avoid pain, and the other one is to gain pleasure. I look at this and think of the analogy when I was a kid. If I wanted to go out and play, it's like yep, you've got to clean up your room before you're allowed to go out and play, so you would do that because you would gain the pleasure of going out to clean your room. The other thing is if you don't clean up your room, you're going to be grounded. While you clean up your room to avoid the pain. So regardless of which way you're going, you're basically conditioning the behavior based on a positive reward or potentially avoiding the negative reward when you do that. And incidentally avoiding the negative reward is typically a stronger motivator in people than the positive motivators. So I'm not saying that we have to walk around the hallways and carry a big stick to make sure that we're implementing our data management programs, but what we really need to do is we really need to find ways to manage people so that they actually do latch on to our data management strategies and they're thinking of how and always ingrained in how they implemented on their day-to-day lives. This pleasure pain cycle also causes a yoyo effect on people. Quite often people will kind of waffle back and forth and because of that they actually lose their drive to take any action at all. So we need to prevent against that. It's not a matter of ability, it's a matter of how we motivate people to make long-term lasting change. Change is not assured, it's a must. So we need to make sure that we're doing that. How do we do that in our organizations? We need to put the guardrails up and make sure that we ensure success of our people that are embarking on these things. Organizational change management is critical. It's not enough to say we're embarking on this program. We need constant follow-up. Anything that we put in place we need to manage programs. We need to have defined milestones. We need to have metrics to measure our success and we need continuous follow-up whether it's operational things that we're doing, data management strategies, data cleansing, data quality, all of these types of things need to be measured and we need to implement the change. So how do we do that? First of all, we need to have a defined target. Those of you who have heard me speak before know that I'm a pilot and have a keen interest in aviation which is why you see some of the aviation type of analogies and clip art in this particular slide but something really comes into play here. If I'm a pilot, I have a target. I plan the flight and I fly the plan. That flight plan has built-in contingencies and I'm tracking my progress along the way and I'm preconditioned about how I'm going to react to those conditions along the way. We need to do the same thing in our data management programs and we need to do the same things in projects and other programs that we're running in our organizations. So when we have those defined targets, what do we do? We break it down into small, sustainable changes again rather than trying to do one big thing all the time. We track our progress against those. We plan, we execute and like I said just like the flight plan we incorporate contingencies into that plan and we execute those contingencies. It's a lot easier to think about what may occur and put a contingency in place than trying to scramble at the last minute when you haven't considered what that actual variance may be. Without a CHAMP plan, your chance of success is virtually zero and again, hope is not a strategy. You're not going to get there and just hope your way out of it. You need to make sure that you have something concrete in place. That means measurable metrics. Again, I've talked about metrics quite a bit and we need to implement a continuous improvement approach. Again, evaluate, measure and adjust. Rinse and repeat and keep adding additional changes and small increments until you build out your strategy whether it's a data management strategy or other things that you're doing in your organization. How do we implement that strategy? One of the first things we want to do is we want to make sure that the things that we're undertaking is aligned to our business vision and our business strategy. Again, your organization may or may not have all of these components. If you look at it, some organizations have a broad vision statement. In other words, it's their broad statement about how are we going to change the world. It's their compelling, exciting vision about what we're going to be someday. Other organizations may simply have a mission statement which is kind of like this is how we're going to accomplish that dream or here are the things that we do every single day. Examples of mission statements are something like Google where they say our mission statement is to organize the world's information and make it universally accessible and useful. Whereas IKEA says something like to create a better everyday life for many people. It's fairly open-ended but tied into that, you're going to need business strategies. That means specific goals and objectives that relate back to that mission statement and help you to implement that mission. Now you may look at your organizations and you may say, well, wait a minute, we don't necessarily have a vision statement or a mission statement. But if you look closely enough, you're going to have some types of goals and objectives whether formally written or just kind of known through the corporate culture of the organization that you're driving towards. You want to align your data strategy and the things that you're prioritizing in that data strategy to achieving those business goals. So what you want to do is you want to tie your KPIs for your data strategy and being able to measure how you're succeeding in those business strategy goals and objectives as part of those KPIs. And again, your data management programs and your data management day-to-day operations are really where you're focusing on delivering, controlling and protecting, enhancing that data value and you're always reworking your plans, policies, programs and practices to align and help you achieve that data strategy. Again, it's incremental. You're doing it by chunks. And do it as a continuous improvement. You're never going to be finished. Your business is continually evolving and your data strategy and your implementation of that needs to continually evolve to support those business needs. Let's talk about vision versus vision mission just for a second again. Your vision statement again is the dream. How do you want to change the world? It's your someday statement and it's usually something big, exciting and compelling. Your mission statement is what are you going to do to accomplish that dream? What do you do? Who benefits from what you do? How are you doing it? And how are you doing this every day? The other thing is that you shouldn't be stating your vision statement in financial terms. Your vision statement is what are the financial benefits apart from the financial gains that you want to make from your organization. Peter Drucker, again, a renowned management consultant says the mission statement has to express the contribution the enterprise plans to make the society to the economy or to the customer. And mission statements that express the purpose of the enterprise in financial terms will inevitably fail because they don't really create the cohesion or dedication to achieve those goals. Again, your business strategy is tied into that. Your supporting goals objectives and you want to make those quantifiable and measurable. If you can't quantify it and you don't measure it, you don't know if you're succeeding or not. Let's talk about the metrics. What we want is what I call smart metrics and what does that mean? It's a good way to break down the word. They need to be specific. They need to be specific and target the area that you're trying to measure. They need to be measurable, obviously. So we need to be able to collect data that's accurate and complete to ensure that we're actually achieving those types of goals that we're looking at. And they need to be actionable. What that means is the metrics need to be easy to understand. When you chart your performance, it needs to be clear which direction is good and which direction is bad when you start looking at these values or metrics. And you know when to take action. So what that means is you may have threshold values and those types of things. As an example from a business perspective, you may have something like a KPI that's inventory turnover. In other words, how much you're turning over that inventory or how often you're going through your stock every year if you're a retailer or something like that. You may actually have thresholds like if you say you drop below four turns a year or below three turns a year that you need to take some type of action. So basically building in thresholds as well as tracking the trends of those metrics is very important. They need to be relevant. Quite often people try to measure everything. Start small and then work from there. So start with small or basically a small area where you know you have relevant metrics and then grow out from there. If you start to track too many metrics about too many things, you're going to confuse yourself. Start using a few and then build out from there. And again, timely and that means your data needs to be timely as well. Data six months after the fact isn't going to help you. So if you're trying to evaluate metrics that are actually dealing with your day-to-day operations, you need that information as quickly as possible so that you can react to it while you still have a window that you can make a change that is actually going to be of some benefit. If the data is too late it's no longer actionable so the fact that you're collecting it really hasn't helped you. So how do we talk about these things and now tie back the data strategy? First of all we want to have information governance and a governance oversight body that's comprised of all key functional areas of the business. It needs to be supported by your senior leadership. It needs to be owned by the business not owned by IT. Data is the domain of business. The business owns the data. They own the decisions that are made by the data. So again, while we help with data strategy from a data architecture point of view we really need to have this data strategy owned by the business in roles like the CDO office and those types of things. We need a culture of evidence-based decision making in the organization and we need to view information as a valuable asset in the information. Obviously we need to balance that. We need to protect sensitive and valuable information and we need to secure access to only those that needed to make those decisions. Data needs to be fit for purpose for analysis, interpretation and visualization. And again, we need to base this on a sound data architecture and enterprise architecture. That's the means to the end. We cannot do this without good data architecture and enterprise architecture. That means things like data modeling and data architecture to really help us understand the data, how it's created or basically how it's related and the business process modeling in this example so we know where and how data is created, how it's used and those types of things. Let's talk about the enterprise architecture and data architecture of this foundation right now. I'm going to go through this very quickly. This is kind of our view of the world. Many people talk about the four pillars of enterprise architecture. Our spin on it is that data architecture needs to be at the foundation of that and it supports the other aspects of enterprise architecture. The central pillar of business architecture, flanked by application and technical architecture to help you deliver your solutions by having a balanced approach to all those. That's how you enable your enterprise and that's the foundation or that entire structure is used to help you implement governance, not only data governance but process governance as well. Let's look at how we try to do these types of things. A lot of people when they're focusing on data management initiatives are looking at metadata repositories only. That means you're doing things like metadata import from your different data sources. You may have a metadata catalog but you may not have the visual models but you're doing things like matching, text search and look up and those types of things. It's not enough. I call that the flat earth society because you don't have that visual tie-in to help you do things. I had to laugh at this when I saw this. It's like the flat earth society has members all around the globe. Just think about that for a moment. But what we really want is we want a fully integrated approach to our data management. What we want is a fully integrated governance library. That means you want your visual models and your linked metadata. So data models, process models, visual data lineage, all your metadata and link glossaries, regulatory policies and reference data all tied together so that you can really manage your business. Obviously, this is becoming more complex. We saw this in some of the studies earlier where people are grappling with the volumes of data. When we look at this particular example where we work from left to right on the bottom part of the diagram, we have all kinds of different data sources that we're trying to ingest into our businesses. We're landing that information into things like raw transient stores, whether it be no SQL stores like Hadoop or those types of things. It can also be relational databases. We have a number of data science sandboxes or experimental areas cropping up. Eventually, we're working with that data. We get to a point where we've done some work with it and now we know what our raw approved data is. We need to get to a point where we're making business decisions where we know what the trust of data is in our organizations, which is often scattered across multiple data stores augmented by things like master data management stores, ultimately refining information to the point where we get to the far end where we're starting to drive things like self-service, analytics, and reporting. You cannot manage all of this unless you understand that information and how it's all tied together. What we really need to do to drive that out is that's where our models come in, data models including conceptual, physical data models, things like enterprise models that give us that focal point about all the information in the organization means and how that ties back to your implementation data models. Basically enterprise data dictionaries and obviously this includes things like our dimensional models, our data lakes, and all those types of things. We need to tie all that together and augment it with business glossaries and those types of things. From our data models, conceptual, logical, physical models, including our dimensionals, our enterprise models, canonical models, which is kind of a derivative of the enterprise model, service-oriented architecture, and those types of things. And again, visual data lineage. Tying into where is the information coming from? How is the information being transformed on its journey through the organization? And what are the sources and targets of that information? Naming standards, things like governance attachments or basically governance metadata is all tied in and we can originate that at our data models. And again, tied into our metadata repository with our business glossaries. Modeling answers multiple questions. It helps us to understand what's important, where it is, and your data can be many places for the same concept. Where did it come from? How is it actually used? And when you rely on business process and business process modeling to help us do this, what's the chain of custody of the information on its way through the business? It can transit to multiple systems and it can actually have multiple origins as well depending on where it came from. What are the business rules that act against that data? Governance, how do I identify private information along those data stores? How long do I keep information? In other words, retention policy. How do I classify my data for master data management? What's my level of data quality? Is it picked for purpose? And what changed on the data and why? These are all questions that we need to be able to answer and we need to tie it into our modeling and our overall data management strategy. This is an example of a high level data model and I'm not going to dwell on the details here, but it's not just about entities and attributes and the characteristics of that data. It's also about things like the data dictionary with definitions tied back to our business glossary. So that's a definition of the top cell. Things like classification metadata and things that I've talked about on the previous slide. What master data class is it? In other words, is it master reference transactional? What's the level of business value of the data? High business value data is going to receive higher attention and is going to be prioritized higher for things like data cleansing efforts and making sure that that data is usable. What's the retention period of that data? Where does the data originate? Is it internal? Is it external? Those types of things? How volatile or stable is the data? They're kind of two sides of the same coin. Who's responsible for it? And also tying into things like what's the level of privacy and what's the security impact of these data? We need to track these this type of information as part of our strategy. Going back to data maturity that we talked about at the beginning. Data maturity is tied directly to data model utilization. Typically what we'll find is companies that are at a low level of maturity may not be doing data modeling or they may be doing it after the fact just for documenting or basically doing things like reverse engineering from physical databases to understand what they went out of there. As you drive through the evolution of those five levels of data maturity, you're going to find that those data models are baked into what you're doing including things like enterprise models, data lineage models all tied together with your governance metadata, ultimately to the point where you have fully integrated modeling, glossaries, metadata, and self-surf analytics all tied together. Process modeling. I'm not going to dwell on this, but process modeling is extremely important. It gives you the context of how your data is being used and it is that central pillar of the architecture. We want to get to a point where we understand not only what the data is, what business processes act upon it, how it's created, how it's utilized, and where it's ultimately destroyed or actually discarded in our organization. The way to do that is to model and understand the key business processes in an organization. And finally, tying this together with all of our other metadata in a data governance library. So we have things like our terms, based on our business terms and glossaries, things like our governance catalogs in terms of the different governance regulations that we're subject to in the policy statements for those governance, and tying in things like master data management catalogs all in a centralized governance library that we can link all of these concepts together. Things like glossaries and terms where we have meanings and we can even get into how you calculate them and those types of things. So we have a standardized definition of how things are utilized throughout our organization. Taking things like those governance policies that I just mentioned. So here's an example where I have a governance catalog, and these are the regulations that I happen that I may be subject to like GDPR, HIPAA, PCI, those types of things, separated out and kind of decomposed into the different areas, and each one of those I have policy statements that I have broken down so I can tie it back to the data artifacts that it ties to. Same thing with reference data sets, being able to tie in things like reference data, master data management stores and tying all of that information in an integrated fashion. We're coming in a final approach here for our discussion, so I just want to kind of review some of the things that we're talking about. Again, where we started on this is that information capabilities and organizations is still poor and it's actually declining, so we need to address that. Despite the investment in AI, big data initiatives, and chasing things like the shiny ball, we need to get back to basics and put the principles in place before we can take advantage of the technologies. To do that, we have to address the human side of the equation, not just chasing the technology, and that means we need to address the people and process issues in our organizations first and foremost. That means organizational change management for all of our data management initiatives, and we need to overcome those misconceptions and face the realities. There are things that are important, but we need to make sure that we're rolling up our sleeves and doing the work. We can't buy these things, deploy them, and expect success. It's hard work and it's a day-to-day hard work that never ends. Data governance, like I say, is hard work. Cloud deployment doesn't push the responsibility to someone else. You still need to manage your own environments. And it actually becomes trickier because, again, whereas on-premise, you may have things behind a firewall not exposed to the Internet. When you have cloud deployments, you may be exposed to the Internet so you need to make sure that you have the proper security in place to do that. Don't confuse data architecture and modeling with science. Data architecture is foundational. It talks about how the information fits together in our organization. Data science deals with the data content to draw conclusions and profiling such as regression statistical analysis to help drive the decision-making of the data content itself. Machine learning is not a substitute for data management. Again, it's something that depends on sound data management and a high level of data quality in order to be able to work. And, again, don't take the expert rankings and recommendations of face value. Do your own homework and do what's important for your business. Don't follow the crowd. If you follow the crowd, you're going to be like the lemmings falling off the cliff. You really need to make sure that you're making the right decisions for your organization. And, again, don't chase that shiny ball of technology. Implement things that are necessary that are going to drive business value for your organization. And, again, eliminate the ambiguous buzzwords, especially when you're talking to business users. Use business terminology wherever possible and be very concise and clear in your communication to your business users. How do we implement that lasting change? We align the data strategy with that corporate vision, mission and goals because that's how we're able to measure it. We establish our metrics based against those corporate goals as well. And those quantifiable metrics help us to measure success not only of our data management programs but of our organization as a whole. We use enterprise architecture and data architecture as the foundation to help us deliver all of this. We need to make sure that we have fully integrated data governance and that means models, metadata, glossaries, policies all tied together so we can actually kind of see it from end to end and see how things tie together. Again, this is all about hard work. Roll up your sleeves but be careful. Don't take on too much at once. Start smaller and grow into it. Be realistic and honest about your starting point. If you're at a low level of data maturing in your organization, be realistic about that and plot out a strategy about how you're going to move up that maturity curve. Don't try to boil the ocean. Focus on the business areas that are going to have the best returns for you and grow from there. And again, it is hard work to remember to celebrate your successes along the way and then rinse and repeat and keep going as you keep growing it out in other areas. That's all for the formal presentation so I'll now open it up for questions. Ron, thank you so much for another fantastic presentation. Always great to have you with us and just a reminder and to answer the most commonly asked questions. I will be sending a follow-up email by end of day Thursday for this webinar with links to the slides and links to the recording of the session and anything else requested throughout. So diving in here, Ron, is the data strategy data management going to be almost similar across profitable companies mainly about having a good data quality of vendors, materials, customers, employees and financial related? It really depends on your organization and what type of industry you're in. So, for instance, again, vendors, customer data, those types of things, typically those types of things will come into play and they're going to be some of the master data management areas that you want to make sure that you have higher data quality. But again, all those for-profit organizations are different. So if I'm a retailer I may be focusing on more on things like product mix and also things like if I'm brick and mortar my stores, my product assortments in the stores delivering the right types of products to the right customers in that particular geographic market or other market segment depending on what it is. So a lot of different things come into play there from a retail perspective. If I'm something like a manufacturer I'm going to be focusing on other things as well. I'm going to be focusing on things like bill of material accuracy for the components that make up my products. Things like scrap factors, things like basically my capacity and my plant floor and those types of things. So it's a different set of data that comes in. If I'm something like mining, again that's for profit, everything there is about capacity and utilization of the equipment. So those are the types of things that you're going to focus on very much. So again, depending on the type of industry that you're in, you're going to have some key focus areas that are important to that business and that's where I would start but then I would grow it into the other common areas as well. How do you quantify the data? I actually do a full presentation on that that I've done previously but what you really want to do is you want to tie it back into your business. So when you're tying it back into your data quality you want to do things like, and I'll take that inventory turnover example that I talked about earlier, let's say we're focusing on data quality to understand again from that manufacturer's perspective which ties into things like the bills and materials and those types of things which ultimately impacts my inventory levels basically how quickly I can deliver product and all those types of things. What I want to do is I want to choose business metrics that will allow me to establish whether I'm succeeding or not. So what am I going to do to do that? You can typically look at it in terms of if I'm increasing my data quality I'm going to be doing one of multiple things. I may help my business by decreasing my costs. I may increase profitability or those types of things or I may be avoiding costs that I would otherwise have incurred if I hadn't done this which is also still a savings. So what you want to do is you want to evaluate that. So again if I'm decreasing my overall inventory levels that means I'm doing things like decreasing my day to day carrying costs of that inventory which is basically the interest and other costs that I pay by investing in that inventory rather than being able to invest elsewhere in my business. Or if I'm able to open up new market segments because I have increased my frequency of delivery or I have a competitive advantage over my competitors so I'm delivering in a week rather than a competitor that delivers in two weeks that gives me a competitive advantage so that may allow me to expand my markets. So then I would attribute things like the percentage of revenue that I've gained by being able to expand into those markets at the expense of my competitors. What are the things that the business is trying to do and then try to tie the quality of data back into how it helps you satisfy those business objectives? I love it. We get that question a lot so that's a great answer and very helpful. So Ron in your opinion what percentage of organizations are doing change management well to enable them to be true data driven businesses? It's a very subjective answer but I would actually say based on the results that we're seeing in companies that are not instilling a business culture I would say probably 5% or less. Terrence, who does change management sit with in a data driven organization CDO, CIO, HR? That's a fun question because now you're going to spark my debate on the whole thing about the fact. This is my pet peeve. It drives me crazy that when we look at the value chain of data that basically turns into data that turns into information that turns into knowledge. So that would initially make you think that the chief information officer would be the one that's responsible. Unfortunately in many organizations the chief information officer role has taken on a perspective that doesn't really deal with the information that's dealing more with technology and is more akin to a chief technology officer which is why we see the chief data officer role that has been emerging has actually been on the technical side. So to me it belongs in the business because the business needs to drive those business benefits and the way that I can implement that is probably through a chief data officer role. It could be a CIO but only if that CIO actually has a very high level of reporting through the business rather than being as aligned on the IT side as they typically are. Don't know that we have time. Do you think you can answer in just 30 seconds what data architecture is the foundation versus business architecture? Basically I put it as the foundation for all the architectures because we have obviously our data architecture is not only managing the organizational data but it's also managing the metadata of all the other aspects of architecture as well. Business processes exist for a reason and as part of those business processes everything that we do in an organization has a representation in data whether it's representing the real goods and services that we provide. We're representing that in data so we need to tie that data back into those business processes to really get the context of what those business processes are doing what the inputs of those processes are and the outputs of those processes are and that's all captured in data. I love it that's perfect timing that brings us right to the top of the hour Ron thank you again so much for another fantastic webinar and thanks to all of our attendees for being so engaged in everything we do and all the questions just a reminder I will send a follow-up email by end of day Thursday for this webinar with links to the slides and links to the recording of this session and we hope y'all will be joining us next month as we talk about LEAN data modeling for any methodology. Alright thanks everybody Ron thanks again as always have a great day. Thank you everyone have a wonderful day.