 Okay, well, hello and welcome everybody. My name is Tony Shaw. I'm the CEO and founder of Data Diversity. I'm proud to be producing this webinar series of data governance case studies for the Data Governance Professionals Organization, the DGPO. I'd like to thank you for joining today's webinar on implementing enterprise data governance from a line of business. Can it be done? A couple of points as we get started. Due to the large number of people that attend these sessions, everybody will be muted during the webinar with the exception of the panelists. But for questions, we'll be collecting those through the Q&A section in the bottom right-hand corner of your screen. Or if you prefer to tweet, we encourage you to share highlights or questions via Twitter using the hashtag of DGPO. I'm going to turn the webinar over to Ann Buff today from the Data Governance Professionals Organization to introduce today's webinar and speaker. Ann, please take it away. Great. Thank you, Tony. Before we get started, as a reminder, I just want to let everyone know the recording for the webinar today will be posted in the DGPO members-only section of our website in just a few days. I also want to take a little bit of time to provide a brief overview of the Data Governance Professionals Organization, actually the names that we refer to as the DGPO. So the DGPO is a community of data governance professionals whose mission is to share knowledge, content, and best practices with our members to build a community of practice. Towards that goal, a group of individuals that we have are working on expanding our best practice information for the six areas that you see in the bottom... I'm hoping you will see in the bottom of this graphic here. The stewardship, the fundamentals organization, process, metrics, and communication. If you'd like to learn more about the Data Governance Professionals Organization, please visit our website at dgpo.org. We have also had the opportunity to run a best practice award this year for companies that are excelling in the data governance area. So to honor those companies that have advanced these data governance programs, we awarded our first Data Governance Best Practice Award this year. The award is given to practitioners within a customer organization in recognition of the business value and technical excellence they have achieved in the design and implementation of an outstanding data governance program. We had 18 submissions this year, and these companies are being featured in these DGPO webinars throughout the rest of this year. I am thrilled to have the privilege of introducing today's speakers, Sean Houston and Ho-Chun Ho from JLL. JLL is a financial and professional services company specializing in commercial real estate and investment management. I myself had the honor of serving as a judge for the DGPO Best Practice Award, so I can tell you personally that the JLL Data Governance Program is very impressive, so we are definitely answering that question today. Sean Houston is the Vice President for Global Data Governance at JLL. He set a computer or operated business information systems at Howard University in Washington, D.C., and had a unique opportunity to work in family business developing a budgeting system for colleges and universities. He built upon that experience creating similar systems for country clubs. He's that fancy. Realizing that his true passion was the data captured by the applications, Sean focused his journey in the data arena. From database administration to data architecture to business intelligence, and finally data governance, Sean has served in all roles surrounding data. Sean later obtained his MBA degrees in both finance and marketing from Drexel University to increase his business acumen. Combined with his data skills, he has helped Fortune 50 and Fortune 500 companies such as Comtas, JLL, and DaVita realize improved data quality and real value from their data-driving revenue gains. Now, Ho-Chun Ho guides and oversees global data governance and management for the corporate solutions business line at JLL. The scope includes the business oversight of master data management, data quality, metadata management, and the overall data roadmap. Ho-Chun and his team defined and established the data governance function, its organizational structures, global and regional resources, processes and operating procedures, tools, and communication protocols. He also mentors the organization on the overall enterprise data strategy to leverage industry best practices and leading edge technology in enterprise information management, business intelligence, master data management, and big data. Ho-Chun is a regional director with JLL. As you can tell, both of these gentlemen have an enormous amount of expertise that I am excited for them to share with us today. So without further delay, it is my pleasure to hand today's session over to Sean and Ho-Chun. Hello, thank you, Ann. Let me share my screen and get right into the presentation. Can you guys see my screen, Ann? Okay, I think you can. Yes, we can see it. We are good. Okay, so hello. My name is Sean Houston, and I'm here with my colleague Ho-Chun Ho. Hello. And we'd like to thank you for joining us today for this webinar. We're excited to put this on for you, put this together. It's entitled, Implementing Enterprise Data Governance from a Line of Business. Can it be done? So I think there's no need for us to say what the question line is because if we didn't think it could be done, this would be a very short webinar. But we want you to ask yourself a question. Let's say you're in a line of business and you need data governance to get the work done. Would you know how or where to start? When you do it, should you keep the enterprise goals in mind or should you just focus on your line of business priority? So today we're going to discuss these options on how you can do it from a line of business. So let's go ahead and get started. First, quick information on the company where we both work. So JLL is a Fortune 500 global professional services and investment management firm specializing in real estate. So our company has multiple lines of business, integrated in order for us to provide real estate services to our clients. So the line of business, Sean and I are in, is called Corporate Solutions. We service corporate clients around the world to satisfy their real estate needs from looking for a site to managing leases and facilities to perform maintenance on their equipment and assets and to implement projects. For example, to build a campus or model a floor or add a kitchen. And throughout the support for our clients, we constantly find ourselves in this situation where our client is on the real estate team in the commercial company. They need data governance, but real estate data is not a focus or the priority to the enterprise data governance function or to the chief data officer. But they do not want to be a silo with just their own data standards. On the other hand, they cannot afford expensive data governance tools, resources, and they would come to Sean and me and ask us what they should do. So in fact, Sean and I, we are in Corporate Solutions and we are in a similar situation, and I think some of you may find it familiar. We are in the line of business at JLL. When we fund up the enterprise, we are a spoke to the enterprise hub. However, to our client account teams, we are the hub, and they are the lines of business. So the question becomes, can a line of business implement or at least start enterprise level data governance? How do we align data governance objectives and activities? Can it really be done? Can the tail whack the dog? That's really the question. So Ho-Chun and I will come along with a couple other individuals established as data governance organizations within our company about four years ago. So due to our successful and our unsuccessful experiences, it's important to remember that everything you do will not always be successful. Every effort won't be successful, but the efforts that you undertake, whether they're successful or not, even if they don't come out as desired, there are a lot of learning lessons that you can take out of them. And so at this point, we find ourselves uniquely capable of speaking on the challenges that are faced in implementing enterprise data governance from a line of business. So you can see there's a little joke inserted here in our presentation slides showing our pictures of different sizes. I'm not sure if they're saying I need to lose weight or Ho-Chun needs to gain some, but little joke. So why are we implementing data governance in the first place? Why does your company even care? Is it just so that we can have data that someone can say is quote-unquote clean? You know, that's not usually the case. The benefits that are inherited by a company that embraces data have become clear. It can become a strong competitive advantage for your company. Many successful, most admired companies are called themselves a data company. So you have a data company that just so happens to have the largest online store or a data company that just happens to sell the best cell phones or tablet, or again, a data company that just happens to be the largest retailer in the world. It's important to remember that data is not always useful. It's only useful when it's clearly understood, accessible, protected, and trusted. So the steps that you need to take and the challenge that you need to face. But to get that advantage, you have to address the data governance mandates, the processes, the structures, the leadership structures, and data governance platforms that need to be in place to make that data useful. So in a nutshell, a successful data governance program will include the four components that you see down here. Mandates, processes, structure, and platforms. For example, just think about this. How must you respond to regulations that come across such as the GPBR? Do you have any internal mandates inside your corporation to integrate the systems from disparate data sources that you have inside your organization? Similar to what we had in JLL, when our company chose to integrate all of our lines of business into a single platform. What platforms must you have in place? What processes? And remember, we're talking about all of this in a perspective of doing so from a line of business with the objective of extrapolating the effort to the enterprise level in the future. So what must you consider and what must you implement? Okay, now let's have a little bit of fun with the topic. So there's a popular show on the cable television network, HBO, called The Game of Thrones. So some people may watch it. I know it's a personal favorite of mine. I don't think Ho-Chung watches the show. No, I don't. Time for TV. But there are multiple parallels. I think you can take between the show and implementing data governance from a lot of business. Even though these view were not familiar with the show, I think I can get you to see the point I'm making. So really quick. Let's level set the show and why I think it's a good metaphor. So the show is about a group of seven kingdoms. So I liken these kingdoms to lines of business within your organization. So just like the lines of business within your organization, the seven kingdoms are not separate, but they comprise a youth bot organization and on a show it's known as Westeros. So each kingdom faces its own set of challenges. The people inside have their own skill sets. And the way they have their own unique way they need to run based on the conditions or environment with which they exist. Now some of them work well with others. Some don't. Some are more powerful. Some are less powerful. So I look at it as not much different from what we have in our lines of business. But just like our line of business, they must interact from time to time. Again, remember that they all comprise one larger organization. So in any effort they undertake, they must also take into account the enterprise, if you will. So two other quick points. There's a group of advisors you see up here at the top. They work on behalf of each kingdom, as well as the entire organization. The people watch the show, you'll know them as the Meisters. So I look at them like an enterprise data governance organization. And interestingly, they have enterprise component as well as a localized one that serves each of the individual kingdoms or lines of business. So I'm hoping that you guys can see where I'm going, which is metaphor. I thank you for your patience with the metaphor. I think it's pretty interesting. You know, my last point is about a common phrase they have inside the show. In fact, it's kind of how the show is all coming together and culminating. And it's here. You know, over here, winter is coming. And this represents all the real and perceived threats that the kingdom face. It's the present and future threats to the kingdoms that if they don't prepare for them, it could take them all down. So I look at these as a threat that you face with your data if not dealt with and prepared for effectively. It can result in fines and significant loss and competitive advantage for your enterprise or your line of business. So in our world, data world, winter is coming means the data is poorly documented and not understood. The regulations and compliance pressures like GDPR and the difficulties, the precise measure, the quality of data, all the factors that we look at as the winter is coming. So for those who've actually been watching the Game of Thrones, this is where I got the inspiration of the metaphor for the show. And this reminds me of a data governance organization. And this is kind of what I do. So many line of business data governance programs focus too much, in my opinion, on the immediate line of business objectives. And they don't take the time to collaborate, define, measure, and understand what's the strategic demand? What's the impact across all the other lines of business? They're starting in a line of business, but what about all the rest? So we start defining things like data quality targets. So 80-20 rules became very popular. Do 80-20 rule, everything's supposed to be successful. So let's say 80% completeness of address data is good enough for marketing. What about that missing 20%? That could link to bad customer service and customer attrition or some other big impact that's not understood to the data people in one line of business. I look at it like the winter is coming on the show and there's one kingdom that has dragons. Some people know they have a dragon, but they don't really know what the impact is that one kingdom has a dragon until they're being burned down by the dragons. And because they don't know about the impact of the existence of the dragons, they can't properly prepare for it. And that could just be in that 20%. So sometimes the 80-20% is not good enough. So enough of the show. So I think some of you probably enjoyed that little comparison with others, but I hope everybody got some points. It jumped out to me as I was watching the show. I know it's a very popular show, but getting back to our specific discussion, we're talking about implementing enterprise data governance from the line of business. So what factors must you consider and what is different in this scenario? So it is absolutely reasonable for a line of business to focus on certain priorities or objectives that may not be in sync with other lines of business. In fact, because the enterprise has a much larger scope, it is very likely that a line of business does not have the same targets as the enterprise. Let's just take General Electric as an example. GE makes light bulbs. They also make aircraft engines. At one point, they own the majority shares of the NBC business where movies and movie stars were their products. So it is really impossible for all these different GE companies all have the same priority. However, shareholder value let's say customer satisfaction are always the highest level of alignment. Effectively, there are common goals for all the lines of business, all the GE companies, for example, or at the enterprise level. So to implement enterprise data governance from the lines of business, you have to think about how you would meet your own needs while making your program flexible enough that it's possible to be leveraged by the organization at the enterprise level at a later point. Reusability becomes a consideration. Data standards that are more overarching will be nice. Ability to map and track the differences over time will be important. And certain data platforms, data governance platforms or tools make more sense than others knowing that they will have to accommodate more users with distinctive needs at a future point in time. And of course, you will find some challenges. For example, lines of business typically have limited funding for data governance. And you certainly have your own timing even if the scope of data you want to govern is the same as the enterprise or other lines of business. Your timing will be different. Typically, when a line of business implements data governance, the focus is what we call vertical sharing. All my real estate teams, in our case, will follow the same country codes because I'm in the real estate world. When the enterprise does it in your company, it probably will want to enforce the adoption of standard countries across the company therefore enable horizontal sharing. Sean, are you on mute? We cannot hear you. What you find is there's no one answer for every organization. You have to strike a balance based upon how your organization is comprised. The personnel, the skill set, the industry talent, the processes and services that are already in place, the funding. So there are a lot of factors you need to consider. You can see over here on the right of the slide. So what it comes down to is the role that you are taking on when you start enterprise data governance from your business line. Do you see yourself as an evangelist, a leader, or a follower? Is the environment allowing you to do the enterprise level work from a line of business? So we've seen some of our clients just for real estate data. They keep the other lines of business and enterprise informed of their plan and the progress that they make. But they don't bother building consensus. We've also seen other clients that start by building a community with financing HR because real estate is naturally linked and often use HR and finance data. We've seen them work together. We even had one client who decided to start data governance with just real estate and the entire enterprise data governance function. As soon as you join forces with other lines of business or the enterprise, that's the point in which you face the dilemma consensus or compromise. So we revisit this a lot. Who is the leader? Who is the follower? So let's say we're all in a class and we're one of the three what they call the good kids in the class. And there's seven much more powerful students in the class with us. And a couple of those people may actually be considered bullies in the class. We want to start an enterprise data governance in this class and we don't have a teacher here. So there's no one here to lead the discussion and kind of drive us in one direction. So depending upon how driven we are and how influential you are, you may be able to get it done without having that teacher. If you find yourself in a situation where you are constantly giving in to other students, you may perceive yourself as having consensus, but it's really just compromise. Because in this case, doing enterprise data governance from a single lot of business is really difficult if you have a similar situation. Even if you have two other good kids supporting you and behind you, you're compromising to the stronger individuals. They're taking into account the importance of what the influential need, but maybe not with the entire enterprise needs. So that's why we talk about striking a balance. And Stephen Covey wrote a best-selling book that I consider myself to be somewhat of a disciple of. It's called The Seven Habits of Highly Effective People. It was written back in 1989, but I feel like the concept in that book are timeless. I talk about a lot and one of those that he has in there is about compromise and he starts me against compromise. You can look at compromise like this. So you have one political party and they say it's my way or the highway. And you have an opposing political party and again, they say my way or highway. So they battle it out. And there's usually no one party that comes out. It's basically you get a little bit of one, a little bit of the other. So instead of one party winning, what you usually see is what they call compromise. But what he talks about is compromise doesn't really equal one plus one equals two. It's not really one plus one equals two. It's more like less than that. Nobody really gets their way. So it's about one and a half to best. So he argues that there's a third alternative, which is synergy. And it's often the foregone alternative. So it's not just resolving the conflict but transcending it to find a win-win situation. And so a lot of times, as you see we go through the organization, the presentation, that's what we say you should fight for that win-win situation. We cannot emphasize enough that doing something is better than doing nothing. So you may honestly accept all your options and the decision might actually be made for you. There may be only one option and that's to do it at the line of business. That's why we say you just have to get it started. Yeah, so when you do enterprise-level data governance from a line of business, you do have to change your perspective and maybe think about your approach, even though the work may be exactly the same. So let's take a look at some examples from our experience. As we explained earlier, Sean and I are in Corporate Solutions at JLL. That is considered a line of business. To support our business intelligence analysis, we actually have to do a lot of research and analysis, and we propose the industry co-standards to both our Corporate Solutions data stewardship program and to the enterprise. Our requirement at a time was to ensure that a single client company, regardless of its locations, will get a single authoritative industry code. So in that case, Apple and Apple Store will be in the same industry of, let's say, software and hardware manufacturer. We were able to get that blessing from the enterprise and get a consensus, get a blessing from the stewards, and then we put a standard in place for our line of business. So we started using that for analysis and a few months later, the enterprise started to implement company master data for both client data and vendor data. And for that effort, it is required that JLL must have the ability to identify specific industry classification for the entire company as well as for each point of operations. So in the case of point of operations, in the case of Apple Store, it would be considered a retail industry in the retail industry when the entire Apple as a company is, like we said, software and hardware manufacturer. And because of that change, we eventually have to... we were informed by the enterprise that the standards must be revisited. We eventually modified our standard to support the entire needs across the company. So let's pause the moment and think about this. You may think that this is a situation where a business line of running enterprise data governance because when the timing is off, you have to do rework. However, we were able to support the business intelligence analysis for a period of time knowing that there is a chance that this standard may have to change. Another case study from my experience was we had to manage reference data. So one type of reference data in JLL we had to manage as property type. So property types are usually a list of an application when you're choosing one of the property types or used to classify a report condition as some type of filter. And you can see in the picture examples of what people would call property types across JLL. Now, depending upon who you are and you may call it property, you might not call it a property. But let's take it from the line of business perspective. And we're going to talk about the line of business that exists inside of a retail bank. And the lease administration perspective would not be a property because the bank office itself holds the lease. So I'm only worried about who holds the lease if I'm in the lease administration looking at it from the facility's management line of business. I may argue that the ATM machine is a property as well as the bank is a property because I have technicians who need to service each of them individually. They have to service the ATM as well as the bank. And so to me, they're both considered properties if I'm in the facility's management. So you can see across the lines of business how you have different perspectives. And we see even more interesting situations as you look across other lines of businesses. As a service provider to our clients at JLL, we have to care about all of the edge cases and the variations. Our clients on the other hand, they're typically in one industry. They don't need to worry about ATM machines and cell towers are only important telecommunication teams. So the clients need to represent their property types and we need the enterprise people who are doing BI for benchmark reports or some type of enterprise analysis to be able to represent their property types that can go across the clients. So the solution we came up in this situation we came up with a client standard as well as an enterprise standard and then we came up with a facility for them to be able to map across the two. Now looking at that from a data standards compliance perspective are they complying with our data standards? In this situation, we allow each client accounting to deviate from what we consider our standard property types with our blessing. The maintenance of the reference data mappings between the clients' property types and our standard property types with the way that we do data governance. So we discussed a lot. And we're going to move on to what we consider to be the meat of this webinar. So we emphasized that you need to do something, but what does that something look like? So we mentioned options, but what option should you choose? So every data governance program is going to be unique according to the makeup of your own organization. The more central shared services that you have inside of your organization the more that you may look more towards being able to do enterprise components and have them in place. So what could that look like? It could be a shared IP team funding shared across tools and platforms. Conversely, the less shared services you have could make you make a decision to implement within the line of business with careful consideration of how that solution can later be used by other lines of business and enterprise in the future. So if you think about and this is just in the line of business and you can only accommodate five users under license agreement. How do you extrapolate that out when the other line of business comes across when you put that out to the enterprise? So these are the kind of things that you would need to consider. So now we are going to zero in on what we consider to be the key factors to success. So the first one is agreement. So a major component of the data governance program is you're building a culture that's eventually going to facilitate what you look at as the desired behaviors that you want people to actually do naturally. So by agreeing on common goals, putting in a framework and methods that can be duplicated from one area enterprise to another and then along with the strategic goals that you've made, you're building that desired culture. You're building trust. So therefore, having that trust allows you increasingly to delegate more and alleviate some of the needs you have for your excessive monitoring. Now, I am not suggesting that you don't do monitoring at all because you should do monitoring, but it's that excessive monitoring that can become costly that you will be alleviating. Another key point to talk about here is agreeing to what you do not agree on. So some examples we've come up with are talks about client standards versus enterprise standards, line of business standards versus enterprise standards. So we're suggesting that you acknowledge that you have differences in priority and timing, but we also say that you should think hard before you agree to disagree. You don't want to lose too many of the battles that are going to restrict the way that you can extrapolate this out to do enterprise data governance in the future. The next key factor is similar. So this is agreeing on how you interact. Who has the authority? How will we solve disagreements? For that, I have a personal story to share. I am originally from Taiwan and growing up in Taiwan, when I watched the movies like Die Hard or The Negotiator, I could never really understand why the FBI agents that were going to shoot the hostage would agree to give the jurisdiction to the federal police, simply because Bruce Willis just left the federal building. What is amazing to me is how each of the stakeholders in that situation knows, respects, and follows the rules of engagement which were established upfront so that we do not have to spend time to argue about the ownership and authority over its subject matter of data governance in each crisis situation. This is extremely powerful in trying to implement data governance and drive wide adoption and support. Also, in the Game of Thrones, the kingdoms rule in the individual kingdom but they almost listen to the house of Robert Barathe who rules over all the kingdoms. That's what they all roll up into that one house. So that is their agreed upon rules of engagement. So you, when you start your data governance initiative, you need to have your rules of engagement in place, formally defined in order for you to be successful. So this includes the idea of corporate data citizenship. So you have to agree to be a data citizen but it's not just given to you that you're a data citizen. It's a right that you earn by acting in the manner that we've all agreed upon is the desired behavior. So in other words, it can be earned but it can also be lost by not exhibiting the desired behaviors of the culture. I think that's the key point. This corporate citizenship defines the behavior that should be encouraged and the behaviors that will lead to consequences. So one final point on this is the concept of a franchise model. This is very, very important as well. So just like McDonald's or Starbucks, you create a franchise model that another lot of business or enterprise can leverage. It provides the model on how data governance with the appropriate agreements, rules of engagement and all the other factors that we cover are all in place. You do have the opportunity to do some localization, such as when McDonald's introduces a specialized product like McLaughster Roll in a single market like Boston. And when that's successful, their process is already in place on how you would introduce that successful product into the franchise model. On how you would introduce that localization in the first place. When the franchise is successful, you can let that franchise lead a certain function or that new capability so it can be rolled out in other franchises. Effectively, each franchise is becoming a center of excellence on some topic. They can do the training. They can bring the experiences and show everyone else how to do it. One area where you can find significant cost savings is how to share your tools and your platforms. So what's in place at your organization already that you can use to share? What are you thinking of introducing as new that you will want to share inside your organization? For example, so you're doing a lot of business data governance with an eye on enterprise data governance in the future. And you're thinking of purchasing a reference data management tool to take care of your standards, your reference data mapping, is it just a line of business? Is it funded as an enterprise? Is it just a line of business? What is your licensing agreement look like? How do you set up the structure within the tool to accommodate any future lines of business or the enterprise that need to come in? Does it scale? These are all the different things you need to consider. So what areas of opportunity do we see inside of an organization where you can share platforms? Do you have a lot of issue tracking, right, knowing your data issues across the platform? Business glossary for common terms, workflow for approval things, reference data management, metadata, data gathering, storing and delivery. All possible opportunities you have inside your organization for sharing platforms. Of course, that's going to vary about organization where your opportunities are. So you have to ask yourself the question, what is a good opportunity if you have a rule of thumb? It's always a good idea to fund these shared platforms from the center. So if it's possible, let the enterprise own these platforms. That's a lot of business. All the jokes here, I've always heard... I agree with this, but as they say, the most important resource any organization has is people. And we all agree on that. What are some important things to consider in this area when we're building our organization? Do you have the right people? Are they the right people performing the right role? Are they organized in the right groups? Are they in the right place performing the right role? Are these groups permanent like a data governance office or are they transient, like a working group or a task force? Are the right processes in place for them to be effective? And do they have the right people? So many times the company had a great employee. Everybody loves this employee. He fits in with the culture. He really has the knowledge that you want somebody to have, but that employee becomes frustrated because they just can't be effective. And it's not due to the capabilities, but the inability to be effective within the structure that's in place. I know I felt it before in my career. I'm sure a lot of you have as well. Identifying the right people for the roles that you have. And if you can't identify them, maybe you need to build them. Maybe they don't exist inside your organization. Maybe you have difficulty bringing them from outside. Maybe you just need to take some people that you have, provide some training, putting them in some type of rotation program that cycles those employees through the data governance roles that you have or through data governance initiatives of teams that you have so you don't have the right people, but you build the right people within your organization. We suggest that you build domain-based stewardship groups around areas such as industry and property types that we discussed earlier, or another example could be equipment. Build these groups with people with diverse backgrounds in the organization to make sure you get a complete perspective. So when you make your decisions on standards, it becomes key because you have people from different lines of business coming in, they can all weigh in on their perspectives and you get a more complete, comprehensive solution. So the next factor is convergence. So what does this all mean? What does convergence mean? What do we mean by convergence? How do we all come together is what we're talking about. You start to add a lot of business. You implement a data governance program, but you did it with the thought that it would be an enterprise data governance program eventually. So how do you bring all that together? You have a few tools at your disposal. You have a roadmap or a set of roadmaps. A formal change management program is inevitably going to be a need for change, right? So you have a formal change management program on how you're going to introduce that change. A decisioning framework that identifies how you will make decisions. So I worked for a company before and they had a set of core values that kind of drilled into us. And one of the core values was you cannot say something was not your responsibility. So whenever we sat around and made decisions, you cannot say as an individual, this is not my area, so I have no opinion. You had to help inform the decision. So that's part of the decision framework that they have put in place in that company to make sure that diversity of opinions was always represented. Conversely, the process of race should be clearly defined. So for example, standard data definitions may start with stewards or given domain in the line of business. If any group decide or have a need to deviate from those standards, we have a clear exception consideration process and escalation path to address or discuss that deviation. And when it occurs, it's blessed by the line of business data governance and the enterprise. So convergence is bringing everything together from line of business data governance all the way to the enterprise. The answer is yes, it can be done. I'm pretty sure I'm giving away our ending conclusion, but yes, it can be done. The final factor is risk. So you cannot proceed without understanding your risks. You're starting at the line of business level. So you have the risk of divergence. You have the risk of other line of business or someone at the enterprise doing something different, something that they'll find later difficult to back away from. And that's the key point. We talked earlier about the need for agreement and a notion of consensus to compromise. And we talked about can you force other people in the organization to take your way in the highway? If you can't, you know, how does that play out as you get to more to the enterprise side and start the line of business to find a place of synergy? When you did not find these places that work across the organization, you're going to start to find yourself with the need to revisit whatever your data governance solutions were and perform your work. And that's just like the example we had about industries earlier in the discussion. If you're lucky, you'll be able to solve that with some type of mapping solution. But if you think about it, that could be time-consuming as well. The knowledge of how to do the mapping, who cares. In our experience, we found it very difficult to get someone to actually care or have the time to participate in the mapping after the fact. If you think about it, it can be very time-consuming that mapping exercise may not be trivial. So doing it after the fact can become very costly. Finally, when you're visiting our Game of Thrones analogy, we have on what they call the show the Wildlings. So these are the people who decided not to participate in the kingdom or in your organization not to participate in data citizenship. They live outside your data governance program. They don't follow the rules. In fact, you probably took away their data citizenship because they didn't exhibit the proper behavior. But did you put in the proper protections to keep them from being able to go back in their data? Remember, there are other lines of business than you may be in. How strong are your data sharing agreements? How about your data privacy and security policies? So these are the risks of running enterprise data governance from the line of business. However, you make the point if your decision is not to take any action, then you find that risk to be far, far greater. But you have to do something because the cost of doing nothing, it could be very costly. Costly in a financial manner. So I read a blog late last year that quantified the cost of not doing data governance at 50,000 pounds for new data coming in your system. So think about data that wasn't in your system before it's coming in new. And the assumption is there's about 10,000 errors that you have to fix a year. It takes five minutes to fix each error. You take each person about a pound a minute. So the estimation is about 50,000. That's just the new data. What about data that's already being used? Data that's already in reports that are in place. Systems that have UI restrictions. So you can't just change the data in that system without changing the user interface. In that case, the cost of data governance becomes way higher. And we're looking at about 500,000 pounds of what they estimated at. That's on top of that 50,000. On top of that, think about violations to regulatory compliance. Now you're talking about fines or any contractual agreement you had with your clients that you weren't able to reach up to. That could actually completely bring your business down. So the cost can be very high to not doing data governance. So I went into some depth to try to talk about the cost of not doing data governance in the risk so that it can drive home the point that there are risks. They must be considered when making a decision on how you're going to deploy to all the factors and the anticipated risks. You move forward with a model that fits your organization. So at this point, I hope you are thoroughly convinced that this is certainly possible that you could start the enterprise data governance from a line of business. Sean and I certainly drink the Kool-Aid. And the process we went through in corporate solutions at JLL is not just art. There's actually some science to it. The method makes a lot of sense to me. And like I said, many of us work in an organization that is both the spoke to the enterprise hub and the hub to our satellites. So as soon as you know your position, you could then focus on building agreements with your counterparts. My analogy is that we all need to agree that we are all going west. It means that no one would go east. We have to have that agreement. And we need to work together to define what west means to all of us. You may agree to disagree but only on priority and timing. Whenever possible, we need to share the same right on our way to west with other lines of business. So we mentioned the rules of engagement and how important they are. You need to pay attention to rules of engagement. Do not dive into data standards, critical data elements, data quality rules directly. Take the time to negotiate with your counterparts to establish your rules of engagement which is going to be your constitution. Like I said earlier, many of our clients are going through the same process to establish data governance for real estate data. They are taking very different approaches. However, there's one thing in common across all of our experiences. All of us have been making an effort to connect with the enterprise to establish a strategic potential or a firm commitment to support each other. In one case, our clients enterprise data governance team actually was empowered by our clients enterprise data governance team actually empowered the real estate team to redefine the data domains. And the data domains are critical. They drive all the standards, stewardship and other data governance activities. Another thing that's important are tools and shared platforms. You need to agree to converge on tools and share the platforms. Once everything is on a shared platform, it is a lot easier to normalize and eventually standardize. When you negotiate software licenses for data governance, you should invite your counterparts to weigh in. They may even help you to share the costs or chip in. And building enterprise data governance is like any relationship in life. If you find yourself to be the person that's always giving in or compromise or you always compromise, then your consensus or partnership would really not last long. So when there is a conflict, you should always think out of the box, look for a win-win situation, look for a win-win solution. In our experience, many of the conflicts can be resolved by having a flexible architecture in the data solution. That's why we decided to use tool-assisted reference data mapping as a valid way to comply with data standards. Now, after you address the process and technology, the most important task is to find the people. Put good people in the right organization and give them the right roles. As you push forward, set examples, show leadership, but make sure that everyone cross the finish line with you. Now, even if you have done all of that, at times, you would still find yourself doing duplicate work. You have to allow yourself some level of duplicate work, rework, or even a little bit of healthy competition. However, these risks should be known risks to you and they should be acceptable risks. Like our examples of industry code standards and property reference data, we actually knew some rework may be required. You may need to allow some flexibility or stretch your imagination to accommodate the needs from other lines of business. Now, one thing that's also worth mentioning, which is to me quite interesting, is that the lines of business data governance team, if you are successful and you stay transparent, oftentimes these individuals on these teams become much more influential across the company. It's a nice career path for people on this team doing this kind of work. It happened to several of our clients and I guess this is probably the added extent of for you to consider doing enterprise data governance from the line of business. I show you this screen to show you how complex the seven kingdoms are going back to our metaphor with the Game of Thrones. Your organization has similar complexity. But by considering all of the factors that we discussed that are important to a successful program, that complexity can be managed and then success can be achieved. So we say not all systems are there, but by system we need a smaller group. We can look at in this case as the line of business. Those that provide a guide, like we talked about a franchise model to file that you can process, those systems are actually competitive advantages to an organization. So just as your line of business data governance when done correctly can be a competitive advantage for your organization. As we said, what's right is different for every organization. We start to believe that you can do enterprise data governance from a lot of business. In this case you get to do the side for your organization as we have done for ours. We're not saying it's going to be easy, there's going to be challenges, but we actually think that you're going to find a rewarding. You should consider the path of maturity that you have inside your organization and the evolution. Maybe you start here with departmental autonomy and then in about three years you're going to leave you with some parting thoughts, some things to think about, take back home and discuss with your teams. So what are your objectives of data governance? What are you trying to do? Is it data quality, is it data standards, reference data? Are you trying to build an organization with data stewardship groups? Is this your first attempt at doing this? Are you following any methodology or framework already? So what can you leverage inside your organization? How do you sell data governance inside your company? Consensus, compromise, synergy. How do you sell it inside your organization? Get to know your culture. How do you measure success? This is something you should think about beforehand before you even start the program so then you can figure out where you needed to get to or where you wanted to get to. So we thank you for your time. We're going to open it up to questions. If you don't get to ask your questions today, feel free to reach out to either of us. We'll make ourselves available. Thank you. All right. Thank you guys so much. What a great analogy. I still got it so you did good. I like it. What it means is we need to go back and watch Game of Thrones now and say that's how data governance should be. It would be much more fun that way. We did get a couple of questions that came through but there's also been a bit of challenge in posting some of the questions. So if you guys are having trouble posting questions in the chat session, Tony and I are monitoring both areas to make sure we get as many questions as possible out to you guys. We'll certainly take questions afterwards. They are both really, really busy guys. If you also want to, you can filter them through the DGPO and we'll help summarize them or Sean has opened it up to email them directly. If you have any other questions about the DGPO, you can ask there as well. To cover one main question that kept coming up, of course, we will share this presentation, the entire recorded presentation on the DGPO members only site. If you want more information about how to get access to that, please stop by www.dgpo.org and you can get that in a few days. If not, within the week. Right into the questions, if you guys are ready, the first one was interested if you could share what the property types, where you were talking about the different property types, do you have an example of what that could have looked like in a tool and I know right now we are not in a sharing environment, but what type of place do you keep that or narrow a scope and term easily between the enterprise and line of business is pretty difficult. If you can address and work that in there as well on how you do that as you expand and contract in that way. It was a pretty extensive effort in our organization. We had a tool for doing things using Excel. We did have plenty of opinions on what a property type should be. We had a client perspective and from enterprise perspective. I think our initial stance when it was we should come up with the enterprise standard and have everyone take it. We just can't. Think of a concept of a castle. What is a castle? It could be anything. It could be an entertainment center. You may have turned it into a dining hall. It's specific to the client that actually needs to identify that property type. Eventually what it looks like in a tool when we finally had tool to put it in is it looks like reference data. We would have inside the tools different reference data and the reference data is organized by that client or that line of business that actually interested in it. You may have a lot of business standards that they try to put into their client and they may not be able to do it. You may have client standards that they put in there. You will always have another section that says enterprise standards. That's what your BI team would use or anybody trying to do enterprise analysis. You would provide a facility. Those tools should provide a facility. I look at the standards and I look at a specific thing like property type. I should be able to see all of the lower property type in a tool that are mapped to that one property type. I see client A and client B and I see what values they have that they consider to be a castle. We are mapping up the entertainment type. In terms of the tools we use, we actually have a commercial product that's data governance tool that we use to house the data. We actually implement reference data management from that tool all the way to systems so that when a value is changed by the stewards and blessed by the stewardship program, the values in related systems can be changed and we have some pilots that were implemented. For the adoption documentation, the applicability, the user guides, we also leverage SharePoint to publish the standards. Perfect. We have one request to see if you guys can go back to the keys to success slide, about three or four slides back. While you are doing that, we have two more questions that I think we can address in a time. The first is, there you go, there's the keys to success, guys. The next question is, what are the specific nuances of data governance as applied to a line of business versus data governance applied enterprise wide? Is there anything that stands out to you guys that is distinct between the two, between enterprise data governance and line of business governance? And we all have the magic number for the number of data domains we should have in our enterprise data governance program. When I define my scope as line of business, my magic number is probably still the same number. In other words, if we say 14 to 20 is the perfect range for the number of domains you should have in your enterprise data governance program. If I'm doing that in the line of business, I probably wouldn't want to have 14 to 20 or maybe 12 data domains. You can just imagine that all the lines of business start to do their data governance and each one of them has 14 to 20 data domains. At the enterprise level, all of us have hundreds of data domains. That's an example to explain that because your scope is different at the enterprise level. So the work is largely the same but your perspective is the largest part that you have to iron out with the enterprise. One of our clients went back to negotiate with the enterprise to say how about you define the domains for us. I'm just real estate. But within my real estate domain I'm going to define subdomains and the enterprise needs to bless my subdomains. I'm going to make sure we send those over to you but we are at the top of the hour. We've had several people back and forth through technical issues. We'll wish them the best because they're watching you guys from Florida and already getting some technology interruptions. So you guys stay safe and good luck. I'm not looking too good there. With that said, like I said I'm going to pass it back out and get over to these guys and distribute that. With all of that, Tony, I'm going to pass it back over to you to close us out. Thanks very much, Ann. Thank you, Sean. Likewise, let me echo Ann's remarks about everybody who is in the path of the upcoming storms. We wish everybody the best there. Meanwhile, we will be in Eastern with our data analytics and insight series. For everybody who joined us today, we appreciate it very much and your perseverance through a couple of technical issues, we will get those things under control for next time. Wish everybody the best today. Thanks for joining us and we'll see you later. Bye-bye.