 Hello and welcome. My name is Shannon Kemp and I'm the Executive Editor of DataVercity. We would like to thank you for joining today's DataVercity webinar, what CDOs need to know, Foundations of Data Governance, sponsored today by CA Technologies, Makers of Irwin, and Sandhill Consultants. A couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them by the Q&A in the bottom right-hand corner of your screen. We encourage you to share our highlights or questions via Twitter using hashtag DataVercity. As always, we will send a follow-up email within two business days containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now let me introduce to you our speakers for today, Hamilton Hay, Senior Consultant at Sandhill Consultants, and Marcy Barkin, Goodwin, President and CEO of Access Software Designs. Over time, Ham has led much of the evolution of the CA Irwin Product Suite and its supporting education courses. He has provided his extensive expertise in information, process, and enterprise modeling to numerous major North American corporations and government agencies. The focus of his consulting and teaching has helped enterprises bridge the space between technical modeling and business success. Marcy founded Access Software Designs in 1989, a model management services and education company specializing in modeling environments, their infrastructures, and the fostering of communication to ensure successful projects, and has provided education and consulting services to Fortune 1000 companies as well as the government for over 20 years. Access, in conjunction with partner Sandhill Consultants, offers EMSOS, Enterprise Modeling Set of Standards, an infrastructure product which provides blueprints, model templates, and over 25 critical standards, prestige forms and templates for implementing a customizable model management infrastructure. Access is also a trusted CA services partner, offering expertise in model management services to CA customers. We are very lucky to have them both here with us today, and with that, I will give the floor to Ham and Marcy. Hello and welcome. Hi. Hello. Thank you, Shannon. Thank you very much, Shannon. Great introduction. I was going to say, she can introduce us anytime. We're really thrilled to be here with you guys today. Marcy and I have been colleagues and friends for several decades now, and we share a lot of experiences with regard to data process and enterprise modeling and all of these kinds of activities. Of course, I just wanted to acknowledge Marcy because maybe about 15 years ago, Marcy took on the task of really trying to begin to compile industry-based knowledge around best practices and standards for data, and that work has culminated in what we're going to be talking about today, which is that knowledge that we've accumulated, how we put it together, and how we think some of these notions and ideas will be of help to a number of clients and organizations, and especially their chief data officers or equivalents. In fact, let's plunge ahead, and we'll talk about low-CDO and friends. So what is a chief data officer? Well, I think this is an evolving role, an evolving role in an organization. But the standpoint that we look at is that the function of managing data, seeing the design of data that plays into the success of an organization, critical function which has existed as long as certainly I've been involved with enterprise designs and structures. So we think this functionality is bubbling up to being recognized at the executive level as something that merits focus by this notion of a chief data officer. Someone or some process that is, in fact, responsible for assuring that this corporate asset or corporate asset called data is, in fact, properly serving the needs of the business. What we're doing in our journeys here through the information world is, in fact, there are a lot of organizations that are still looking for help in terms of topics around data management and then data concept of data governance. How do we know where we are? How do we know we're on the right path to meet our business needs? I think that we pass on some information that will be of benefit to everybody that serves in that role, whether they have the title or the function. So interestingly enough, when you go around and you ask a bunch of people questions, well, what is data governance? You find that there is no standard definition, which is ironic given the fact that we're really talking about standards and best practices and how you know where you are, how you measure yourself. But there are some similarities when you tackle together various information from definitions from experts in the field and talking to organizations. So there seem to be four principles that come to the fore. The first principle is data is an asset. It's not just something that's expendable. It's not a consumable. It has a lot of persistence. It has to have some integrity over time and space and location. And it is probably, in many cases, the most valuable asset of an organization. It is more persistent than the machines, than the computers. The data is going to be around a lot longer than that laptop that you have or that server that you have, which will generally evolve. We know data does evolve. And, of course, that's principle two, which says fundamentally, we have to keep track of what is the purpose of the data. That is, what is its context? What does it mean to us? The information that we can get from these things that we call data needs to be managed because the environment changes. So business rules change, regulatory environments change, community world changes. If we talk about a concept like customer, we need to understand that we need to manage that concept because it will evolve. And sometimes consciously and sometimes inadvertently or accidentally. And I want to be axle about managing this asset. The third principle is that organizations that don't really define and implement policies around data and data management, they are going to, in fact, be very vulnerable and they may be struggling to succeed. We've seen a number of examples of this. Marcy, you've got one that you were talking about the other day. Yeah, actually, the idea of defining policies to have them govern and to be able to prove, for instance, an audit trail, that kind of situation, I ran into the exact problem. I was working with a customer on Wall Street and obviously a lot of regulations and so forth. And they were required to go through audits, obviously financial audits and so forth. But as far as what we concern ourselves with the data, they were supposed to actually provide proof that they had a handle on what their data structures were, how they were being used, when they had been changed. What the impact of that metadata change was across their different businesses and so forth. And they really didn't have a way of doing that. Documentation for standards and procedures is one thing and we quickly start there. We can get that fully organized, documented, and accessible. But without a way in which you can prove that you have all of that change control and going in is actually working and so forth, that is not at all going to satisfy an audit. So this company was in a lot of trouble. And after we organized it for them, put EMSOS in place and so forth, gave them a structure whereby they could say to the auditors, so here's the day on which we made the change. This is what the impact was and so forth. They passed the audit and in fact I got a lovely email from my team there that said that for the first time in years, they not only passed that data management audit, but they did it in half an hour. So there is a way to manage this and there is a way to prove the effectiveness of the infrastructure and the standards and the procedures and so forth that you put in place. So that's the good news. That's excellent, that's excellent. It says also, it really illustrates the fourth principle event also, which is, hey, ignorance is not a bliss. Funny as we work with clients, what we find is that there's no awareness, but in many cases that awareness is very limited and you really need to know what it is that you have in place, your existence or as is a data management system or governance system. And in your example here, we're getting to an environment which is more regulatory. To many of those regulators, you need to prove what you have in place and that in fact that it is serving the purposes that are needed to manage this critical asset. So if we look at what are the critical factors that are influencing our data systems and we recognize that governance is really a very broad term in terms of the scope involved in governance. It has to operate, governance has to operate as a function in this incredibly changeable systems that we're dealing with, the exponential increase in data, the exponential increase in the volatility of businesses. Things are bigger and they're faster. They're growing at incredible speed. So we're able to respond to the various dynamics that are going on. This reaches up in a number of our experience about organizations that are adopting agile development technologies to meet the velocity requirements of their business changes. And this is now really crashing into some of the more stable data management practices. The data stewards have to and whether they're DBAs or whatever roles that they have, they have to maintain the quality and integrity of their data structures. So the velocity is kind of banging up against the need for integrity and stability. Something that a number of our clients are talking about and trying to deal with. Governance has to comprehend all of that complexity. So some of the aspects of data governance in terms of a framework, we actually want to be looking at data quality, the data management, policies around data, whether they're security policies or efficient sharing policies or whatever. There's also aspects of data in process or interactive. They're mutually interdependent. So you cannot look at data in a vacuum, just you cannot look at business processes in a vacuum. And of course, a lot of the aspects of governance all boil up to what are the risks of the choices that we make, the decisions that we make. So these critical factors are things that the folks in governance and or data governance have to comprehend. The government landscape of governance, if we kind of like parse it up into some of the components, this little pyramid or triangular diagram, some of the major elements that we've seen and experienced with our clients. So we recognize that there's things like business requirements and the measures of business, which tend to be economic measures, not exclusively that. We also see, you know, there's the whole issue of these policies, what we're talking about in terms of governance and stewardship. But there are also other elements that like taxonomy, the organization of knowledge, different organizations organize their knowledge in different ways. We think it may all be uniform, but in fact it's quite variable, not only from organization to organization, but in lines of business. We see significant variations. And some of those were aligned in the past where we had really stand-alone systems, but now being large-scale integration of lines of business in order to meet the economic challenges that Congress is saying. The neatest, of course, is, okay, how do we do business? How do we in the data world do business? What kind of standards and procedures do we need? And most of you will say, yeah, we need something in this nature. The question is really serving the expanding role of our business. The foundation, the ultimate foundation here is really the consumer of data information. We say consumer validator because your customers will let you know if the information isn't very valid if you're not doing a good job and you need to be, again, tuned into that baseline. So we need each one of these components as individuals, but they're also a collective system, and we really, from a governance standpoint, need to make sure we pull them all together. Now, one of them, we've got a fundamentally little details here that says some of the paths that are associated with each one of these categories involve a variety of specific information that needs to be managed and monitored. Think about it. We need policies. We need to understand accountability. We need to understand what our partner roles are. We need to understand what the communications policy is. When we're already talking about governance and stewardship, of course, they all need to come together and have the ability to work in terms of data architecture, design for the enterprise, whether they're a business analyst or whether they're a DBA or anything in between, the consumer included, need to be able to see the map, the landscape, and sort of how all these things fit together. They may not be doing that particular role in terms of what their job or role is, but they need to understand, however, how they interact with these other roles and other elements of the system. So, we're bringing up some of the requirements, Marcy. Yeah. So, in this slide, all of you are looking at my life for the last 20 years, which is why Ram and I are both laughing. So, I think I'll take this one, Ham, if that's all right with you. But we'll go into companies. I've been doing this for a long time and talk about standards and procedures and practices and forth. And it's amazing to me, although it shouldn't be at this point, that when I do walk into a company and I say, you know, give me your meek, your humble, your poor, you know, give me all of your documentation about any standards and procedures that you have around data management, data modeling, and so forth, I'll receive a certain amount of documentation, but it's always, always far less than what is really critical for what the company needs to be able to be successful. When I say successful, I'm saying what is the message of reuse? Are you getting out of your data structures? Everybody is spending so much time on analysis and so forth. If one team doesn't know what the other team is doing, if that information isn't brought forward, if it's not shared, a tremendous amount of time and money is being lost with each model that's being created, it's going to be shared. So when I look at standards and procedures, I say, are they getting reuse? Are they creating redundant data? A certain amount of redundancy is necessary, of course, but are we constantly reinventing the wheel here when we don't have to? So what I see is that folks think that they have standards and generally they do have some. Everybody knows what their naming standard is for an entity or a table or whatever, but that's only really the tip of the iceberg. And when I start to do a real assessment of the environment and speak to people, look at what they've gotten and so forth, inevitably there are many disconnects. There's gaps between how they're using the data, what they think is standardized, who's using those standards, and so forth. That gap, I call it the reality gap, between where you are and where you need to be because my attitude is this. Every company is an enterprise. I don't care if it's a small company or I go up to global companies or government agencies and so forth, it doesn't matter. Every company is its own enterprise and treating data should always be treated from an enterprise point of view, as opposed to the kind of siloed departments or even the siloed projects that we run into. So that gap of what we have and how a lot of people are using it and how are they sharing it and so forth is usually quite large, that's what I've found. So there's only a subset that's being used that has a piece to do with the fact that data governance, although we've used this term for many years, there's different kinds of governance and even in a lot of governance programs that I've seen, sometimes the data seems to be the stem child and that's a shame because there's a huge amount of loose that's taking place in terms of what the company can deliver as a whole if their data is not being taken care of and not governed properly. So my thought is that truly we have all of these issues. The biggest issue of all for me is that without the kind of data governance that we need to put in place, we can't trust the integrity of the data. We can't see when it's changing, we don't know whether I'm defining customer here and it means the same thing across the board or a different line of business is calling a client. We don't know any of this and that affects not only obviously our source systems but particularly data warehouses and so forth. So it's a huge issue for me and that to me is the biggest problem out of everything that I see in the way of issues in the field. So it's important about clearing that up. Okay, take it away. Okay, Marcy. Yeah, how do we know what we don't know? You say, okay, all these points are really great. We really recognize the need to govern what we do, govern in the sense of manage, in the sense of design. We need to do all these kinds of things. But how do we know about doing that? How do we know where we are at this point? Well, we use the concept of an assessment in terms of how we think through this kind of problem. By the way, you can take a free assessment to see where you are, self-assessment. Go to thesanthealkonsultans.com website and look under our standards section. And there's a little online thing that you can take just for you. It's basically based upon, here's what we have found over the years, to be the standards and procedures that seem to keep coming back as the critical core standards and procedures that are needed. And you can just go through and do a check on, well, what do we have in place? And that'll give you at least the first step in terms of seeing where you can be in this. Second question is, how do I determine where I want to go? In terms of, again, managing data and governing what we do. Well, the destination is, of course, really dependent upon your business, your context. It's also dependent upon what are those industry standards and practices that have been proven to help organizations be more successful. A combination of your context. And again, that's a process that, if thought process you need to go through with your organization, that's okay, we know where we are. Now, what's there to be? Where is it that we want to get to? And you should go through an assessment and a little vision planning kind of thing of where we want to go, but we really commit a large amount of resources to implementing your changes in your system. We can certainly, we all tend to, we have an immediate problem. We need to come up with an immediate fix. We may often find ourselves sub-optimizing, just propagating, actually, more of a problem in terms of inconsistencies from the business to the line of business or from IE to business or between our subcontractors and our organization. All kinds of things are, if we continue to do the same small-scale, highly localized changes to the system, we never attack what Marcy calls, you really got to start thinking like an enterprise here. Some things you need to be able to use across your overall enterprise. So, we call this creating a flight plan. This is not every flight in the U.S., there are thousands and thousands of routes in the U.S. under the plan, but the G is kind of interesting because it means that if we want to go from a destination point, you'll know where we are and where we want to go before we choose that route, but that's the next step. So, let's say we want to go from Nirvana in Seattle to Nirvana in South Florida. We identify those two points, the as is being our origin and our to be being our destination. So, we all recognize that there are several possible routes. Some are slower than others and they may have a lot of directional changes. But each one of those represents time that it takes to develop and implement what it is that we want. We may be misdirecting ourselves because we don't really capture a full picture of our case of route. And some of the routes might be a lot faster. It all depends upon how we define and think through the problem. So, the key thing is to understand really what's important to you to your organization with regard to the data. We'll talk a little bit more about this, but I already made reference to it in terms of development speed versus information stability and integrity. So, we all recognize that what is important to you, economics, the time to market, time to development, time is a big factor in everything that we do. Competence, are we ahead of the curve, behind the curve, trying to catch up where in that particular area the other factors include not only those external factors, but also our internal factors. What level of skills and knowledge do we have about developing systems or enterprise and our enterprise data? What are our capabilities? And we'll find some cases where we're maybe going to be short of those knowledgeable resources, both at the implementation level, at the technical level and at the managerial level. So, there are some possible routes. And what we want to share with you is of all of the possible routes, we're finding some very specific research choices that, in fact, tend to be most expedient for many of our customers. So, let me make sure that I didn't advance one slide too many. Yep, sorry about that. If I had a slide number, I'd see where I am, right, Martin? That's why I always say put numbers on them. That's true. There are some notions that we want to emphasize here, tracking your progress. If you identify what's important to you, but you also need to do the same theory of which is you need to track what's important to you. You need to pay attention to your measures or metrics. So, if you want to find those up front, if you know what's important to you, what are your best objectives, everything from schedule to cost, your budget, you're serving your customers, your consumers' needs. Your ability to track gives you the opportunity to identify before you get too far downstream or along your path, whether you've missed something or there's something that you may have had before you leave the assumptions or missing initial conditions you didn't understand. So, having the kind of tracking mechanism for these things is a crucial thing. And we find that, we talked with one customer, said, well, what do you have in the way of metrics? I said, we're talking with your people. They said, well, we don't really measure what we do here. And we talked to the senior management and said, of course we have metrics. I'm looking at my costs all the time. And the point, of course, the point was, what is it that each of your units is producing in terms of data objects? Are they serving the purpose? Do they have to be reworked? Those are important kinds of questions that need to be addressed. We're thinking that there's also some implementation strategies which seem to work well. The first one is designing for interoperability. This is fundamentally boils down to, if I define a data object, say, it's a customer name as an object, as an attribute or column, is it, in fact, the same usable across my multiple lines of business? That's re-use, designing for re-use. And it's re-use, design for re-use, helps us in terms of data and information quality. We wonder that information that needs to be shareable and that benefits the business from being shareable across our multiple lines of business is, in fact, designed that way. We also, you know, Marcy has found a lot of her travels that managing the data lifecycle is a key element. Actually, if you don't mind, let me address this a bit. You know, all of these are key implementation strategies here, but managing that data lifecycle is not something that is generally done quite honestly or really thought about. Pieces of it here and there, perhaps. But not as an overall plan, an overall structure for how we do these things. So, you know, we need things, for instance, like approval procedures. You know, perhaps a logical model is going to get approved before it goes physical, and perhaps that physical model will get, quote, approved before we get the DDL and go live with it. This inadvertent change that happens to data is something that people have not really taken to heart, and it's very difficult to manage data when you don't know when it's been changed or why it's been changed. So, by putting certain procedures in place, approval procedures at critical points or change control procedures, and I'm not just talking about the code. I'm talking about a model-centric environment where we're looking at how does the structure in a model change, and does that structure affect the physical side as well? Does the logical and physical need to be synchronized? Certainly, the database and the physical model need to be that sort of thing. So, a synchronization process for how we know and how we can trust that that physical model, for instance, is really what is in production, and that everything hasn't changed beneath us and we're not aware of that. You know, how do we notify people that a change has been made and so forth? Included in those procedures, we always have roles and responsibilities so that it's easy to know, you know, what am I responsible for? What does this model have to have to be approved? Who's going to do that and who do I hand it off to? That sort of thing. Governments really require accountability, and so roles and responsibilities are critical to procedures. We don't just say this is what has to be done. We have to say who does it and the group does it and so forth. And the last thing I want to say about this changing the data lifecycle is if we don't put that in place, it's very difficult to manage the data when we have changing resources, somebody leaves, somebody else joins. And the organizations that outsource a lot of their modeling have a terrible time if they can't say to the folks in India or wherever, look, here is the way we do it. Here is how we know our data has integrity. We practice governance here. So here, these are our standards and procedures. This is our lifecycle, and this is what we all adhere to, whether we're onsite or we're outsourced. So the managing of the data lifecycle is really, for me, the key to be able to get all of the other pieces working. And that really leads into, again, we need to be aware of what's happening. And that is, we need to understand what is important and figure out how to measure that. We need to monitor that. Measuring is one thing, but if we put the data in a drawer and don't look at it and don't go back into the organization, here's what's happening. Here's what we see in terms of our choice. Hey, we have an initiative to speed up our development process. What's it really working? So we need to measure that. We need to assess the changes that we make so we know that we're on the right path and we're also maintaining or improving the integrity of our system, of our data architecture. With that principles and these notions and concepts, what we'd like to share with you now is a technology solution to consider. We recognize that there's, again, many paths in terms of approaches to implementation of data management, data standards, the governance that overlooks all of that, hierarchical or overarching enterprise of you of what we're doing with regard to data. So let's look at some of the things that we're finding work for a number of our clients. The first thing we want to talk about is this notion of designing for interoperability. How do we, in fact, can we, can we approach concept of what we call error-free design? Well, we think that that is an approachable goal and what we want to look at, of course, is how do we, in fact, design our information structures, our data structures so that they are predictable, they're reliable, they're repeatable. They have integrity in the sense that they have captured the requirements from the business. And what we find is that you need a really good set of technology to be able to do that and then we're convinced that our data modeler is a technology solution that definitely serves that purpose. So we're going to take a peek now at what that really means in terms of, as a technology supporting the concept of governance. So let's look at the concept in governance of designing, of designing design standards that support interoperability of my data structures. Let's look at Erwin and I say, okay, what are the elements within Erwin or the principal elements that support that? Certainly in Erwin, the concept is instantiated of templates for standards so that you can take what you have as a defined naming standard and you can implement it in a template in Erwin that you can use to start new activities, new modeling efforts to upgrade existing models to a set of standards or to use as a comparison tool in terms of, let me take a look at whether any particular model or design, in fact, is compliant with some standards that are key. We also look at Erwin from the standpoint of does it support this lifecycle process we're talking about? Erwin has got a model repository architecture in which you can lay out the structure for storing models and data objects that support the lifecycle. We satisfy things like accountability. Yeah, the roles and permissions in a repository. Can we support audit trails? We can use things like user-defined properties to specify particular properties which are used to monitor progress, accountability, and so forth. And then the category is metrics. What can we do in terms of metrics? Well, with Erwin you not only have standard report formats but you can create additional report formats since you have access to the metamodel that allow you to do things like quantify some of the important parameters that you want to look at. So if you take a look at some of the specific design standards, the naming of certain errors that Erwin instantiates including writing specialized macros that you do a complex naming options or use of glossaries. Equivalent on the data type, you know, master data type standards for your particular relational database systems or custom systems that you wish to develop. You know, it's substantial technology supporting domains and use of domains as part of your naming standards for data objects. And of course things like standardized templates, option sets and things of that nature which we're going to be controlling the generation of DD also. So just design standard areas we see forager and there are other areas within Erwin that support, you know, how do you improve that interoperability in terms of your design? If we look at Erwin's support to data design management we look at the lifecycle process. I would see, as I mentioned, hey, this is an architecture within the model repository. It allows you to do everything from storing templates to a record or baseline models or individual data objects through, you know, a model architecture, standardized glossaries, all these elements basically you can manage and control within the repository. Accessibility, again, the roles, permissions, assigning users to these roles and permissions and controlling what they can and can't do in terms of modification of the objects that are in your repository. Also, as I mentioned, user defined properties, everything from, you know, creation dates to who the information stewards or data stewards was the approval for this particular object or some of the objects, all of those elements can be included in things like user defined properties. Here's a typical data warehouse model involving almost a thousand tables and 16,000 columns. Let's say, well, I don't know how good that is. Well, you know, if you use the ability within Erwin to generate reports, you can do things like standardize reports, modify them, create new reports, which allow you to do things like say, okay, measure how many duplicates are there in this particular model. How many of the tables or columns have definitions? If they're your standards to have a definition and we think it should be, then you can see that, hey, you've only got like 28% compliance on your total number of attributes in terms of having definitions. It can cause some of your operational systems problems if there isn't a definition and it certainly causes you problems over time. From the standpoint of looking at it now from Sandhills Enterprise Modeling Set of Standards, EMSS, where we've compiled this knowledge over an extensive period of time, this is in fact the leading, and it may be the only tool, as many of you know it might be, a knowledge base that has this kind of collection with regard to managing your standards and procedures. So we have questions, things like, from the government's perspective, okay, where am I? That's an interesting question. We talked about that at the very beginning in terms of creating a flight plan. Certainly the same general topics in terms of how does EMSS address things like design standards for interoperability, the life cycle process, the accountability. EMSS addresses each one of the major categories in some detail. You want to kind of reflect a little bit more because you've been the principal architect for EMSS. I think what I'd like to add here is that, yes, EMSS is a really robust, customizable framework and it's got all of the critical standards and procedures and templates and blueprints and forms and so forth. EMSS was designed from a governance point of view. Because that's always our starting point. Without governance, I can tell you to do this and that, but if there's no superstructure, if you will, for how that will be governed, how it will be implemented and so forth, that it really isn't going to help you very well. What I'd like to point out here is that, again, whether you're a small or a medium or a global company, you really must deal with governance issues, best practices and so forth and that's really how EMSS came into being. So, you look with companies such as Pfizer and Wells Fargo, Social Security Administration, Cummins down in Tennessee, all of these companies, these are rather huge, SSA obviously, Social Security Administration is a very large government agency. Each one of the customers that we work with has a different scenario in terms of their organizational structure, who's going to be in charge of this stuff, who's going to do it, what their roles and responsibilities are called and so forth. But the common thread that goes through all of this is that they all basically need the same types of standards, procedures, best practices and so forth. It's a question of how they do it that varies and that's why EMSS is customizable. But we've identified all of the critical aspects of managing the data lifecycle and so forth and that's what's included. The only other thing is, too, that it doesn't really matter what type of industry you are, healthcare or insurance, retail, manufacturing, all of these different businesses, either public or private, need to have a way in which they can get a handle on all of this and to make their modeling environment work for them as opposed to being something with a collection of different odd kinds of models here and there. We don't know whether it represents an enhancement. That's just for an application or whether it's something that could be used later because of a larger system requirement and so forth. So, in the size or the type of the company doesn't matter, this internal infrastructure of the governance and for modeling is something that we're seeing just a tremendous need for and out of all of that, this product was built. So, I just wanted to get into that. Thank you very much, Marcy. So, let's take a peek. Let's open the covers a little bit and just see what it looks like. There's a browser-based technology so that everybody needs to have access to the standards. And it's a set of not only the standards and procedures and forms of basic core content but also is included definitions and examples of things like report formats and documents, templates for the models and things of that nature. So, let's take a quick peek. We're going to talk about blueprints and the data model lifecycle. As a repository of knowledge, it's good for people to understand what their lifecycle looks like and various elements of it. This is just an example of a shared object, enterprise-level lifecycle that involves application development, data development and also the qualification of objects to be shareable across an enterprise. If we look at some of the standards, this is just a little snippet that shows you the detailed definition of what an attribute looks like. If we look at the lifecycle management, say an overlay of that data model lifecycle that shows where data governance roles are played, information asset owners, information stewards. And again, as Marcy said, each organization is going to have a different flavor, but what we have is a core set here that can be tailored for the particular organizational requirements. The accountability, the particular roles are defined within the standards and those roles are also defined in terms of where they play a role with regard to the procedures and all those are defined. And of course, all of that winds up being instantiated in Irwin in terms of things like the roles and permissions within the repository as well as with user-defined properties. Irwin instantiates things like accountability. Let's see what else we got here. Auditrails. You want to manage your audits. EMSOS has got things like change control forms that specify the information or checklists for submissions of objects for approval or consideration for things being a globally shared object. We look at metrics. Irwin has a set of standardized model validation forms. What we do in the standard side is to say which ones are in fact needed for particular needs in terms of the measures that you're collecting. And I showed you an earlier version of a metrics report that just added the number of objects with definitions of the number of duplicate objects in the system. Just the quick snapshot of, you know, there's the elements that are in both of these technologies that support the concept of governance. We certainly see that, you know, adopting an approach to governance, adopting, you know, a methodology, the technologies, you know, the approach like that we would recommend or some other approach, you're looking for expected, some expected benefits. We certainly look for things like reduced investment in terms of being a total lifecycle cost of ownership. We want to reduce cost as much as we can and improve productivity. So to do that, we don't want to reinvent the same object multiple times within a system, and we see that time and time again with our customers in terms of what the past is. Well, the future has to be different. We're not going to be able to reduce costs and improve our productivity. We need to reduce scrap and rework. People who are constantly repairing designs, you know, after they've been in the field, they're just throwing money through the sieve down the drain. We want to be able to improve our resource utilization and our productivity. All these things also focus on getting us to time to market or time to solution to the development a lot faster with a higher level of quality and integrity. The consistency and mutual understanding of using of data and usage across the enterprise we find is core to have lines of business share, information and knowledge across their lines of business and across the enterprise. And this is becoming more and more critical as our systems become more complex and more extended globally. And more mergers. Absolutely. Mergers all the time in terms of a very, very complex task to bring this kind of harmonization and alignment. As we mentioned earlier, the regulatory audit, regulatory environments are getting more critical, more complex, whether it's the financial, pipeline safety, pharmaceuticals. That's the one we ran the other day, vehicle identification number, you know, tracking and being able to track, you know, particular items that show up in the marketplace. Food safety is coming into the foreplay. And of course, things like increased complex, I can't even talk anymore here, increased competitiveness. If we need flexibility in our systems, we need to be able to turn the data architecture and the application architecture to be able to enhance those or modify those to meet the changing marketplace requirements. And that's always always at the end of the day. If we lose our data integrity and we lose our ability to share information, it's going to have a tremendously deleterious effect on the success of our business. Yes, design and distribute our data hopefully in a shared environment. And how we do that is really critical to the success of not only the modeling environment, but the larger overall governance objectives. So it really starts at home. It starts in the specific way in which we tackle looking at our data, using the data and distributing it. That's all about that. I want to leave a couple minutes, you know, a few minutes for questions. And just to note that if you send questions that don't get answered in real time, we will respond through e-mail and so forth. So how it started. Well, we talked about that. Take a little self-assessment that's available in sandhulaconsultans.com. To drill in a little further, we'll be more than happy to talk with you about approach to data governance. It might be right for you. And we're sure that we're really confident that you can benefit from these kinds of discussions. And we also offer in-depth price modeling assessments as well that we can talk to you about. So, you know, in conclusion, we've got everywhere you want to go. And of course you've got to know where you are. But if you don't understand your business context, you stop right now and go back and find out what your business context is, because that ultimately is the driver. You know, those of us that are in IT or in government functions and things like that, you know, ultimately it's still a business generating the revenue and the dynamics that are important. So know where you are. Know where you want to go. Create that flight plan to get your destination. Begin self-assessment. If you really think that there's things that you need to do and want some help on, so today that's really the important aspect. The question, I'll turn it back to you. We really appreciate being able to talk to you folks. Questions? We have a few minutes. We'll try to respond. Okay. We have several questions that have come in. And of course some of the common questions are people going to get copies of the slides. And yes, we'll be sending out a follow-up email within two business days also by end of day. Thursday with links to the slides, links to the recording session, and anything else requested throughout. Including if you keep, and I just have a couple minutes left here. So if you keep submitting your questions, Ham and Marcy have graciously offered to write up answers and I'll get those out to you in the follow-up email as well. So keep the questions coming. The first question is how do you deal with senior, A, senior management buy-in, and B, data quality issues, and other common issues in the field to get data governance in place? That's an excellent question because it's really an educational question. You know, senior management, if you are serving in this role, you'll be able to speak the language of business. You may not have those that skills and knowledge fully. So you need to, you know, get them from colleagues or from patriots that can help you express the best value of governance. Because fundamentally they're going to say, you know, we're going to have to fund this and you've got to show me where it's going to pay off. And so there's the conversation you need to have with business and it'll make you a little while to develop that. But it's doable. We help our customers understand how to express the importance of doing this. I think intuitively we all know it's valuable. The point is, is it how much of a priority is it? Do you want to add to that? You deal with CIOs all the time to kind of explain this. And this may sound conceptual, but it really is to the heart of it, which is that if I explain to a CIO, look, you've got all of these people spending all of this time, which is money to do all of this analysis and so forth. And if you are not getting reasons out of that, you are spending a general time and money that is completely unnecessary. It's more expensive to fix something than it is to do it right from the beginning. Now, I've been in the business long enough to have a certain amount of reality. I'm not trying to be a Pollyanna here, certainly not. I've been on the battlefield for a long time. However, if I have a project and it requires a data model, and at the end, and I have procedures in place to say, hey, these things now are considered shareable. Why? Because they have integrity. They have definitions. They've gone through approvals and so forth. At that point, if I make everyone aware of the fact that, hey, guys, we have these data structures, we can reuse these. I don't care if you're using different databases or whatever. I can start with these on the logical side, make sure that I'm satisfying the business requirements, and then do what I have to do to implement that in different physical ways. That's fine. But if we all go back and work with a structure that already exists rather than spending a month or whatever it takes to re-creating that as if it didn't exist, you cannot tell me that that does not save you time and money. That it's just the way it is. And we can do much more detail than that, but if we want to start with just that premise with a CIO, they get it. So you do have to address the bottom line. You do have to address us, and we bring metrics and so forth and so on, but conceptually, everyone in the upper-level management for the most part will get it, and that's where the discussion starts. And I'm pretty sure we're just past the top of the hour here. Thank you to MMRC for this great presentation and Q&A again. I'll get to all the questions that we didn't have a chance to get to, to you guys so we can get that out on the follow-up e-mail. Thanks, everybody, for your questions. I just love always, of course, when you guys are so interactive and really participate in the webinars. And of course, another big thank you for today's sponsor, CA Technologies and Sandhill, who, of course, enabled us to provide these great webinars to everybody for free. And just to remind everyone, again, we will be posting the recording and the slides to DataVersity.net within two days, and I'll get that follow-up e-mail out to you as soon as those things are up. And a quick thank you from Ham and I for everybody who attended. Thank you, everybody. Absolutely. And thank you guys for this great presentation. It was very engaging and I think everybody really enjoyed it. So I will give you guys that information and I hope everybody has a great day. Thank you. Bye-bye.