 Hello and welcome. My name is Shannon Kempe and I'm the Executive Editor of Dataversity. We'd like to thank you for joining this month's installment of the Monthly Dame International Webinar Series. This webinar series is designed to give our Enterprise Data World Conference attendees education year-round. We're excited about the upcoming Enterprise Data World 2016 to be held in San Diego, California, April 17th through the 22nd. We do have a currently have a call for presentations out for that. We have a lot of inquiries about it as well, so be sure to save the date. Today's webinar is being presented by longtime DEMA member and speaker Malcolm Chisholm. He will be discussing data governance for end-user computing. 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'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 DEMA. 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 formally introduce today's speaker. Malcolm has over 25 years experience in data management and has worked in a variety of industries. He is an independent consultant specializing in data governance, master data management, metadata engineering, business rules, management execution, data architecture and design, and the organization of enterprise information management. He holds an MA from the University of Oxford and a PhD from the University of Bristol and can be contacted appropriately, as you can see on the screen there. And with that, I will turn the presentation over to Malcolm to get us started. Hello and welcome. Thank you very much, Shannon, and welcome, all colleagues, to data governance for end-user computing, a topic that I think is going to, it was a considerable interest today, but I think will only grow in interest over the next few years. So I think it's a new frontier as it were of data governance, but one which is incredibly important. So today in the webinar, and as Shannon highlighted, please submit your questions as we go through this, and I'll try to answer those at the end. Given that it's a new area, I think there is scope for a lot of questions, but today we'll look at what is end-user computing. The background to EUC, that is end-user computing, the challenge of it for data governance, and then what has to be done for end-user computing data governance, and then finally something about data governance policies. Now I would caution that this is actually a very broad topic, and I will be in the one hour that we have only really able to scratch the surface of it as we go through it, but I think just doing that should be hopefully informative to all the colleagues out there, but there is a great deal more to it than we're going to go over today. So without further ado, let's look into what end-user computing is. So it's really right now the wild west out there in terms of data governance. It's pretty ungoverned. People are using spreadsheets and Dropbox and Access databases in a kind of shadow architecture that is actually quite vast, although difficult to estimate in size, but there are entire departments that run on end-user computing. So the question is what are the needs for governance over these environments, and how are we going to achieve any progress in terms of data governance, and those are quite difficult questions to get answers to as we'll see shortly. So let's just start with a few definitions. What's data governance? Well, and these are my definitions that there are others out there, but just to set the stage, data governance to the activities that are needed to ensure data management is carried out in an effective and efficient manner to achieve corporate strategy while minimizing risk and respecting all obligations the enterprise has for its data. Data management is the activities that are needed to the enterprise to acquire, maintain, use, publish, archive, publish again, sorry, and purge data. In other words, manage the entire data lifecycle, and which should be carried out under the oversight of data governance. End-user computing is any aspect of data management that occurs outside of a production corporate application, even if it occurs in the general environment supported by IT. So it's really distinguishing between the data management that you can do as it were by yourself or in conjunction with a few colleagues versus corporate applications. And a corporate application is a data processing application supported by IT, usually with IT involvement from the requirement stage to the production implementation stage where the built bought or rented. So IT is not really involved in supporting end-user computing. And I think it's important to be able to draw this distinction, you know, in terms of narrowing down what end-user computing is in order to focus effectively in it. Too often, I think that we tend to not have a good understanding of areas we're trying to deal with in data governance, and that can cause scope problems, it can result in mismanaged expectations, or it can result in people trying to evade, as it were, the benefits of data governance. Now, data governance itself has challenges. Although I gave a definition of it just now, when you come to dealing with data governance in practice, it breaks down into a number of different disciplines, and the difficulty is that you kind of have to be good at all these different disciplines in order to make data governance work. Perhaps you don't have to be good at them all at once, but ultimately you have to be. So we have things like data stewardship, data policies, and the data lifecycle where there are primary accountable is data governance. Then we have areas where the primary accountable is IT, like data security. So with data security, you typically have a data security unit located within IT, which is looking after things like access control and preventing hackers getting into the environment. But data governance also has an interest in that because data has to be classified as, you know, typically something like, is it strictly confidential? Is it publicly available? Is it business confidential? Is it personally identifying? And there are rules then about what you cannot do with data of these confidentiality levels, which data governance typically sets the rules or manages to get the rules set in working with other parts of the enterprise. So data governance has a role in data security, although it's not primarily accountable for it. Similarly, data architecture and modeling, you may have an entire group in enterprise architecture devoted to that, but data governance has interest in it too in terms of the semantics of the business concepts which are implemented in data architecture and modeling. And again, we can see the same with operations where change management would be something, at least data change management rather, would be something that operations is very interested in, and information knowledge management in terms of the business usage facts around operations would collect that, and data governance would also be very involved in it. And then there's other areas such as legal privacy and compliance, where obviously the legal department and maybe internal audits are involved, and data content management where you might get involved with marketing and, you know, work with those. So the challenge of data governance is trying to deal with all of these sub-disciplines within it, and unfortunately, all of them become relevant when you get to end user computing. So that is part of the challenge we're going to have to deal with as well in terms of EUC. Now let's go and look a little bit deeper at what EUC, at this, sorry, at endpoints in terms of the distinction again with corporate systems. So IT and operations are typically strong partners with data governance, and admittedly data governance can sometimes be located within IT and sometimes can be actually within operations, other times it's by itself under a chief data officer. But very often the, and remembering that data governance has only been around in terms of general implementation since about 2005, so it's rather new. And my experience at least has been that data governance aligns with IT and operations, and generally is involved in working with corporate systems, just because it's aligned with IT and operations. But today, and increasingly, many enterprises have segments of the workforce that are mobile and dispersed from central offices, and these staff are creating data at their endpoints that's not captured in corporate systems. And in addition to that, we have staff in corporate centers who are now doing work on the PCs that isn't captured by corporate systems. So typically you would see areas like actuaries or some kinds of predictive modelers who work purely in end user computing environments doing models maybe in Excel, and they are perhaps sourcing data from corporate applications, but they are not storing it there and they're not doing their work in corporate applications. And on top of that we have this mobile dispersed or self part of the workforce. There can be people on the road who are working in a disconnected way. There can be local offices or offices in countries far from where the home office is located who by the very nature of where they are are forced to work in end user computing environments, and these are known as endpoints. So where the end users are doing their work in their end user computing environments which they themselves are set up. And I'm going to leave aside discussion of the cloud for now, which is certainly worthy of a lot of attention, but it adds more complexity to it, and it has some special characteristics of its own which I think we'll have to deal with separately. So just focusing purely on what we might call standard end user computing. So the idea of endpoints is a very important one. And then when we come to end user computing itself, what's happening at the endpoints? What's going on there? Well, you can see that a lot really all of the data lifecycle itself is happening or to be honest should be happening if data management was good at these endpoints. So there's data acquisition. Now, data can be acquired from the Internet and some of it is free. On the other hand, what I have certainly found is that end users, and this is rather frightening to me from a data governance perspective, end users can actually pay for data and acquire data from data providers, some of which are just a few of which are shown here in the picture. That makes our end users subject to the contracts that come with those data sets. It's not just in question of paying some money. You can do anything you want with the data. There are contracts that cover that. Even the free data can be, which is available on the Internet, can also have terms of use associated with it. And unfortunately, even worse, our end users can go out and just grab data from the Internet as if it was free and unencumbered by any contractual obligation just because it's on the Internet and put it into our environment. That is not the case. All websites have terms of conditions on them which have to be respected. You can't just grab data from them. So already we can see that we have significant data governance concerns based merely on data acquisition. Now, I would point out that in some environments, perhaps many environments, IT and indeed others attempt to shut down end user computing because they feel they just can't deal with these concerns. This is not going to work. These environments are absolutely needed in part because IT itself cannot supply the capabilities that the users have to have to do their jobs. So it's not like we're going to be able to just stop this, but it has to be governed. And then we have tools for analysis. Excel would be a very important one. Access for slightly more sophisticated users and users are getting more sophisticated. I find it quite surprising how many business users, pure business users without any IT background today can use SQL. And then there's reporting. And reporting can be done in Excel. It can be done in Word. It can be done in PowerPoint. And from a data governance aspect, what is interesting is when these reports travel outside of the enterprise, maybe to regulators, maybe to clients. And without necessarily anybody knowing who's on those distribution lists and what they're reporting and what we are then as an enterprise obliged to back up or support in terms of data that's been officially reported. So again, another data governance concern. And then there's communication. We have a variety of communication tools. We've got traditional emails supported, say by Outlook. We've got Dropbox, which is, or it's equivalent, which is used for file sharing, regrettably not only within the enterprise, but outside of the enterprise. And so files are coming into the enterprise through Dropboxes and going out of the enterprise through Dropboxes or equivalent. I don't want to pick on Dropboxes especially, but there's plenty of equivalent services. And very often there's no rules around that. One does wonder about the, first of all, the appropriateness of the kinds of data that are shared in this manner. Secondly, the possibility of breaches. And then there are things like link and Skype and so on where other forms of communication, indeed, data sharing can occur. So that's going on as well. And then the end users themselves are dealing with models, reports, files, contracts, publications, and so on and so forth. So what I'm trying to point out here is that end user computing is rather a rich environment in terms of its diversity, complexity, the rather large number of people that are involved in it, and the points that have to be, frankly, addressed by data governance, and we need to do that, I think, fairly urgently. So let's look at a bit more of the background now. And now in terms of end user computing, because, and we will deal with this point more in a moment, because it doesn't involve operations or corporate applications that are supported by IT, there tends to be a little, I think there's a little less in terms of industry focus and vendor support. But there is some. So one place that you can go to to find out more about this is USFRIG, which is the European Spreadsheet Risk Interest Group. And they have a website. They are a slightly more academic organization, but that is not to say that they don't have practitioner's speak, they certainly do, and they have vendor interest. But as their name suggests, they're European. So they have a conference once a year in Europe, and they have a lot of interesting material on their website. Unfortunately, I do not know of any analog in North America or in any other region. So there's plenty of resources there that you can find on the website, and they are pretty good about making materials available from the conferences, past conferences. And they, I think, one of the more interesting things that they have is the USFRIG horror stories. These are not entirely up to date, but they do have some examples of what can go wrong due to lack of governance around end user computing. And here's one particular one which is rather famous, actually, which is the research embarrassed after a student finds errors in their published paper, which is, if I remember correctly, Rogat and Reinhart and Rogoff, who recently published a book called This Time is Different about the financial crash and associate that with debt levels. And they had at the heart of it a model, and somebody, indeed, found an error in it. Okay, so that was rather embarrassing. They, as you can see there, that the correct procedure was missing some countries. And the minus 0.1% growth rate suddenly turned in 0.2% growth rate, and that kind of had an impact on the purported conclusions of this paper. And there's other horror stories about how people have lost money and had accidents and things like that due to spreadsheet errors. So this is, the reason I think for looking at these kinds of things is to assist in making the business case for end user computing, which is otherwise rather difficult to do. And I would also, sorry, I just want to go back to that in a minute. I want to put in something that's also come to my attention since developing these slides for Daima, which is the website maintained by Dr. Ray Pankow of the University of Hawaii, and his name is P-A-N-K-O, like the Japanese breadcrumbs. And he has a spreadsheet error website and a human error website in his research at Pankow.com where he has some pretty interesting papers and a rather recent one, which if I remember correctly and I don't want to be held to this, has enough material to prove that any given spreadsheet has a 67% chance of having an error in it coming from the data or recalculation. So most of our spreadsheets out there are wrong. It's the conclusion. And they're wrong because things are ungoverned in large part. Our spreadsheets are simply developed. Data is simply put into them. People may not know what the data really means, anything about it. And then they use that to run the business. And lo and behold, bad things happen. They may not be discovered immediately, but they happen. Now, in terms of vendors, interest is growing from vendors. Some vendors are getting into this space. They are specifically targeting the needs of end-user computing. And I think it's fair to say that they're not trying to repurpose software that was built for something else. They're either genuinely interested in data governance or genuinely interested in end-user computing. So we are getting some degree of vendor support out there. I think as this builds, we will be able to channel more energy from data governance to end-user computing because tools will be available. And quite frankly, the vendors will be developing the market and they will be, you know, those marketing activities will in general focus more attention on the governance needs of end-user computing. And it is my experience that the vendors do want to work with data governance. So we do have a natural ally here. So we have some academic backing from YouthSprig and we do have some vendor backing as well. So for data governance professions who are out there, I think these are good places to start to find partners to assist in extending the data governance program to end-user computing, which I feel is extremely important to do. Now, also in the general background, we have regulators. And BCBS239 is a banking regulation. So I can talk a little bit to financial services here. I realize we'll have many colleagues on the line who are from other industries. And, you know, I think that this is going to apply to them in the future. But for now we have a rather strong regulation affecting banks. So BCBS239 is a global regulation from the Bank of International Supplements, which is really designed to improve risk reporting in financial services. And as I mentioned earlier, people like actuaries, people who are concerned with risk, modelers, including risk modelers, are very heavy users of tools like Excel and they are adept at setting up very large end-user computing environments. So the Bank for International Supplements, or rather it's BCBS committee, that's the Basel Committee for Banking Stability, by the way, has the 11 principles in this regulation, BCBS239. And in principle three, which is about integrity and accuracy, we find this. Where a bank relies on manual processes and desktop applications, e.g. spreadsheets, databases, they don't mean corporate applications, they mean desktop databases like access. And has specific risk units that use these applications for software development. It should have effective mitigants in place, e.g. end-user computing policies and procedures and other effective controls that are consistently applied across the bank's processes. Well, I mean, I think, you know, there you have it. You have a regulation which is mandating EUC governance. So if you're in banking and you're in data governance, you would now be remiss if you did not act upon this because it's a regulatory requirement. Now BCBS239 applies primarily to global, systemically important banks, which are like the top 50 in the world. It's also applicable to any domestic, systemically important banks, which is what regulators might feel are important in their particular country or jurisdiction. However, the general direction of this is that it's going to be applicable in banks everywhere and throughout financial services because it's about risk reporting. These spreadsheets, these end-user computing environments are there to manage risk, which is the most important job a financial institution has to do. Let's face it. So it is going to become more widely applied. There's parallels with Solvency 2 in the insurance field for capital adequacy ratios. So I think you're going to see end-user computing governance mandated more and more by regulators. So I think the time to start with it, frankly, is now and if you're in financial services, you really ought to be doing it already. So data governance has to sort of get on the wagon here and start delivering. So okay, how are we going to do that as data governance? So why is EUC governance needed? There's many reasons. So the first thing is that it's not merely the end-user computing environment per se that's important. These are very, very strongly linked to individual users in ways that does not happen in typical operations environments and typical operations environments. Although you can make the case that even in operational environments using corporate applications, there can be users who have special knowledge, who are difficult to replace, but they're usually working in teams and there is some sort of corporate, some level of corporate support. But the situation is much more difficult with end-user computing. So an individual can get a new job and then they're gone. An individual can be terminated maybe for cause and then they're gone or other reasons can happen. I put in alien abduction here. People can go away. What happens to the end-user computing environments that they have been developing? What happens to the data they've been working with? This may not be well-known. I mean, employees who get a new job typically want to focus on that rather than wrapping up what they've done and everybody else is working so hard in our now downsized corporate environments. It's not easy to pick up the material that they've been working on. If an employee is terminated for cause, they can be escorted out of the building immediately and the same problems arise. So it's not just the knowledge in a sort of business sense that goes away. It's the technical knowledge around end-user computing and the data that's involved in it. What are the producing data? What exactly is that data? How is it defined and so on and so forth? So that's a real concern for data governance. How do you deal with that? So I think you're going to have to have information, knowledge, management strategies there, documentation. Again, the regulators help. They demand in financial services documentation models. I think that's also true in healthcare and other industries. But it does require data governance to get involved and bring tools and techniques and policies to bear on the situation and get this done. Now, it's not just the individuals, but endpoints also have problems. They can go away suddenly. They're destroyed. They are lost. And they're stolen. And data security can to some extent get involved in this. And I think that this is a concern, which is on the radar of many corporations, because of data breaches or data losses that have occurred in these ways. And there are questions then about, well, what can we do about this? The backup strategy is one thing that I think data governance can get involved in or assist in that it will have to be done in conjunction with other areas of the organization like IT. But there are tools now available which can reach down into the endpoints and copy up to backup environments the data that is there. Once you do that, you have a store of a centralized backup of end user files. Then things become a lot more interesting for data governance. You can do things like check naming conventions. You can see when these were last updated. You can profile the data to see if there's production data in these files and so on. So suddenly we don't have to throw our hands up in horror because we can never understand what's going on at the endpoints. There are now ways in which we can govern them through the use of new technologies. But again, what we're focusing on here is business justification for the need of end user computing data governance. And then I think the real problem, we've got no close partner in we being data governance. So data governance that's grown up with IT is going to always, I think, be oriented to IT. Data governance that's come out of the back office in operations is going to be closely allied with those. Nobody speaks for the end user computing and in fact the end user computing staff, they themselves don't want governance. They just want to be left alone. So we don't have a natural partner there. Again, IT might be a partner, but it's got a relatively narrow focus and it typically doesn't understand data governance. Legal and HR could be partners because legal understands the implications of lost breaches. HR typically has policies about the equipment issue to individuals, but end users themselves are resistant. So what are we going to do since we've got nobody as it were in the classic IT model of tell me your requirements, I'll go and do something to meet those requirements and satisfy them and then I'll be done. This is not like that. This is an area where data governance must lead because there are no close partners and that requires data governance being mature and confident enough in itself to be able to lead and I think that's important. So to do that data governance we need to get authority and have a very clear idea of where it would want to take end user computing governance. However, I guess the flip side of this is that nobody too much is going to complain if there's no end user computing governance. That is the individuals, the end users themselves, but overall we're doing the enterprise a disservice if we're not addressing this so I think it has to be done, painful as it may be to get started on that. And then complexity is the other part of this challenge. I mentioned earlier that data governance consists of many sub-disciplines and there's many more than I've shown here and they themselves have their own challenges, their own methods, their own techniques, their own secret source, their own sets of problems and we have to unfortunately master them all in order to do data governance well, but especially in order to do end user computing data governance well. So that complexity has to be addressed and I would not deny that end user computing governance in itself has special characteristics that might make it its own discipline. So again, data governance, now who's going to figure all this out? Again, I pointed out we had some assistance from the industry, groups like use rig, we have some from the vendors, we have some focus from the regulators, but ultimately data governance is going to have to lead in this area. It's going to have to synthesize all of these requirements and come up with solutions. So the vision and leadership has to be there. So again, we have the IT mindset of tell me what you want me to build, I'll design it, I'll build it, then I'll turn it over to you then I walk away and the business analyst mindset, which is I'm just here to gather requirements, tell me what your requirements are. Well, we've got nobody here, or maybe in a few cases, who are going to tell you what the requirements are. So again, vision and leadership are needed. So vision is the ideal state. That's what a vision statement would be. So we as data governance, since we're not going to get requirements, have to envisage or visualize the ideal state of end user computing in the enterprise so that we can then understand what we need to do from a data governance perspective to help achieve that. And leadership is how to get to that vision. So that's what data governance has to do, and it might be a little intimidating for data governance units that have not really tackled this before, but the challenge is out there. It's been out there for many years now, and although it hasn't been addressed very well, the complexity has grown because the tools available to end users have increased and have increased in complexity and more and more of the enterprises are being run by this shadow architecture that involves end user computing. And I've been involved in some enterprises where the end user computing shadow architecture is greater than the set of corporate applications available. And you cannot expect end user computing environments to persist for long periods of time without problems. They have the same issues that corporate systems have in the sense that because of the problems of staff turnover, increased complexity, layering of one thing on top of another, the complexity becomes in the end unmanageable and you have a black box and you can't change things. So the excuse of saying we did not need this in the past, why do we need it now, is not valid because the complexity is growing and things are accreting over time, so the problems are approaching critical masses, which will impact the enterprise. And again, I think that's something you can see from the PCBS239 comments, that something's come to the notice of the regulators. So again, you can't say we didn't have this in the past, so we don't need it now. It's a problem of growth and growth in complexity. So that comes back to leadership on the part of vision and leadership on the part of data governance. So now, what do we have to do? Okay, so okay, there's lots of challenges here. The problem we have, one of the problems we have is how do we reach our end users? The end user computing users are usually widely distributed across the enterprise, rather than being concentrated in one or two departments. I would agree that there are definitely concentrations of them in certain departments like finance, analytics, actually. There's a lot more of them there than elsewhere, but I think you'd find them everywhere, including IT. IT is often very little automated and how it does its work, and quite spreadsheet driven. And in fact, I've noted many occasions that business analysts and others who preach the virtues of corporate applications themselves use nothing but access and excel. So that's rather odd. But we also have the problem that no department again is going to engage data governance to do the EUC data governance. In fact, they want to avoid data governance. So how do you engage these users? And I would like to suggest briefly two ways, I'm not saying these are the only two, but there are two ways I think that we can at least consider for doing this, and those are principles and policies. So what are principles? Well, principles to be done well, you really have to understand what we're talking about. And people sometimes talk about guiding principles. All principles are guiding. There's no such thing as non-guiding principles. So we're just talking about principles. Principles are propositions that are to be accepted as true or false, but not further analyzed. You can't further analyze them, you know, because they, you know, you think they can be derived from something else. If they can be derived from something else, those are principles. So it's things like all men are created equal. So are you on board with it or not? We're not here to prove that that's a true proposition. Okay, we can't. You just have to, there's a lot of things we just have to accept. So the use of principles is that they can, they're a starting point, a framework that can allow us to build a consistent set of data governance rules and policies. And it's important the rules don't contradict each other. So rather than have a purely tactical and ad hoc way of reacting to things, principles, if they're clear enough, give us a framework that allows to quickly judge if what we're doing is in accordance or not with them. So in that sense, it's very useful. So principles are, I think, also useful for data governance. I mean, you're going to have to start out dealing with end-use, if you're in data governance. You're going to have to start out dealing with end-user computing in some high-level manner. You can't just jump into it and start doing ad hoc tactical stuff. So it's important, we talked about the vision earlier, that's important, but the next step down would be the principles. So what is it that we should or should not be doing in end-user computing? So here's an example of principles in practice. You know, can you send me that big file of customer data, says one person, the other says, sure, I'll put it in my personal drop box for you to pick up. So here we have customer data going outside of the boundaries of the enterprise, outside the firewall, into the cloud, into somebody's personal drop box to be picked up by somebody else and pulled back through the firewall of the enterprise into some environment in there. And you might think this is a silly example, but I assure you it happens far more frequently than you can imagine. So that's the non-ideal state. Let's try this again. Can you send me that big file of customer data? Well, we're going to have to ask about that. We can't use external storage for sensitive data. So principles don't set the rules, but they're at least a framework that people can use to guide their decisions. I'm not saying the rules are important, they're very important, but the principles are a much quicker way of helping, of having some effect, and also they don't have to think of every possible scenario. We're going to rely on people to follow them. So what might be some sample end user computing governance principles? Well, production data in an EUC asset makes it a production EUC asset. So if you have a spreadsheet or an access database, you've got any production data in that. It's a production data asset. It has to be treated as such. Don't tell me it's test. Don't tell me it's something else. It's production. And so if you think about the way we manage, the way we govern corporate applications that are production environments, think about the way that that can be extended to cover environments and user computing environments as well. We do want a way of identifying what's an important EUC asset. I think one way to do that is to identify what a production EUC assets and how do you do that? You find production data in them. So you touch production data, you are production, and all that comes with that. All EUC, number two, all EUC assets that are used to run or manage the enterprise, i.e. production assets, are identified. So this is an important governance aspect that you've got to be able to name and identify something in order to govern or manage it. So how can you achieve this? Well, I mean, how you put this into practice could be several ways. You might have naming conventions for end user computing files. You might have some kind of register of them, an inventory of them, put somewhere with some metadata about what they're about. But you've got to be able to quickly identify them. And I mentioned earlier the ability of modern tools from the vendor community to be able to reach in and back up end user computing environments into a central area. The files that are in the central area could be profiled by data governors to see if they have production data in them. That's not too difficult a task. And if they have, then you could come back and tell the individuals on whose endpoints those were found that these are production applications, effectively, and they have to be managed and governed as such. Next. Sorry, every production EUC asset has data management and accountability formally distributed and documented. So you can't be just doing one of these let's say risk spreadsheets which could make or break the company without some racy matrix, let's say, showing who developed it, who's checked it, how the outputs are being distributed from it, where the data is coming from, and so on and so forth. So we need the formal distribution of accountability so we know who's involved in it. So we don't find out after somebody's left or after somebody's had their PC stolen. Next. All data sources used in EUC data assets are documented and sourced in the courts with enterprise directives, meaning policies, procedures, standards, guidelines, et cetera. We don't want people just grabbing data from anywhere, either in the enterprise or outside of it. We want to know where they're getting their data from and are they allowed to use the data in the way whether they are in using it or intend to use it in their EUC environments. Again, a classic core data governance requirement. Next. All usage relevant to the business of EUC assets is documented. So we're looking at how the data is used in these assets, what's it used for. There are regulations here when it comes to things like predictive analytic models for credit decisions about individual people. But we want to extend it beyond that. We want to know are you using the data in an appropriate way in accordance maybe with business policy, corporate strategy, and so on. And then all processing relevant to the business is documented, which is closely related to it. And then very importantly, quality assurance is undertaken for production EUC assets, and data quality is always addressed. And on that, I would refer back to Dr. Ray Pankow's papers, where he is promoting a kind of peer review rather like structured walkthroughs that occurred in development environments quite a while ago, which were affected. But QA could be done by peer review. There are also classes of tools that are emerging again from the vendor community specifically for things like spreadsheets that can be used and you can use, they can be used to help with data quality. Next, sensitivity of data and processing in EUC assets will be registered and respected. So if you do have sensitive, particularly sensitive data, and you have to process it in a certain way and have certain safeguards around it, that's going to be known when, again, not going to wait until the PC is lost or stolen to find out that you had all of the customer lists of your company on that. Manual adjustments to data in EUC assets will be documented. So you can't just punch numbers into cells and use that to make your model look good. That data, if you're importing it, has to be reasoned. It can't just be something you throw, fudge factors you throw in there. Again, you could be running the entire enterprise with one of these assets. Reports or equivalents that are published from EUC assets and which out of the enterprise are registered. So we know, just as we do for corporate applications, what reporting is formally being distributed to interested parties outside of the enterprise that comes from EUC environments. And then if data from an EUC asset is put into another EUC asset, or as happens quite frequently at corporate application, then a data sharing agreement is required. We want to formally document these data flows and know what they're doing. And then pathways to conversion to corporate applications, if available, and if appropriate, will be implemented. So we don't want some sort of heavy-handed IT policy saying you've got to get rid of all end-user computing. But if there is a genuine pathway for conversion of an EUC application to a corporate application, then it really should be followed. I do not see the justification for having an EUC asset. So these are principles which I think could inform data governance as it goes around doing its job and could be used to generate policies and so on. But of course, in your environments, you should be free to choose your own principles. These are just some suggestions. And I think you have to do, everybody has to do what makes sense for them. Every enterprise is different. There's really no one-size-fits-all. And then, briefly, policies, bearing in mind we've got some time for questions here. A policy is a high-level rule that constrains business behavior, like every decision about a critical data element must be documented. It's not a low-level rule, which DBAs often talk about policies, like the area or code of a telephone number must be enclosed in parentheses. That's not a policy. So a policy ideally doesn't tell anybody how to do something. They have to figure out how to operationalize them. But policies are enforceable and enforced. You should not have a policy if it's not going to be enforceable and if you don't actually take the trouble to enforce them. So policies can also help with end-user computing. You also need to get authority for enterprise data policies if you're in data governance. And again, this comes back to the leadership thing. Data governance has to have the authority to issue policies that will govern the EUC environments. And I think when it comes to specific things, policies are probably the most important tool for addressing EUC governance. So develop EUC policies. Again, I don't want to go into this too much. You will need a policy lifecycle formulation, promulgation, operationalization, compliance checking for all the policies for data governance. But I'm suggesting that EUC policies, because we're reaching such a diverse and dispersed audience, are particularly important for data governance. So you need to make sure your policy framework, your policy lifecycle, the way in which you do policies is very sound, very robust, in order to be able to address end-user computing. And with that, Shannon, I'd like to hand it back to you for any questions that might have arisen. Absolutely. We have questions coming in. And if you'd like to submit a question, just submit it in the bottom right-hand corner in the Q&A section. And of course, one of the most common questions that we receive are people inquiring about a copy of the slide and the recording. I will be sending out a follow-up email within two business days. So for this particular webinar, by the end of day Thursday, with links to both of those things and anything else that's requested throughout. So let's dive into it. Malcolm, we have a comment here, but maybe you want to add in your own in addition. It says, our IT operational risk team, along with various key business partners, took a year to build out the EUC governance, and now each DG group is responsible for implementing. And it's their first year in production. Do you have anything you want to comment on that? And congratulations to them for getting their program off the ground. Absolutely, yes. Okay, so there's a number of implications in that question. First, but it was done by risk, which is rather interesting, as to where I would question, just being a little cynical, I would question as to whether risk had the expertise to deal with data issues. And then secondly, each data governance group has to implement it. It sounds like you've got decentralized data governance. And I think data governance, I appreciate federated models, and I think they're very important, but if there are separate data governance units, they should be coordinating themselves and coming up with an enterprise viewpoint on the specific data governance issues of end user computing. And I do appreciate those non-data governance aspects to end user computing, of course. So I think that getting my advice there would be to get the data governance units to coordinate with each other and make sure that everything is being done in a common way. Communications are common, terminology is common, the whole approach is common. I love it, this is a great advice. And then next question is, same design, a little bit different angle. We are on the path of becoming BCBS 239 compliant. I have been studying about center of excellence. How do these relate? Any advice on becoming more operational with governance or alignment and the day-to-day work needed with data? Sure. So when you center of excellence, I didn't know there was a concept of BCBS 239 center of excellence. Usually it's something like business analyst center of excellence or something like that or analytics center of excellence. It implies a pool of resources that can be utilized. But I think for BCBS 239, there's a lot of literature out there now, so I think you can do that if I might put a shameless plug for myself in. I am talking about BCBS 239 in a tutorial at the upcoming data governance financial services conference in Jersey City. So I think getting materials like that, I do think that to be honest, that the consultants and vendors who are involved in BCBS 239, and perhaps I might include myself in this, could do a better job of addressing the end user computing implications of BCBS 239. So I think that what the initial thing to do would be to take the advice given for general BCBS 239 and then turn it into a way that's consumable for end user computing. So they talk about critical data elements, data sharing agreements, quality checks, things like that. The Ray Panko idea of the peer review of spreadsheets. That I think could be useful to ensure you've got compliance in end user computing environments for BCBS 239, but that would only be a starting point. Sure. I love all these programs starting up. Assume a clean slate data management environment with a low level of data management maturity. What would be the order of priority for implementing DG processes or organization? What are the processes before and after DG discipline that need to be implemented? Right. So you're starting up data governance here from a low maturity environment. So when you're in a low maturity environment, people are doing things tactically because there are needs out there that are not met. So you have to do that. So I think what you have to do initially is to build a data governance operating model, which is how are you going to do data governance in your operation? You do need, especially in that kind of environment, you do need executive management to sponsor it because otherwise you can't get the authority. And not that you can't do something, but it would just be very limited. So you would need to, I would recommend, go to a small data governance office unit, get a couple of bodies for that because you do need people who are specialized in data governance. It can't really be done by people who have day jobs, you know, other than data governance. You need just a couple of people who are focused on it all the time. Now they can, then they need to find partners because granted you can get a couple of people doing data governance, but the need for data governance is spread out all over the enterprise. So a couple of ways of doing that is starting a data steward program and the term data steward is used and abused widely. For me, a data steward is really like the eyes and ears of the central data governance unit in these other areas of the enterprise who can help understand what the data concerns are in the particular business domain and help plan the data governance program and then data governance needs to find special partners that they can work with. Again, the idea is to leverage other people. So legal always has a good partner for data governance. They always have lots of data concerns and in fact some organizations worry that data governance is too aligned with legal and becomes paralegals, but that's another topic. The PMO is another natural partner where data governance can insert itself into the PMO program to make sure that there's a check early on for each project to see if there's any data governance concerns. So leveraging these other parts of the organization and then developing a roadmap that's meaningful and again coming from a low level of maturity, you have to be careful about communication and all the soft skills to turn that environment around because people won't see the value of data governance right away. So I know we're all set of time but that's kind of just the starting point. I think that could be a whole other webinar. Certainly. Well, Malcolm, as you point out, we are out of time unfortunately, but we have a lot of good questions that have come in. So if you want to keep submitting your questions, I will work to see if we can get some answers for you. Malcolm, thank you so much for this great presentation. It's really been informative and thanks to our attendees as always for your time and attending and for being so interactive in everything we do and asking such great questions. So Malcolm, again, thank you so much and I hope everyone has a great day. Thank you. Bye.