 Hello and welcome, my name is Shannon Kemp and I'm the Executive Editor of DataVercity. We'd like to thank you for joining us this month in Salmon of the Monthly DataVercity Web in our series, CDO Vision. This series is designed to give you a round of education on data strategy topics in addition to our annual face-to-face event from which we returned in April. It was a great event. We are already underway planning next year to be held in Atlanta, Georgia. This month, John Lamely will be discussing coordinating your data strategies with Data Management World's Collide. Just a couple of points to get us started. Due to the large number of people that attend these sessions, he will be muted during the webinar. For questions, we'll 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 CDOVision. 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 our speaker for today, John Lamely. As a well-known industry analyst, John is a business technology thought leader and recognized authority in all aspects of enterprise information management, with 30 years' experience in planning, project management, improving IT organizations, and successful implementation of information systems. He is the president and chief delivery officer at First San Francisco Partners. And with that, I will turn it over to John to introduce today's guest or to introduce today's webinar and to get us started. Hello and welcome. Thank you, Shannon, and there is no guest. All you've got is me today, right? My cohort, Kelly O'Neill, is on vacation, so we'll just have me. I'm looking at the attendee list. It's still growing, so my being the sole presenter has not been a disadvantage so far. So we're good to go. Good afternoon, good evening, good morning, wherever. You may be talking about data management worlds colliding today and coordination. And this is very often in these presentations, you get a conversation that is anchored in how things should be, best practices. And this was what works and this doesn't work. Today, the scenario or the story we're telling is a little bit more realistic. This is the way things are and how can you deal with them. So that's how we're going to have our conversation today. We're going to take a practical look at what's really going on in many organizations. And it's really, and we'll see some examples of disconnected, loosely coupled, or coupled EIM efforts. EIM, of course, standing for Enterprise Information Management. A lot of companies will have separate data management areas. They might not even know that. There might be a rogue area. We've had many clients over the years where the investment in data management, such as BI analytics or data quality or even departmental stewardship and governance, has even exceeded the official budget for the official data management or governance area. So, and you have similar technologies or conflicting processes and all of that. What we want to do is be able to coordinate. We're going to take a look at this situation, talk about how to coordinate across the initiatives, coordinate, create across your architectures, and then things that might be poking away around your data management but maybe not directly connected to that. As always, we love to take questions. So if you have any, please submit them. And our esteemed producer, Shannon, will facilitate my answering those the last 10 or 15 minutes of the presentation. Here's the scenario, and we've used this slide before. It's very good. It's pretty practical. And there's a lot of good voiceover to this. We've got all these business needs that are popping up in our data-intensive 21st century. And you can look at all of these little voice bubbles on this slide and see that, of course, these are data-intensive efforts. Some of them might have a process aspect to them as well. But without a doubt, there's a lot going on here with data. As we know, the reality of this situation is more often than not of these 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 9 or 10 bubbles here. Actually, there's 10 of them. Of these 10 bubbles, you might have worst-case scenario, 10 separate data management projects, 10 ways of looking at this. And I'm not talking about a big organization with two disparate divisions where I use the example very often of a large oil company where they have their exploration and drilling, and then they have the processing plants, and then they have the retail outlets where they sell gasoline and oil and Twinkies and have a soda fountain. Those are three entirely different lines of business within one umbrella organization. I'm not talking about that. I'm talking about one organization that sells widgets or offers services of some sort and has these things going on disparate. Of course, we are entering a time here where people are saying, we need to do better than that. One of the big drivers of our work and the expansion of our practice and other competing practices to us is the fact that the light bulb has gone on. But now you're faced with, again, it's the same situation as our objective for today's talk. You've got all these different things. Whether you acknowledge it or not, you're going to have to patch these together in some way, shape, or form. If you acknowledge it, great. Now you want to know how to patch it together. If you don't acknowledge it, guess what? You're going to be forced to patch these together due to the cost of ownership of things. I think that's another driver that we don't talk about much. Just the cost of doing all this differently. I don't care if this drives are cheap. I don't care if resource costs are coming down because we can blend offshore and onshore and blend all kinds of different staffing models and things like that. None of that is relevant. The fact is, when you do things like these 10 bubbles and do them 10 different ways, it gets ridiculously expensive. So we're going to cover three common scenarios. And these scenarios are so familiar that it is scary. It is almost you walk into the lobby of an organization and you can tell these are going to happen. And of course I've used the overused scary slide here because everyone knows that that's a scary thing on that slide. But enough of that, let's move on to those scenarios. First of all, we have an MDM effort. Some type of significant domain, a customer or product, is being consolidated, cleaned up. People are fed up. We send out the wrong bills. We don't know who our customer is, so we're doing MDM. All right, awesome. You also have an analytics effort. You want to do big data or we want to do our third or fourth generation data warehouse or we want data lake or whatever you're talking about. But there's some type of analytics going on. And then maybe somewhere because of compliance or problems with accessing data, you have a data quality effort or a data governance effort. They tend to orbit each other, kind of a binary star type situation here. And that is an effort where someone, a group is saying, we need to do better oversight of data. The regulators say we do. And we're building principles and policies and we need to get everyone around us. Now this scenario is detailed this way. In the MDM area, they're doing nursing and they've read somewhere that data governance is important for MDM. So we are going to have a data governance area within our MDM project. Now what happens there is while that big project is going on and let's say one of the big systems integrators are in there helping do the work with your organization and at the same time the analytics efforts are going over and there's another big contract type firm and they're doing their work too. Of course, in the realm of analytics, someone will also say, well, you know, we need to know where that data is and who's allowed to get to it and we need to build rules around it so we need data governance. So we're going to bring in our data governance people. And now you have coexisting integrators looking at each other across the table, sometimes being friendly and cooperating and sometimes not being friendly and cooperating. Or worse, they pretend to be friendly and don't cooperate. But that's another story. So you've got that scenario. So now we've got, you know, you've got your internal people, your external people and two probably competing philosophies of data governance or data management. Let's take a look at one of the other intersections here, the MDM and data quality. Of course, data quality and MDM, they also go hand in hand and data governance is a required success factor for MDM. These are our critical success factors, but the MDM team, because they're nervous and they don't want to fail, they're going to say, we've got this governance stuff and we have our own data quality thing. Well, the compliance-driven folks are saying, yes, but that is silly. We now have two groups doing the same thing. Again, some of you are hopefully out there just nodding your heads going, that's us. And then we have this analytics data governance quality thing and what we get there is this, do we really need to talk? I mean, the data scientists are going, we've got a lot of volume here. Data quality is not an issue, but the data governance and data quality, people are saying, yeah, maybe it could be. You know, we could have some real issues here, but at least we should just start to talk about things like that. And again, there's three things in this data realm that we talk about in these conferences and in our seminars or our webinars here. And this is a very, very similar thing. So what happens is, you'll hear these quotes at the meetings, we will coordinate our respective efforts. Well, here's the problem with that. It's noble, but it flies in the face of what data governance or enterprise information management is and those of you that have heard me talk before, what does the E stand for in EIM? It stands for enterprise. It doesn't say let's do the same thing in different areas and coordinate with each other. What you do in that situation is the organization is abrogating its responsibility of this data asset management. It becomes a political thing. Again, the scenario plays out that we'll try to cooperate, but push comes to shove. If there's a disagreement, they're all going to do it their own way because they're going to get their projects done. On the other side, the MDM data quality data governance, we have that success factor. We're going to do our own. You very rarely even see a willingness to cooperate. It's a success factor. We don't trust you. We don't want to be on the critical path of another initiative, so we're not going to play nice with each other. Normally what happens there is it gets up to the upper realms and political capital is invested and spent, and some resolution comes up. From my observation and to be really candid, everyone goes off and does their own thing. I mentioned earlier on the data volumes, remove the need for data quality or data governance. There is a constant tension in a lot of the work we see going out there with big data environments between getting disciplined around it and just letting technology take care of everything. The answer is in the middle. Some very telling statistics were in a national publication last week that escapes me. I think it was Forbes or the Economist, but don't quote me. And that is that just 80% of the Fortune 1000 are doing analytics. 5% are up and running. And I can tell you one of the contributing factors to that gap is this failure to manage the data going into these analytics engines and just throwing stuff in a big pile and hopefully somehow through the statistical wonders of massive quantities of data will squeeze out the errors. And it's possible, but not likely. The other thing that happens here, which I haven't had another bullet point, is a lot of organizations invest in data analytics and sophisticated delivery mechanisms of algorithmic or heuristic type uses of data. And within a matter of three to six months of the rollout of that facility, operational and managerial reports are being produced out of your massive, expensive spark, Hadoop, Mongo, whatever, Cloudera stack of stuff. You're doing operational reports. Now, fine if you want to do that, but now you're smacking the realm of data quality and data governance going on there. So you can see this is very typical. It's pretty common. I hope I didn't bore anybody too badly from all of this, but this is very, very common. Now, you could put other projects in here and substitute things, but I think everyone can kind of see where this is going. So let's talk about coordinating across things. You know, we got the problem. The story is a common story. Organizations to review doing data type efforts, heading off in different directions, incurring some pretty impressive costs of ownership, some pretty impressive capital expenditures, and sadly not accomplishing what they could be accomplishing if there was some type of cross effort or cross program coordination. So we'll talk about a process here to do that. First, you have to identify what these efforts are, and there can be a lot of... In our scenario, we just put three common ones, but let's break this down into some more details because no one sees the whole forest for the trees. Not only can we have distinctive big chunks of work, we can have master data management. Sometimes we can have two master data management efforts, or three even, and of course those have to be all wired into other application areas as well. And we have the analytics or the data warehouse or the BI, the data quality, the compliance-driven governance, but we also have all the departmental things. We have departmental production of manager reports. We have the business analyst or the data analyst doing ad hoc analysis or business intelligence at the whim and direction of departmental heads. These are data management efforts that are part of your data ecosystem. Now, these are data ecosystems that are very, very fragmented and very nonfunctional, and that's a problem. Now, the sad part with a lot of these and you have to determine this when you identify these distinct efforts are, first of all, let's list everything that is data related, and that includes three or four business analysts over in some department, maintaining on a departmental survey server, some SQL server, and doing some reports and using some off-the-shelf stuff to schlep the data around and do that. That is part of your data ecosystem. You must account for that. Now, then the second thing you account for is this massive inventory, and this is going to be a lot. You're going to be surprised. Most clients we have when we get in there and start to count this stuff, they are just gobsmacked at how much stuff they're doing and what it's costing them. The other thing it distinguishes is this error of commission or omission? Have they deliberately done this or is it just kind of evolved? Most of the time, fortunately, it just evolves that way. I mean, let's be fair to the various departmental BI areas, the shadow ITs, they're called sometimes. They've got a job to do. A request was put into the data folks or the IT folks. They said, we'll get back to you in six months. That's when we'll be done. And we don't have six months. Bang, they go do it themselves. This has been exacerbated now by renting out some space in the cloud or buying an application. It's software as a service in the cloud as well. Now, so you must distinguish between a reaction to a business problem or a deliberate political move just to control out of some type of nervousness, because when you want to bring these things together, you've got two entirely different trajectories to solve that problem. If it's been something you've evolved into, reasonable business leaders will say, yes, we've worked our way into this corner. You know what? We're not going to beat ourselves up. But how do we work our way out? The other situation where it's deliberate where someone has said, this is my data because I am the keeper of the customer data, for example, I don't want to play with the other kids in the playground, that's an entirely different resolution to that situation. So that's why it's really important to, at this point, take that inventory, identify all the efforts, and remember that includes data quality, data governance, and all kinds of stuff, right? Now the next step, what are the challenges and opportunities within that? Challenges you're going to see, for example, are the aforementioned cost of ownership. That's a good one. There's some ones that we all understand very well, different answers to the same question repeatedly. Everyone has heard that story, okay? You're going to have, it gets even worse, though. It can get even more painful. You have different data dimensions that are slicing and dicing the data in a way that doesn't reflect another functional business area and cannot be used enterprise-wide, and they've been declared at an enterprise-level metric. So you've got that type of problem, too. So those of you've got a lot of the typical data challenges that happen when you start to silo all these different efforts. There's a lot of opportunities, and you have to take a positive look at this. What is going to happen that's good if you start to eliminate these? And I'm not talking about technological conveniences. Oh, we'll have all the data in one place. That really, honestly, who cares? If I'm a CEO, I don't care. If the risks are managed well, I don't care if everyone has their own copy. It's their job done, and it's managed well. So it's not just an anti-redundancy campaign here. The opportunities are in things like workflow and collaboration and looking at common data, but through your different lenses and understanding what those lenses in context are. There's enormous business opportunities there. Everyone in the organization is subject to this type of process. A lot of you are out there sitting, and we could never do this. We could never identify all this and go through the challenges. I'm going to challenge you to think differently, not think politically that, well, we're going to get in trouble if we ask around, or it's not out of our area, or the last time we did this, we got our hand slap. I'm going to ask you to challenge your leadership that tells you don't do that. I'm going to ask you to challenge them why not do that. There is a concept in the world of business called due diligence, and basically what it means is we will exercise the necessary efforts to ensure we're not messing up. It is incumbent upon all of us as keepers of our organization's assets. The concept of due diligence is vital to mergers, acquisitions, financial reporting, regulated industries. It is a core business concept that we tend to overlook around data. You are subject to due diligence if you cash your paycheck. Therefore, I think it's perfectly okay in a polite way to say, we've got all these silos. You've got some people that insist on them. I think we should put the challenge to them to say why is this still good for the organization? Maybe not the proof which I hear all the time is, John, please help us convince everyone we need to do this. You know what? Just as a devil's advocate, I think we should ask them to prove to us why we should keep doing it this way. You want to point out both the challenges and the opportunities. Then you have all these common points. We're going to have common intersections of data and data sources. Now we're into the architecture realm. By their very nature, we've got all these common points. But in the master data area, we're going to have common points. In the analytics area, we're going to have common points. In reference data areas, we're going to have common points. In basic BI data warehouse and reporting, we're going to have common points. In document management, let's forget rows and columns. Let's talk about documents, all right? Which is another realm to be governed. You're going to have common intersection points with other areas. Bring those to bear. These are really important things that people need to understand. It'll start to build your argument of why should we keep doing this. I put an example together of how a typical common operating model for governments and management might respond to this type of environment. I'm going to walk you through it. We have our multiple layers of governance and an engagement model for data management and data governance here. It's divided into the strategic executive tactical, managerial, strategic managerial tactical. That's kind of how it breaks out if you wanted to draw a two-by-two type matrix. Strategically, we've got our leadership and our direction setting. The reason you start there is at the top of an organization, you do not have an infinite number of executives. It's a very fixed, very small group of people. They all have oversight and insight into everything. You don't have a separate executive council for governance and a separate executive council for the major MDM project. They might be different meetings, but it's the same people. So take a look at what they're doing in governance and say while you're doing on the governance committee, Mrs. Executive, do you understand that there is three of these major programs underneath you and two of them aren't talking to the data governance yet? Why is that? Is there a good reason for that or is there not? Within the executive working group where we've got the leadership and your owners or the accountable parties tend to be in the working group, there's a tendency to put business as usual efforts in there and stay away from the big programs. But if there's a big MDM program, if there is a big ERP-type thing still underway at your organization, they should bring those in. That's the dotted box there that says programs. They should be built into your leadership body for your governance thing. Then if we have our local type of governance, the offices and the stewards and all of those kinds of things, and that's where we bump up against data management, first of all, train your leaders in that area to be on the lookout and have a programmatic view of things and go looking for and embracing the programs as well as the departmental type work. Then at the tactical execution level, get your stewards or the equivalent to a steward whoever the hands-on folks are, get them trained up on a program view as well. This is your front line of defense. This is where you'll see problems emanating when there's one thing that someone's trying to exclude from it. So train them up to do that all the while you're interacting with the stakeholders, the PMOs, program heads, and things like that. Again, this is a typical operating framework, and we just kind of laid what's going to happen to start to bring these things together alongside. Which takes us to another topic, which is enterprise architecture. I'm going to stop here because we're at the halfway point, by the way, and I always do this. First of all, I take a little drink of water, especially since my cohort Kelly isn't here to allow me to take a drink of water. And then I also remind you that I am delighted to answer questions as the time permits, and we actually get back to those questions afterwards, too, and we'll email you answers if we don't get to them. So please submit. There are some questions coming in here, and please submit as many as you'd like, and we will get to them one way or the other. And we really do appreciate that. So let's move on then with coordinating with enterprise architecture, which is an interesting area, which also comes into the mix here. Let's see here. Anything sound familiar? We have the architecture versus EIM. We have, is enterprise architecture part of EIM? Or is EIM part of enterprise architecture? Who's in charge of that? EIM, enterprise architecture in many organizations is viewed as royalty. They influence an awful lot of activity. There's other organizations where, sadly, enterprise architecture is viewed as some type of, while we were told to have this area, and there they are and nobody really knows what they do. And that's not cool either, because this is a very, very vital role. It's very, very significant to a modern organization, and it's really significant to what we're talking about here today. We've got an awful lot of terms and technical buzzwords cast about our industry. I mentioned MDM analytics quality and all of that. A lot of times the enterprise architects understand these from a conceptual level, but not at enough detail to understand how all the bits and pieces should fit together. The enterprise architects also have a lot of other aspects or components of the enterprise to work on, such as communications, applications, a lot of wires and pliers type issues as well. Now we'll layer on top of that the fact that you've got all these maybe business areas doing their own thing and doing something like, well, we're doing this project to clean up our customer data, and we're doing that departmentally because we didn't have time to wait for a big project from IT. Well, fair enough, but what you're really doing is MDM, and you don't know you're doing MDM. So we're kind of kicking these terms around, which is really cool, but we need to come up with an area that understands terminology and all the moving parts, and now all the moving parts fit together, and that's where enterprise architecture actually comes in. There is a powerful, powerful support network in this area if we're dealing with these disparate data management efforts. If you look at what enterprise architecture has in it, they're looking at, there's always some type of process aspect to enterprise architecture. It's either workflow, or if you're thinking in terms of John Zachman framework or a TOGAP framework, there is the flow or the process way of things. There's always oversight. Data governance isn't the only type of governance. There's all kinds of other governance, right? There's applications, and we don't talk about apps very much because we tend to look at our data efforts as programs and projects, but the ongoing trend in the implementation of code is more of the app and the connectivity and the service type aspect of those things. So that's important. The technologies that are in there and then the organization aspect to do that. You want to have... there are overlaps between EIM and enterprise architecture. I think that's pretty obvious, but when's the last time you sat down, if any of you are in information management, when did you have a half-day or a full day? Just sit down, coordinate, and sync up with all of the enterprise architecture and get a sense of what some of that was going on. Some organizations will answer that right away. Most organizations go, wow, we really haven't been that proactive in communicating. We're waiting for them to tell us things, and the fact is I think you need to be a bit more proactive in that area. There's a lot of overlap between the two. Some of you might want to challenge me on that, and that's perfectly okay, too. We could deal with that in the questions and answers, but I do think enterprise architecture is a vital function in a modern organization because of all the moving parts and because almost all moving parts have a technological aspect to them now. But I also believe firmly that if there is an enterprise, data management area, or enterprise governance, there needs to be some frequent intersection with the enterprise architecture area. Moving on here, I have an example of what I mean by that. Now, I'm going to do a little bit of a background here. What I have here is a small portion of a Zachman framework. And for those of you that are not familiar with the Zachman framework, it is a taxonomy that expresses how an enterprise fits together, all the pieces. And the heart of it are six, I guess, domains you can call them, and that's the what, how, where, who, why, and when columns. And we could also call that data function, network, people, time, and motivations. And that's the columns, then there are six rows, two of which are depicted on our example here. And it goes all the way from a very conceptual level through an identification and definition level all the way to a physical instantiation. So I have levels two and three. I have the what, which would be data, and we're talking about data today, but data needs to interact with the how. Then there is the where does it live, which is the network, and who touches it, which of course would be access and privacy and users and things like that. And then the when, because we do have to consider the time aspects of our organization, and then of course something that I dwell on a lot is the why. What are you doing with this? What's the value in that? And all of those can be expressed from a very conceptual to a very granular level. But what we did here was taking an organization and we mapped what types of data management artifacts they had that would help support the enterprise architecture. So in the data area, what was the maturity of their artifacts? What was the presence, which was how much did they use them? And what was the priority of an artifact in this area? And what we painted was a real simple gap analysis of how an organization looks at itself, because all organizations have a taxonomy. All organizations have stuff that fit into this six-by-six matrix. And some of it's more evolved and some of it's less evolved. But we all have that. We do this. It's just how do you do it is the issue here. And we were able to contrast, and we do this once in a while for clients, this gap between enterprise architecture and your enterprise information management. And you see areas that have big blank spots or absolutely nothing. That nothing exists, for example, at the definition layer, we have no processes to find, no use cases. And by the way, no use cases is pretty hard if you're service-based, right? And there's, of course, no priority to doing it either. So very easy gap. This is what I mean by a way to start to reconcile these very disparate efforts. We've kind of got two philosophies here. Let me step back a second. The one philosophy is fairly traditional. Take a look at what you're doing, find out where there are some common points, and then not only build the business case, but then challenge your business as to why they're letting it continue like this when it's getting so expensive to operate. The second thing, a little less traditional, is take a look at this from a very strict taxonomic, rigid view of things, and see how you're really doing in making these areas. And if your enterprise architecture is not being supported very much on the data column, you know you've got a weak pillar there, and that needs to be short up. And that's another way to show that there needs to be some more attention span on looking across the enterprise for your data efforts. I hope that makes sense there. I see questions coming in. These are all really good, and I'm going to have a lot of fun answering those. I think we're going to end up with about 15 minutes for questions here. So don't be shy, folks, okay? Don't be shy. And we've got to coordinate now. And now the third thing I was going to talk about is coordinate with other stuff that's not in data management. Believe it or not, there are projects that are considered not data management. Of course, I just think they're not very cool projects. No, just my personal opinion. I'm a data person. There are a lot of things happening, though, that might not touch your data management area and maybe should or you should consider. And this is along the same theme as I just talked about with enterprise architecture. You're involved with this stuff, and you need to consider these other areas because there is some support there. There is some due diligence that needs to be done as well. I just took a sample of other areas here that sometimes orbit around data management and don't touch it and maybe should or at least should be considered. The first one is content. And by that, I mean not rows and columns. So everything from email, through Word documents, to SharePoint sites, to contracts, to safety manuals, to websites, okay? All of that semi-structured, not much structure, thing. And the thing to understand with those as part of this bringing things together are who is the audience for these because the audience for those are very, very often the same audience that you are trying to get their attention to consolidate some rows and columns type stuff. And remember to most business area leaders, there is no distinction between structured and unstructured content. That's just the stuff they do work with. And it really benefits you from an area, from a standpoint of bringing things together is to consider everything that they look at. And then the other thing is the equivalent of a steward, and I like this word better than steward actually, is that there are curators of this content. And the curator is just along the lines of like a museum curator. It's not yours, but you've been given a charter to take care of something and make it available for people to use and enjoy. And so there are always curators of content and they are appointed by content type. And again, if you understand who the curators are, you have another class of steward or custodian of some sort and you have another contact point, intersection point, leverage point for this. Digital media, some folks would say, oh, that's unstructured, John. Yeah, but I needed a fourth arrow on the screen. No, seriously, because of the technologies involved and the volumes, I personally split out unstructured content and digital media because you cross a technological chasm when you do that. That's your audio, that's your video. You have curators for that. There's the caretakers and can you see it? Here's what we've got. Here's what we offer. But you also have producers. These are people that aren't necessarily crunching this stuff to make it, but they're the overseers. They're like a program manager. And again, this is a role that's very, very much like roles in your data management world. It's a good group to touch upon. Social media, again, there's a case to say, well, social media is unstructured content. Yeah, but it is so important now. We recently had a client where we were talking about the social media presence and he said, yeah, we're just getting started, but everything's great. Market loves us and we did a survey and they did a survey and the survey said, everybody loves you and we are great. And then I looked at social media and in the social media realm, this particular client was not held in as good a light as it thought it was. And it turned out that the people surveyed, that took the survey were one demographic, but the people using social media was another demographic and they had missed them. All right, so social media is important. You have curators in there and stewards in the social media world. And you need to know where and what kind of social media it is that you're dealing with and how important it is to your organization. Again, though, the same activity and discipline for data management is going to show up here. It's a great leverage point for you. I have ERP, which is the big, you know, PeopleSoft, Oracle, SAP. It's okay to mention these names because they're ubiquitous, all right? Many of those get data management attention because they are quasi-MDM efforts. They used to not get the attention. And after the first generation or two of, say, SAP and Oracle financials, everyone said, you know what, we didn't put any governance in place and our product master is just as bad as it was when we started. And so, and even SAP now has a big governance presence. So I'm not talking about that per se. I'm talking about what these systems do. These are your operational systems. And we consider, well, they're just their input into data management. Not really. Those events, those transactional events, those interfaces that are touching your customers are really important. That's where the wheels can come off with data quality. This is a really important constituency to bring in. This is where a lot of departmental data management happens because someone has access to the transactional system because they are the owner of that and they get the data and they stuff it into their departmental database and no one ever sees what they do with it. So that's another area not to get apart. It also affects operations and it also, of course, affects compliance because you're touching things. So there's a couple areas here of not perceived as part of data management but actually really give you a lot of opportunity. So we have enterprise architecture, these four areas, the traditional way of breaking this stuff down and getting the programs and then a nontraditional way of intersecting with enterprise architecture and these other projects. So what's the message from all of this? The up message is E is for enterprise. We don't want local stuff. It's noble, it's great, it's not going to work, it's going to cost too much. Everyone says we want to be data driven. Data driven means the E is for enterprise and of discussion. It is a, in the world of arguments and symbolic logic, there's a concept of a topology. It means if this is true, then that is absolutely true and if you're doing stuff from an enterprise and you want to be data driven, then you're doing stuff from an enterprise. They're interchangeable concepts. You've got to measure stuff. You're going to have a top data job or CDO visibility into this and you're going to want to see visible business value from all this kind of stuff. So if you've got those things going for you, you can bring these things together on the other side. All right, at this project level, you're going to try to communicate. You're going to run into the political barriers. You're going to put the project before dot, dot, dot, EIM. So you want to definitely spin your messages to the left side of this picture. Two different paths for your messages top down. Go back to that operating model I showed you. Start at the top because those folks already have visibility in all this and ask them why shouldn't we start to pull all these common things together or at least think about it over time. But then again, some organizations, it's difficult to do that. So how do you act bottom up? Well, be proactive. Cross-reference all this stuff. Build the case. Say this is not an option. You're going to have to, because we can't afford it, and you're going to have to have a counterpoint of why we shouldn't go ahead and start to pull all of these, all this material together. So at that point, I'm going to start to hit our questions here and then we'll finish up with that. So Shannon, I'll kick it back to you to facilitate our questions. John, thank you so much for this great presentation and to answer the most common question that comes through for our webinars, just a reminder that I'll be sending a follow-up email for this particular webinar by End of Day Monday with links to the slides, links to the recording of the session, and any additional information requested throughout the presentation or through the Q&A. And as John mentioned, go ahead and submit your questions in the bottom right-hand corner in the Q&A section of your screen. John, the first question I have here is difficult getting people to get to the importance of enterprise data, especially with movement of the functions to the cloud. Any observations to share? Yeah, that is one of those key opportunities when you do your inventory. That's why I said identify things that are going out into the cloud. Because what happens here is everyone sees the benefits of, oh, wow, it's just a few bucks. We're going to get what we need really quick. I don't have to deal with IT, blah, blah, blah, blah. Well, a couple of things are happening. One, they're on to you. All right, that's not going to happen much longer. There's an awful lot of risk in that. And the observation I have to share is share the risk. Most of there are, I can't tell you how many times we've seen someone sending a file out of an organization that if a regulator saw it, they would just go nuts. And no one ever gave it a second thought that there was personally identifiable information on this file going out. Because the vendor's going to say, yeah, yeah, yeah, we're going to protect it. But the fact is, even if the vendor does protect it and ask your excuse, you aren't allowed to send it out anyway. And a lot of folks are overlooking that part. A lot of folks are sending out data and not consulting with their corporate council or their compliance areas. So my observation here is twofold. One, it's not so much getting the importance of enterprise data as a term or a concept. It's getting people to understand the concept of the consequences if you don't think about this stuff at a little bit higher level. If you keep thinking of it departmentally and short-term and tactically, you are creating a level of risk for your organization that in any other circumstance would be deemed inappropriate. And you would get in trouble for it. So that's my observation there. I said two things, though. So that's the first thing is the risk. The second thing is, the regulators are on to you and so are your leadership and your organizations. And a lot of times what you might be able to do is just say, oh, you know, if you're a data management person and you've got all of this department, we were working with, they just said, oh, we went with something in the cloud and the software has a service and we don't need you anymore. Rat them out. All right, send a note to corporate clients and say, are they allowed to do this? All right, because that's the due diligence I talked about. You're obligated to do that in many, many cases. So that's kind of my two-fold response there. I think we've got another one out there, at least one more. Go ahead, Janet. Well, we had a comment come into the chat section. The people at the data source are being hit by three different objectives, same data systems people, but there are different groups asking for similar things. You want to comment on that? Yeah. There's a... when different groups are asking for similar things, that is a rich, rich, rich opportunity to get them all into one room. And I have a sneaky trick I do that. I don't put them in a room and say, hey, you're all asking for the same thing. I don't do that. Because then they go, well, how do you know? What I do say is, hey, we've got these requests and they sound the same. And from a due diligence standpoint, I need to make sure that we are with it. If they are the same, you know, are they really? And if they aren't the same, how do we manage this going forward? I have never run into anybody in any organization that would say, if presented with this type of scenario, would say, well, I really don't think we should leverage our resources and save money. I think we should just go all the separate ways and just spend more money. No one is going to say that. You might get political resistance from somebody's database that they've built for 10 or 20 years and love it and cherish it. But when presented with something like this, people are going go, yeah, well, you know, mine means this, what does your mean? So a lot of it, again, is taking that inventory, what's going on out there, dealing with the challenges, but also the opportunities and taking that positive spin on it. There was one more that I saw in the questions there. Do you have one? Maybe it was in a comment or something that was about the buzzwords, Shannon. I kind of touched on that one earlier, but is that one still out there? I do not. It may have been directly just to you, but I don't see that particular question. Oh, okay. It might have been. It might have been directly to me. Well, let me, I saw this out of my eye. Would you mind if I took it? No, please. Oh, okay. One big issue I see is the buzzwords being thrown out such as analytics, MDM data quality, data governance, without really understanding what these terms really mean. Well, I understand what they mean, so of course this doesn't apply to me. But I do know where they're coming from. And because you have all these concepts out there and what it takes to achieve true integration. And there's a couple things going on here, and this is a good question because I could have touched on this in the presentation, I think. One of the drivers for good or bad, I'm not going to say which way it is, but one of the drivers are vendors sell their product that does their thing. So the MDM folks sell their stuff and the data quality folks sell their stuff. And the data governance folks sell their stuff. And there is a tendency to sell the solution to the buyer. And very often that buyer is not EIM enterprise aware. They're looking to solve a problem and away they go. So that's one thing that's against you. Oh, you have an answer to my problem, Mr. Vendor. Thank you. And you call it MDM whatever. All right. So that is a problem, and that is an opportunity to deal with it. So the one thing you can do here as part of this process in the inventory is also bring your procurement area into this. We've had really good success rolling out better discipline in the data realm by just bringing procurement in and they say stop. Nothing's being bought unless we have verified that it fits into... Oh, this is where architects come in. It fits into what the enterprise architects want. It fits into where data governance approves it to be that. And so that's one way to do that. Another way is... And I'm going to talk to the data people now directly. And you know, I'm a data person too. You know, we've got a cool job. But we do love to bandy about our buzzwords. All right. And we hear a problem and we go, yeah, well, you know, that's really an MDM thing you're describing. And then the consumer seizes on that. And you know what? Stop doing that. All right. Quit jumping to the name or the label that's on the wrapper of the product. You know, ACME MDM solutions. You know, or ACME data quality tool. Just stop doing that. All right. Just say, you know, when someone says, all right, well, customer data is horrible. Don't say, well, then we're going to go buy MDM. Just stop doing that. Say, what we're going to do is we're going to solve the challenges in the customer domain. And there is a wide range of tools to do that. We're very proud of ourselves. We, in our realm, understand the difference between analytics and MDM and data quality and data governance. But you know what? Everyone else we work with do not. And it's not incumbent on them to educate themselves either. It's incumbent on us to speak to them in a clear message. And you're really hurting yourself long-term if you do it the old way. If you just go right to the product and right to the solution, oh boy, we're going to do MDM or oh boy, we're going to do data quality or oh boy, we're going to implement a glossary tool. You know, I mean, back off of that stuff. All right. I know we got to do it. Tools are really important. It's not the starting point. So avoid buzzwords. These labels or labels that come downstream emphasize solution. Again, emphasize the inventory that I talked about. Emphasize the due diligence aspect. It's just as important for them to tell you the UY as for you to tell them why. All right. Let's see here. We've got about two minutes left as anything else popped in on the chat. Let's see. Oh, I think I see something here. How do you address the systems where each group is protecting our power base? Does that happen? Really? It's very difficult. Okay, that's kind of the whole person's talk. You have embedded groups. So we'll just use this question as a way to review. Okay, Shannon, and I'll turn it back over to you for the wrap-up. All right? So in one minute here, you've got all the systems that are doing their own data things. Step one, take the inventory. Step two, what are the opportunities and challenge, and tell somebody, hey, look, due diligence requires me to tell you that over here we got this system doing this, this system doing that, system number three doing that, and by the way, it's the same as first as system A. So A, B, and C are doing it, and A and C are doing the same thing, but spending a lot of money to do the same thing. So we bring that all to bear. Now, the third thing is that operating model. I showed you. Take that to the top, to the people with insight into that area and go, why are we doing this? Is there a reason? Why is it, you know, what is the business driver for this? And how do we back ourselves away from that? And then, you know, then bring in your architects and all the other things that I just talked about in a meeting. That's the way to do it, is get a total view of all these systems and then have the organization start to justify them or say, you know what, we really got to move away from these things. At that point, I think we'll mention the next one. It's the CDO vision series August 4th, and we're doing a big data update. Lots of data coming in on big data, and we're going to be sharing that and sharing some lessons learned and all kinds of other stuff that's of interest to those of you in the data realm and the CDOs and the top data job people and all of that. At that point, this is Shannon, I will turn it back over to you for our wrap and our exit. Dawn, thank you again for the great presentation and the Q&A. Thanks to our attendees for being so engaged in everything we do. We always appreciate it. Just a reminder again, I will send a follow-up email within two business days for so for this webinar by end of day Monday with links to the slides, links to the recording of the session. And we hope to see you, as Joan mentioned, next month on August 9th, the best practices are, excuse me, with a big data strategy. Look forward to that and I hope everyone has a great day. Thank you.