 Hello and welcome. My name is Shannon Kemp and I am the Executive Editor for DataVersity. We would like to thank you for joining today's DataVersity Webinar, Data Systems Integration and Business Value Part 1, Data Data. This is the first July edition in a monthly series called Data Ed Online with Dr. Peter Akin, brought to you in partnership with Data Blueprint. We'll give the floor to Megan Jacobs, the Webinar Organizer, from Data Blueprint to introduce our speaker and today's webinar. Hello everyone and welcome. My name is Megan Jacobs and I'm the Webinar Coordinator here at Data Blueprint. We are proud of you guys have found the time to join us for today's Webinar on Data Systems Integration and Business Value Part 1 on Data. As always, a big thank you goes out to Shannon and DataVersity for hosting us. We'll give you just a few moments after I let you know about some housekeeping items and introduce your presenter. We have the floor for the presentation followed by 30 minutes of Q&A. I'd like to try to answer as many questions as time allows, but feel free to submit questions as they come up throughout the session. As for the top two most commonly asked questions, you will receive an email with links to download today's materials and any other information you request during the session within the next two business days. You can find them on Twitter, Facebook and LinkedIn. We set the hashtag DataEd on Twitter, so if you're logged on, feel free to use it in your tweets and submit your comments that way. We'll keep you posted on Twitter feed and we'll include answers to those questions in our post session email if for some reason we cannot get to any of the questions. Okay, so our presenter, Peter Aiken, is an internationally recognized data management thought leader. Many of you already know him or have seen him at conferences worldwide. He has more than 30 years of experience and has received many awards for his outstanding contributions to the profession. Peter Aiken is the founding director of DataBooPrim. He has written articles and eight books. The most recent is the case for the Chief Data Officer. The best practice is through DataVersity's bookstore, so you receive information on how to do this in follow-up emails. Peter Aiken's experience with more than 500 data management practices in 20 countries is consistent and is a top data management expert. Some of the most important and largest organizations in the world have sought out his and his friends' expertise. Peter Aiken has a year of immersion through groups as diverse as the U.S. Department of Defense, Deutsche Bank, the United States of America, Wells Fargo, the Commonwealth of Virginia, and Walmart. He also has conferences and is constantly traveling. So where are you off to today? I'm off to Columbus, Ohio to meet with the data chapter out there, Megan. And thanks and welcome, everybody. It's good to be here. Our topic today, as I said three times already, is data systems integration and business value. And the real key to this is that most people tend to look at data systems integration, call it data fusion, whatever it is that they're going to call it, and think it's a technical problem, but it's actually a problem of business value. That's what we want to take a look at today. As always, we have our overview, where we're going to talk about data management in general to help ground us in the same context. So we're all starting off on the same piece of paper. Moving to what is metadata and why is it important? We'll then talk about major metadata types and different subject areas, not all of which will be important to everybody, but it's important to know the possibilities that are out there. We'll talk about the benefits of metadata, particularly two integration scenarios from an applications and sources perspective. It is important that you approach metadata in general with a strategy, but that each project also needs to have a strategic intent as well. We'll talk about the building blocks that we use to create metadata value out of this, get to some guiding principles on this. And I like to finish this particular webinar with a specific teachable example. And the reason for that is because while we are online here we'll hopefully be very familiar with metadata and the concepts by the end of the hour-and-a-half discussion that we're going to have, it's very important that you have something that you can show people very, very easily because oftentimes you'll need to make an elevator speech about metadata. So I'm going to give you an example relating to iTunes because most people are familiar with iTunes and talk about it from the context. And hopefully you've all seen this. We're starting a terrific debate here in the US about whether getting metadata around your phone calls and emails is a problem or not. We're going to be having that discussion ongoing over the next couple of years, I would assume on this, but this will help you to make a better participant in that discussion. We'll finish again at the top of the hour with takeaways, references, and move to our Q&A. So let's dive in for our overview where we start every one of these webinars out, which is that most people are unaware that data management is a combination of five integrated data management practice areas. This is the eye chart that is designed to make your eyes crossed. Don't try and read it at this point. If you'd like to go through it in more detail, give me a shout and I'll be glad to walk through it with you. But for the management overview, there are five data management practice areas. The first one is data program coordination. It's the idea that we need to measure data coherently. We need to all be singing off the same piece of paper. Let's grab these webinars in the first sentence of it. The second is organizational data integration, the idea that we need to share data across boundaries. Whether these boundaries are going from program to program from part of our organization to another part of the organization or between our organization and our partner's organization, it needs to be done in a controlled manner, in a governed manner, if you will. The third data management practice area is data stewardship. This is the idea that unless we make it personal, it's going to be everybody's problem, which usually means it's everybody else's problems, and that's not helpful at all. We are also made to engineer data delivery systems. This is our fourth area, the idea of building delivery systems out there. And again, our problem in this area is that our colleges and universities, and I'm a college professor at Virginia Commonwealth University, do not teach people anything other than a relational model. High school people are not able to make good decisions about things they do not understand and that they don't know what they don't know. And so our fourth, excuse me, fifth area, the data management practice area is data support operations. We have some other topics that we're going to dive into, webinars that are going to dive into these topics as well. But the, all come down to understanding basically a piece that I'd like to say is like Maslow's hierarchy of needs. Many of you remember Maslow from your high school, which is the idea that if you don't have food, shelter needs, met, it's unlikely that you're going to sit down and write a great novel at night. You're going to be instead concerned with moving to the mat or on met, the food, clothing, and shelter needs. Maslow's hierarchy needs, we're only attainable after you first satisfied the needs below that. And in data, we want to talk about exactly the same thing. Our five data management practice areas provide building blocks. They are necessary but insufficient prerequisites to leveraging organizational data, which is our version of self-actualizing. So if we put our five data management practice areas here at the bottom of the pyramid, they are necessary but insufficient conditions before organizations try to do fun things like cloud, MDM, big data, SOA, et cetera, et cetera, et cetera. Each of these areas are important, and you can do them without doing the others, but if you're trying to do things in that green triangle without doing the foundational work first, you can do so in a way that will take you longer, cost more, deliver less, and present greater risk to the organization than would otherwise be encountered if you did the proper crawl, walk, run scenarios. Again, our guidance here is from the data management body of knowledge, and we're looking specifically at metadata management here, and we would like you all to use these topics to become more prepared to pass the CDMP and familiar with the data body knowledge. Again, about 1,200 professionals worldwide out there that have passed the CDMP, and we're seeing increasing requests for it as we get organizations that come to us and ask us to help them find people to fill positions. So a data blueprint is not a staffing organization, so we don't do this, but we're going to make connections and link things together. The data management body of knowledge does have a chapter on metadata, and this is the overview slide for that chapter. It's in the form of an hypo diagram. You can see the inputs on the left-hand side, the activities in teal in the middle, people and partners below that, and then the deliverables on the outside. That's sort of a framework for how we're going to be working in here. So let's move to the next one. What is metadata and why is it important? We're going to start off here and give a little bit of a piece. I think this might have been Jerry Rosenbaum that gave me this language, but I forget who actually it was, but maybe it was Gorman. In the history of language, when two words are pasted together to form a combined concept, initially, I hyphen-formed them. So we started out by saying metadata. But over time, the hyphen gets lost, and that's kind of a good thing. There is, in fact, a copyright term on the word metadata, but it's not possible to enforce it anymore than it would be if Microsoft copyrighted all the errors in ones on place. So we're going to refer to it from this point onwards as metadata without the hyphen. That's the preferred way to do it. It makes sense to do it that way, and it doesn't make sense to put the hyphen in it anymore. So metadata is everywhere in data management in every data management activity, and it's integral to all IT systems and applications. It is pervasive. Data is to data. What data is to real life? If I also talk about the number two, that is a relevant statistics for some people, but other people may not know that 42 is actually the meaning of life. It's also my age 12 years ago, but that may or may not be relevant to you as well. So again, these are facts that are represented out there. Data represents the real life transactions events. The metadata represents reflects the data transactions, the events. So in order to properly manage data, you must manage metadata. That is, metadata describes the structure and workings of an organization's use of information. And these describe the systems that use to manage this information. Here's a couple of guarded definitions. The first one is OK. The second one is better. The first one is data is describing very facets of the data asset for the person of improving its usability throughout his life cycle. And while that was useful, they came up with a better definition that I really like. Metadata unlocks the value of data and therefore requires management attention. I bolded that for you. Please use that and give Gartner good credit for coming up with a terrific definition there. Metadata unlocks the value of data. If you don't know the 42 that you're asking for, whether it's my age, excuse me, 12 years ago, or whether it is the temperature outside, it's going to make a difference there. So we can now define metadata management as the processes ensuring proper storage integration and control over the associated use of metadata. And the place that's a good place to start in terms of metadata is to think of a card catalog. Now, those of us that are on the card here tend to be mature in our perspective on data management. We find that people have to be in IT for at least 10 years or so before they really get it and discover that, wow, this data stuff and this metadata stuff is really important. But we can still talk to things. This is the idea of your explaining to the kids that in the old days used to go to the library and they go, why did you go to the library? And so that's because where the books were. Books, what were they? I mean, you can imagine in the future it's going to be very different. But how do we manage a library and we did it through the card catalog. The card catalog tells us what books are in the library. They can search for books by subject area, author title. It shows the subject, the tags, the publication dates, the revision history of the book. The card catalog information helps us determine what the readers or the researchers were looking for. So when you go to the card catalog, you would write some stuff down and then you would go look through the stacks. Boy, are we glad the internet's here now. Without that card catalog, finding the books in the library would have been practically impossible, but we were able to make it work for many thousands of years before that. You find the same books. You may find the right books. You may find that the catalog information in there is incorrect, and that's of course what we're trying to do with metadata is the card catalog for our managed data environment. These are the descriptive tags that tell what the data is. In other words, if we go back to my 42, we want to say Peter's age. Okay, now we've got it. Metadata tells us about information that is useful to business and technical users, and perhaps where to find it. We'll look at actually a lot of things that Medicaid can do as we go on it. It tells us where data came from, how it got there, and the transformations that are leveled, perhaps its quality, all kinds of things can be associated with just that lowly number 42. Again, it provides assistance with what the data really means and how it should be interpreted. If I'm going to try and buy alcohol in the state of Virginia, alcohol I can buy at age 21, so they would do some sort of calculation to figure out that my age is 42, my age is 42, I was 12, and then add to it and come up with a way of figuring out that I'm, in fact, old enough to buy liquor in the state of Virginia. There's a representation of metadata that my colleague Brad Melton came up with, and I appreciated this insight, Brad, that you had. There's any combination of any circle and the data in the center that unlocks the value of the data. So if we're answering the question, who, how, what, where, when, why, these are all metadata about that 52, or 42, excuse me. Again, why? Well, drinking age, what? It's an age in years rather than an age in weeks. Again, you can add all sorts of flavors to this. I think it's a really nice articulation of how to describe metadata. If we go back to our library example then, we can put a library book at the center there and say who, the author, the what, the title, the where, the shelf location, the when, the publication date. All of these things are going to be helpful. A very small amount of metadata, the card catalog, unlocks the large amount of data in the library there. One more step further. So maybe you use Outlook or some sort of email client that you're doing. And Outlook also uses metadata to help us navigate and manage our overflowing inboxes. Again, if we drop our email message at the center of it, I want to go back and think how difficult it would be even if you are a good Gmail user to do searches through your email without metadata surrounding that. Let's take a look at an Outlook example here. Again, we've got to, who, and from, right? What is the subject? How? Priority? Going into an inbox or a personal thing. Why? It's the body of the message when it was sent and received. So all of this metadata is used. And the fact that we have overflowing email boxes use this metadata to find the important stuff and we help us stuff that's less important and organize it for future access. And sometimes we will actually create rules in Outlook that say when my boss sends me an email message, go ahead and send me a text as well in case I missed the fact that it's an email message. These are the ways of using metadata around that. Now, let's talk about the structure of metadata practices in here. This is, I think, a fairly important slide, so I'll spend a minute on it. Again, if we say, what do we mean by our metadata practices organization? Well, the first thing that has to come to mind is that we need specialized team skills. Even if you're knowledgeable about data, it does take additional information to learn and understand how to use metadata, and that's because it's composed of this process of connecting data sources and data uses in an organized and efficient manner. Another way that people use to describe this is in a programmatic fashion, so you're not dependent on having a person in the loop in order to do this. Again, we use this typically through a storage of metadata, and we can talk about glossaries or repositories, models, things like that. We'll actually deal with some of those when we get into our technology module. That's not this time here. But there's a precursor to that, which is an engineering precursor. And if you haven't had an engineering background, you won't be able to understand how these concepts can be helpful for you. Similarly, you need to have a background in delivery. That is, design of information delivery systems in there. So not just storing the metadata, but using the metadata engineering to create the proper storage and the proper delivery mechanisms. And all of this is surrounded by metadata governance. So when you are speaking about data governance, you are also speaking about metadata governance. And when you execute this metadata practice, the engineering and the loop functions here implement the governance functions of your organization. This is critically important. And here's a chart that we use to help illustrate to one group how metadata practices are inextricably intertwined with many other things that are happening. We're just showing three of them here, data quality, master data, knowledge management. But you can see I've taken that metadata practices area and connected it in there with everything else. Again, one of the reasons we do this is so that you guys can take this material home and use it for yourself. This is not how you should build it, but this is how you should illustrate it. And we are interested in your opinions as well. So we're going to move to our first polling question. Those of you that are joining us for the first time, know that we ask these questions periodically so that we can keep running track of how these things are going. You tell us that when the organization began using or is planning to use a formal approach to managing metadata this year, next year, or not at all. Megan, I'll leave the thing open here for point sets. That's a metadata that Shannon has told us gives us an optimal response time on this, and let's see what people say. We have responded. I'll go ahead and close the poll. 30% said last year. Let me see if I can... We'll publish it when we send out the emails, right? Sure. And then B this year, 2013, 13% said so. November, 2014, 14% said so. December, 2015, 15% said so. All right. We're working on getting us to that stage and letting us have time to understand this. Thanks, Megan. I'll start with the types now. Again, different types of metadata. I'm going to go a little fast on these just to give you some ideas of what they are. But most people don't think of process metadata actually being in there. And one of the most important components of process metadata is whether or not the process model exists or not. I don't know how many of these exercises you all have been in, but many times as you'll do a process modeling exercise, the results will end up in a binder somewhere, and it'll end up on Megan's shelf. And that'll work terrifically. As long as Megan is still in the same office, you'll know where to find it. But when Megan decides to move to another job, get promoted or win the lottery or something like that, where does that metadata go? So lots of these components go into this business process metadata. Again, if we look at it with our little spark analogy here, we are looking at who created the documentation, what are the important dependencies among the processes, how do the businesses in their business processes interact with each other. Just different types of metadata. Here's some business metadata examples that we have. Again, what we're looking at from the business perspective, this includes the business names, the definition of the subject areas, date ranges, data types, domain values, all kinds of things that are in there. Here's some other metadata, technical and operational metadata. Again, if we look at technical metadata, it's the physical database properties. So where do I actually find the value of 42 that I'm looking to obtain in there? Operational metadata is targeted at IT operations, so job frequency, recovery and backup coverage. When do I have the most recent backup of this? Technical and operational metadata might include audit controls, data archiving and retention rules. Your data retention policy is an example, is an exercise of metadata. Results, things like that. All of these things are critical. Here's another category, data stewardship. So data stewardship metadata is all about the responsibilities of the stewardship, how broad their responsibility is, what types of instruments do they have? Are they able to make sure that their data is in fact improving? Are they established good, active monitoring and preparing? I've got this up here, CRUD. That stands for create, read, update and delete. In other words, which people have which permission to do which things, to which data items. Lots and lots of these types of topics that are in here. Here's a particularly interesting topic, something called provenance. Again, this is the history of the metadata. So if I told you that 42 came from my fake driver's license, now you would have less hopefully confidence that it was in fact an accurate description of age. I assure you I am well above the drinking age. So again, for each data item, provenance items can be included as their sources, any derivations, dates that were created, the programs that created, who would be the owner, a perhaps responsible steward, what type of rules would govern the sharing of that data as we look at it. Again, there's lots of these areas. I'm not going to go through each of them. Here are 16 more areas, analytics, architecture, definitions, data governance. I'll show you here that there's actually more metadata than there is data. That's a little bit of a scary thought, isn't it? More data than there is data. So when they say things like the government is only collecting metadata and not actually collecting data, I might give you a little bit of a cause to think about things here. Let's look at the benefits then. I've got seven major benefits of metadata here. Again, the first one is, as Gardner correctly says, increasing the value of your information by providing information that increases its ability to be used. Metadata can also help you reduce training costs, lower the impact of staff turnover through various types of documentation, history, origin, and usage type things. It can reduce the amount of research time, and by this we mean that when we're looking at solving problems, we tend to spend 80% of our time researching the problem and solving the problem. There's a Dilbert where when you hear a boss say, Alice, I noticed that whenever you do your problem solving, the last thing that you try always works. I want you to get better at it. It's a very funny Dilbert that goes in there. Metadata can help improve communication so that people literally are on the same sheet of paper. It can increase development time markedly. Particularly those of you that are in agile shops, if you're trying to do agile without first pre-defining your data components and having metadata ready to go, then they can only slow down your agile. In a proper metadata environment, it increases at very, very high rates. It can reduce the risk of project failure, and finally it can help us to identify data rot. That's data that's redundant, obsolete, or trivial, and if data is obsolete, redundant, or trivial, then why are we managing it at all? So these are just some benefits that we have around here. There's also, of course, structured data. I tend not to like the term semi-structured or unstructured. I prefer tabular and non-tabular, but it's in popular use, so let's just make sure everybody is, again, grounded in the same place. It's data that's not in a database or data file, includes documents or media files, voice, things. The recording of this webinar will become a non-tabular piece of data. Of course, it's not non-structured. It does actually, in fact, have a structure. You can use metadata to describe both of them. In structured format, you may look at it in terms of content management, different university websites, internet sites, data archives, all kinds of things that go out there allow us to do this. And these way of classifying metadata is to describe them as descriptive metadata, structural metadata, or administrative metadata. Let me take you to each of those. Again, administrative metadata would be the catalog information, the fessori terms that we're looking at. The structural metadata would include things like the Dublin core, the field structures, the formats, the XML schemas, etc. So for those of you that are unfamiliar with the Dublin core, this is the base for most of the library metadata. The speech that I'm going to make this week, a group I'm going to be visiting with, will be meeting at the OCLC in Columbus. And looking forward to that, it's a terrific venue, and I enjoy working with the folks out there on that. I did have FOPOT at one point in time. I was in Dublin. I was actually in Dublin Island, and I was hinting around that I had never been to Dublin before, and I was wanting to get an invite. I still haven't made it to Dublin yet. And somebody found me with their hand, and that would be Dublin, Ohio, you want to visit, not Dublin, Ireland. So it was a particularly challenging day. By the way, that's metadata too, isn't it? And the sources, the updates schedule, the access rights. What page relationships do we have back and forth between site navigation, things along those lines? So these are some of the metadata things. Let's look at a specific example on this. Here what we have are four metadata sources. We may be looking at existing reference models that your organization may have purchased. For example, ADRM is a reference model for retail organizations. There may be a conceptual model that was created with a couple of you that you may be using. There may be some existing systems that need to be reverse engineered, and there may be an enterprise data model, and all of those need to be integrated together, and that is metadata integration. Very important on that. So in this next section here, I'm just going to go very briefly through as we move into strategy and implementation. There's a little bit of history in here that was put together. It's a terrific little piece. I'm not going to read you all of this, but the idea was in the early 90s, we originally thought metadata was a pretty narrow definition. And we talked about whether the databases existed in the fields or on that. But managers began to recognize the value of the various repositories that were involved in it. They were seeing things like reduced train costs and things like that. And that allowed them to become a little bit more recognized on this. The real key came in the early 90s. I was at the Defense Department working for something called the Defense Information Systems Agency. And one of the tasks that we were working with there, in addition to supporting the war fighters, was the Y2K deadline. And that helped people start to realize the value of metadata because if we knew all the two-digit dates, we could go around and change them to four-digit dates. But, of course, if we didn't have them, it would have been much more difficult to do that. I'll point out another little piece that came out of that as well, which was that we were going to buy case tools for the Department of Defense. And as part of some of that research that came out of there, we were able to develop this thing called the Case Deception Interchange Facility. This was the idea that we could exchange metadata between case tools. This eventually morphed into some other things in here, and we'll touch on that a little bit later with the Common Warehouse Model and XMI, XML-based metadata interchange. Also, the first part of ISO 1179 was created in that time as well. Again, as we move forward, people are really understanding that metadata has value, but we're also seeing it's a non-trivial effort. It does require some people with specific skills. And we do need to see a very much rejuvenation of the tools market in there because we have many of these systems, but we also have some modern needs, and the organizations that are putting these tools are working very hard to try and address these. It's just being driven largely by regulatory issues. Again, groups that are paying attention to Sarbanes Oxley or Bodle Zool 3, depending on where you are, are paying a lot of attention to this as well on this. So let's do a couple things here, though. Again, here are some examples from the EFF on why metadata matters, and I'm not going to read each of these to you, but these are clearly, even though we don't know what the content of the call was, if we have the metadata surrounding the call, we at least have an idea of what we can triangulate the call into. So again, thanks to the EFF for pulling that one together. It's a very interesting list, and again, we'll hopefully contribute to the wide debate that we have to have on this. What this means is, hopefully, you can see we need a metadata strategy, not just at the organizational level, but for each project. How is metadata going to be used in this project? In fact, you can really get a little bit further than this and say that there is not much out there that isn't metadata. So I know it's a little bit confusing, but we really do, if you think about it, metadata is data, so we would manage it using data management techniques. So metadata is really data. Therefore, metadata doesn't really exist. Boy, if that's trouble, let's come back to that at the questions and answer pieces. But it is important to build a metadata strategy and decide what you're going to include in the scope of your metadata management efforts instead of arguing whether something is or is not metadata in there. This will give you an idea of what the organization is attempting to do and what your requirements are now and in the future. Our measurements show, however, that only one in ten were able to have a documented, board-approved data strategy, and consequently the metadata strategy becomes really programmatic, which leads us to our next question here again. And Megan, if you can put that one up, we were interested in your perspective, compliance laws, how much have they influenced your versus into data quality, metadata, database management in general, or had no impact in general on this? Everybody put some time here and then show the results to you. Oh, there we go. That's appropriate. Ramon's going earlier, but probably that wouldn't be as appropriate. It looks like, give us time so we can see if we can show them. Well, I guess it's not. I'll read them off to you guys. So, for 89%, that's all that data quality improvement efforts. Dispense for metadata management efforts. Wow. 27% for database management in general. And for no impact, we have 13%. Very good. We keep track of these over time, and so what we're doing is sort of tracking the awareness in these areas as they go onward. So, Megan, we go onward here again in terms of our, the data implementation here. The idea, of course, follows a normal planning cycle, which is that you have to say there's a strategic implementation in the planning phase. You're going to conduct some stakeholder interviews. You're going to make sure that you have access to the metadata sources and the information architecture components that are relevant to it. Develop what your future metadata architecture should look like, and then develop a phased metadata management engineering implementation strategy and plan in order to move onwards on these. Each of these phases are important, and the most important people mess up on is that they try to go too big instead of focusing on this. This can be done at the project level. If you do it a couple of times successfully at the project level, then you'll find it'll be easier for you to move onwards up into the organization-wide level instead of trying to do it top-down. So, let's get some metadata building blocks. I'm going to pull in question up on you, so don't wrap quickly here. Let's look specifically at the goals and principles. And the idea is we want to provide organizational understanding of the various terms and usage. One of the things, for example, I try to urge all of my customers to do is to never use the word customer when they are referring to a concept as broad and as ill-defined as abstract as a customer. For example, at the university, a customer of the university would be any taxpayer or any citizen of the Commonwealth of Virginia. Well, that's not going to be very helpful. And one of the things you need to do is to start talking about types of customers. We may have current customers. We may have past customers. We may have future customers. We may have potential customers. Almost all of you are going to need a qualifier on these large abstract terms. We want to start to be integrating metadata from the various diverse sources. And this is particularly true when you're looking at integration projects. When somebody says, I'm going to integrate data with place A to place B and they hand you a spreadsheet, you should be saying, ah, it's probably not the best way to go about the process is meeting what's actually in there. A better way to go about that process is in fact to look at the data and see what is in fact in there. This is where we can provide easy integrated access to metadata and ensure that we have metadata quality and security. Megan, here's our third tracking question here. When you guys started to use Repository, either purchased or homegrown. There's another song. So if you're ready to go, Megan, we'll take Miles Davis back off. All right, looks like we've got about two seconds left for us to submit their answers. And Shana's the one that did the studies on this as the editor of Dataversity. She knows it's leaving it out for 0.7 minutes. Gives us the optimal response rate. Keeps you guys on your toes. Gives us good responses. All right, and here I think we can show the results, like 30% said 2012 or last year, 15% said that year, 11% next year, and 12% said that it's not applicable. Okay, and we're seeing increased usage in these areas. We'll go back and pull them together and come up with some more useful statistics. But thank you all for your help in that. We've got one more polling question coming up in a little bit. The activities surrounding metadata are, of course, understanding the metadata requirements, defining a metadata architecture, understanding how to apply standards, implementing them into a nice environment that people can use, creating and maintaining the metadata, integrating metadata the same way that you integrate data, using some form of metadata repository-like functionality. I'm not saying that you need a repository, but that you can use something that works very much like one, and delivering and distributing metadata and then reporting on the metadata usage. In particular, it's appropriate to look at standards. And again, we have industry consensus standards versus international standards that we have to take a look at. And it's good for your organization to develop a high-level framework to tell how the standards are related and how they rely on each other as you use them back and forth. Here's a couple of them that you may encounter, those of you that are in the warehouse world. There's something called the Common Warehouse Metadata. It's evolving to a new standard here, which you're seeing now, the Information Manager MetaModel. This is work that's being done by the Object Manager Group. We're really, really trying to integrate all different types of metadata in here. Business, modeling metadata, technology metadata, modeling metadata, and making it compatible with the semantics of ontological components, basing it on a core model so that you can use this model to translate something from one to the other. This is fairly sophisticated stuff. And if you're into this, congratulations, you can see from the statistics here there are still some companies that are just getting started in this area here as well. Again, what are the deliverables, your various repositories, the metadata quality, the quality metadata that you have, the analysis of how it's being used, where did that number come from is a question that many executives ask. They're asking the question of data lineage in there. What about change in impact analysis? When you look at how these can be implemented overall, this impact analysis is one of the best ways to keep you from having problems. We'll not get an exercise that we did at one of the banks in New York City at one point, who's our CEO here at Data Blueprint, was in charge of a project, and they said, well, we haven't got time to do it right, so we're going to go ahead and put it out. And Louis said, well, if you do it, it's going to cost you money. And it turned out we were able to measure the amount of overtime that we ended up having to pay over the next couple of weekends to correct the problem. So again, having that change in impact analysis can help you, you can say I told you so, but more to the point, what you really want to do is be able to say hey, if you do it this way, this is the potential cost of the organization will incur. Our overarching theme here is we're looking at these data integration projects and how these things fit together and how they produce larger business value out of this. Again, the metadata control procedures put in place can significantly reduce the overall impact of these various technology changes and components as we go into this. Again, problematic in many ways, but most organizations just don't spend enough time and attention, paying attention to the models and the architecture on this. We talked a little bit about the models in particular here too because these models are really, really important and they're not something that you have to do an awful lot of work to get. A little bit of reverse engineering might work. Some of the books I mentioned, David Hayes' book a little while ago, Len Silverstone and David Marco both have good books that come with predefined metamodels in there so that you can compare and contrast on the theory that is easier to edit and critique than it is to create from the very start on this. Again, if that's unclear, we can say that for a question at the end. The roles and responsibilities that we're looking at from a metadata perspective, everybody's involved. You've got your suppliers, stewards, architect, modelers, administrators, data professionals, brokers, and industry regulators that are involved, participants are the specialists, the integration architect, stewards, again, architects, modelers, administrators, and business users in particular on this. And then the consumers of the data, which also, of course, include everybody above, but the business users in particular. From an industry perspective, you'll hear the word metadata repositories. I think this is the fourth time in this presentation that I've used it. I want to be real clear. There are some very, very good tools out there that the role of maturity that an organization has to have in order to use them has tended to be high. So what we like to do is instead skip it along the lines of buying a little pet when the kid comes in and says, I want a dog. They have these little electronic dogs that you can buy now and you hand the kid the dog and if they don't feed the dog and take it for a walk and play with it, the dog actually turns itself off. Many of these metadata repositories to the vendor chagrin tend to shelf wear because people are not able to use them. They're not mature enough to use them. So we'd like you to, again, crawl, walk, and then run develop an interim repository-like functionality. Build that little electronic dog. Get to know what it's like to take a dog out for a walk two times, three times, four times a day before you decide that you really want a pet of that sort. If you've never had one before, those of you that have had them, you can provide some guidance to this. Again, this is one of the things we want DAMA to be as a forum for these types of activities. Obviously, category of tools are the various data modeling tools, database management systems, almost all will now report their own metadata. Again, if you don't know how to go in and read the Oracle catalogs, give us a shout. We'll show you how to do that. It's pretty straightforward. Data integration tools, business intelligence tools, system management tools, object modeling tools, process modeling tools, report generation, data quality, data development, data administration, and reference and master data management tools all can play a role in there. So, again, our final polling question that we're coming up to here is, how do you all use these tools in your operations? Again, remember, we're tracking this over time. Not always does it, Megan. Yeah, one more second. Show the results. 49% of you said yes and then 33% of you said no. Okay. You're not that far behind. And if you're ahead, you're not that far ahead. Again, we've got some other statistics we can combine this with and then show you relatively where your organization is on that maturity curve. So, it gets 15 guiding principles around metadata. The first one is to establish and maintain a metadata strategy with the appropriate policies, clear goals, objectives for metadata management and use. And who would do this? Why be data governance a group in the organization? To secure sustained funding commitments, vocal support from senior management. I have an example I use in one of the other webinars of the CEO of a telecom company sending out and saying, we're going to start doing metadata management. And when people said, wow, he said that, that's really interesting. Somebody must have gotten to him. Clearly, it got the impression that the head individual of this organization was supporting metadata management here. Take a surprise perspective to ensure your future extensibility. The other side is here that while you can build projects of metadata, as you do three of them, you're going to start to say, hey, these things are generally applicable. There's a section where we take a specific technology and show how it is applicable across a number of different types of, you know, to do that. Develop a metadata strategy before you purchase products. Again, if you don't have an idea of where you're going, any tool will take you there. So come to a clear consensus on what it is you're attempting to do before you purchase the technology to go and implement it. Look at the various standards that are out there to ensure interoperability of metadata across the enterprise. The company I worked for that was essentially four separate companies. They couldn't talk to each other because they had evolved in different ways. Got together a series of acquisitions and things like that. It makes it much more difficult to put it together. I have another slide that I show in a different context because you can't architect after implementation, and that's exactly what people discover. Number three, effective metadata acquisition for internal and external metadata. In particular, when you're buying software packages, make sure when you buy the software packages, you require the vendor to provide you with the appropriate metadata in there. You'll find your implementation is a whole lot easier as well as your enterprise integration efforts. Maximize your user access to a solution that is not accessed or under accessed will be very difficult to show business value. Again, you can imagine management looking around at the next, starting the next recession, even though we're coming out of this one, let's look at the next recession. And they say, well, what do those metadata management people do? And if they lay them off, and nothing gets worse, then they were clearly not being effective in there. Number eight, understand and communicate the necessity of metadata. Make sure you have websites that articulated pamphlets, different brown bags, whatever it is that you need to do. Make sure the content that you have and demonstrate that you're increasing your scope of your metadata management efforts. Look at XML messaging and web services in particular. They are well complementary to metadata. Establish and maintain business involvement in there. It actually loves metadata because it represents facts about IP. And they're not sure IT has tended to be a mystery. Develop and implement monitoring procedures to make sure that people follow policies, include specialized training for your staff, as well as the metrics, dedicated metadata experts that can go around through the projects and beyond. And finally, start to certify the quality of your metadata that you're looking at. Now, I'd like to finish off here with a little tentative example because it's important when people say, oh, so you spent some time watching a metadata seminar. Can you explain it to me now? And if you go out there and say, well, Peter said things like metadata is all data and all data is metadata, that's not going to be helpful. It's really not really productive to talk metadata with management in many instances here. But we can at least show an example here. And I want you guys to be able to take this away and see what sorts of things can be done. You may have your own examples that you come up with here, but I like to use one based on iTunes. It's a very teachable example that some of you may understand and have encountered this before. So you take your iTunes, whether you're on a Windows or a Mac machining, you stick a CD in there, and it goes and says, oh, great, here's your CD. And it has the number of 30 minutes and 47 seconds long. Very useful. And if you move to the next phase, if my iTunes are connected up to the Internet, and again this works on Windows as well, it'll go out there and contact something called thegreatnote.com media database, which is a database of all, they're trying to have all of them the data about all of the CDs that are out there. And notice it has transformed those track 1, 3, track 25 to the actual titles of the song, the artist, Miles Davis in this case, and the album, even the genre of the album. But you'll notice that song 24 is still three minutes and 47 seconds in length. The other is it retrieved the CD name, the artist, the track name, the genre, the artwork for the album. There you go. And it sure would be a pain to type in all of this information. I've got several friends who were working with early MP3 players and were trying to maintain this information on their own. And of course, somebody at Grace Note came up with the idea of, wow, what if we put it all in one place? We'll only have to type it in one time. The very first time it's typed in. And now everybody will be able to share it. This is one of the greatest crowd sourcing efforts, most tangible crowd sourcing efforts that we can use. Now, I've heard people say, oh, iTunes doesn't really use metadata. And I just sort of go, wow, really? What version of data are you using? Again, we access the Grace Note database, but now I have this information here. What can I do? I can create something called a smart playlist. So this smart playlist here is designed to export all the data for an artist named Miles Davis. I can limit it to 25 items that are selected by range. If I want to, there's other pop-ups that we can do. Live updating means it simply works in real time in order to do this. What happens is it helps to organize iTunes. So I get this smart playlist, and now it goes in and grabs, oh, wait a minute, one item that I put in there called the Complete Birth of the Cool, but I had another Miles Davis DVD in my iTunes library that I didn't know that I had. Wow, live at the FilmWare East. I must have bought that and forgot about it. So I found all of Miles Davis things that are here. Now, that may not be the actual thing that I was attempting to do. In other words, I didn't get the results that I was intending to get there. I just wanted to have the Complete Birth of the Cool album out there. But instead, now I've got both of these albums. So I can go back in and find that request. And then I can go back to that smart playlist and add another criteria, another metadata rule that says Miles Davis Complete Birth of the Cool goes in one list, and then I can go to FilmWare East, goes in another. Those of you that are using iTunes, of course, know that the newest version does this for you automatically, so you don't even need to go this far in order to come up with it. Again, fine-tuning this result can give us the Complete Birth of the Cool, and now I can move the two albums, this folder named Miles Davis, and in that folder I can maintain all of my Davis information on this. Now, here we are working with Miles Davis and CDs. But we can't get it in our organizations, can we? And if we have metadata management tools, many events of your organizational data can become this easy. There are tools out there that provide the functional equivalent of this iTunes. I've got one bank that I work with that has their metadata environment tied so tightly to their production environment that if production goes down, metadata goes down, and if metadata goes down, production goes down. I wouldn't recommend that for everybody, but for this organization, it works really, really well. Here's where it gets really fun. Notice we've done all this for CDs. This is the exact same set of code to include now other things that go into the iTunes environment. The same interface, the same code processing, the same data structures are now applied to podcasts, books, and PDF files. So again, even though that first piece was really useful, look how much vastly more useful this has become. We're going to expand it to things that really apply to economies of scale. So there you go in about five minutes. Hopefully all of you can take away a very quick example on how to understand and illustrate the value of metadata and then turn around and say, how come we can't do that with our data? If I wanted to slice the current customer data and mix that against the products, which is really what a BI question is all about, it becomes a little bit more difficult. I'm going to finish here at the top of the hour now with a couple of quick takeaways on this. Again, we start off with Gartner's wonderful articulation. Metadata unlocks the value of data and therefore requires management attention. Again, those that are working with metadata on this are certainly appreciative. Those that are not are not possible. But you can see the last example, properly engineered and architected systems that I set up just for CDs can now apply to the PDF files, the movie files, the books that we have in my iTunes library, all the media stuff that we want to have. Metadata unlocks the value of data and the second half of this definition is equally important. Because it unlocks value of data it requires management attention. I have had some people that say metadata is technical stuff. I don't want to play with it. Well, you are concerned with business value and therefore it is important. Again, remember our practices are that we have to have a specialized team. We absolutely want to make sure that we have different focus on engineering the metadata, storing it properly, and delivering it properly in order to do that. To connect our resources with our uses that gives us our provenance, our origin of where these things came from, and all of this is governed by governance. In other words, metadata is the language of data governance. And it really is approaching your organization with a data integration project, with a systems integration, any kind of any sort of project. Your first question to them is how good a command do they have over the metadata because if they have a very poor command over the metadata, you can predict with not a whole lot of precision and surprise that they're going to have difficulty. In other words, metadata defines the essence of the integration challenges that you are facing organizationally. And with that back at the top of the hour, again, remember our summary here that we have. Put a little plug for the DM box on this and that we always recluse and recommend reading. This will give you a little bit of time to start getting your answers ready for us in order to do this as we get ready to go off to Dublin, Ohio. So make it back over to you. That was a great presentation. Now it's time for Q&A. Time for you all to ask your questions. So just click on the Q&A chat feature at the top of the screen and you should be able to submit your questions through that chat window, that Q&A window, not the chat window. So we'll just give it a few minutes so you guys can get your questions in. And we're working towards this, our upcoming events. This is part one of a three-part series. We're going to talk about cloud next time, which, again, a lot of people are looking at as a penitent. There are some very exciting opportunities around cloud, but cloud and data presents some really interesting challenges as well. And then the third part we'll do warehousing as we get into that. So, again, August and September talks coming up there. Of course, you may understand metadata totally, and we may not have any questions, so let's see. Sam, let's see here. The first one is, how would metadata management work for unstructured data types? Good question. How would metadata management work for unstructured data types? I'm going to go back to the slide on the metadata practices because the answer is in some cases it's very much the same and in some ways it's different. The slide I want. Oops. That slide. Hang on. The second one is that the basics of doing metadata practices are to change whether the data is structured or unstructured. You still have the requirement for the team skills. You're still trying to collect sources and uses with the data. One of the things I was talking to a colleague the other day and he said, you know, gosh, I'm really kind of scared because I'm afraid now that I've heard all this stuff about the government monitoring the phones that if I say the words, say, and Obama, Ben Laden, and Bomb in the same phone call that they will actually be able to come and check me out. And it does represent an unstructured data problem or a non-tabular data problem as I prefer to call them, but the other is still there is some metadata engineering and you're not randomly going to have a phone call that's going to be monitored that way unless they already have a suspicion. They simply cannot manage all the data that's going on out there. Again, I think it's something like six trillion tweets occurring periodically that's just numbers. So there's got to be an interest. Now, if you're already on a list of people that the government is watching, and again, I'm not working with the government here so I'm certainly not expressing a government position. I'm simply talking about practical matters. Okay? Unless they've already decided that you have interesting conversations and they should check them out, your unstructured data is unlikely to be going through voice filters looking through specific terms. But you can do that. You can run your things through it. Now, a terrific way to see this again, and I want to sound like an Apple bigot here, but Apple's iMovie has a really interesting set of metadata that it crack us. So for example, if you're in iTunes and you're creating a trailer, which is one of the things people like to do with iTunes, iTunes will read through your movie data and find scenes with one people, scenes with two people, and scenes with three people in it. And it will say at this point in the movie trailer, it would be nice if you had a scene with three people in it. And it will presume the movie scenes in the raw material that you've given it that have, as far as it can tell, three people in them. So that's a way of looking at metadata management in a relatively unstructured environment. But you can see clearly if it was unstructured, you couldn't find that. So it is clearly finding some structure in there. Similarly, some of you will have a band and when we play them we record our sessions. And some software that will go through and find the pauses in between the songs and suggest that these are song breaks in between the songs. So there are techniques that you can use to add more structure to your non-tabular data. And this makes the process of doing your metadata engineering and your metadata delivery very, very successful. I can go back into iTunes, excuse me, into iMovie and send me scenes with only three people. In fact, iMovie is actually smart enough that it will do actual recognition and it will find scenes where Peter and somebody else are in the same scene. That's pretty good metadata management and you better believe it's up there in commercial software. It's certainly available to other folks as well. I hope that answered your question. Again, the basics of the unstructured world are the same. Some of the tools and techniques are different. And in iMovie you're very unlikely to manage these two types of metadata, tabular and non-tabular, in two separate streams. You gain much more by integrating them together than you do by keeping them separate. So in most cases you will simply not do it as a separate issue. You'll do it as a component of your overall metadata management strategy. Again, I didn't do the answer, but I hope that was useful for you. I'll see here questions. Do you handle multiple layers of metadata? For example, metadata about a data file as opposed to about the dimensions of the data file as opposed to data dimensions across an organization. So that's a terrific question, fairly sophisticated in terms of what they're asking here. The idea behind metadata, metadata means above, beyond, or transcending. And what that really means in most cases is that you are abstracting a concept up to a higher level of abstraction. Those of you that are familiar with the Bacman Z-A-C-H-M-A-N framework understand that it's one of the principles upon which it is based as well. Let me give you an example. I'm not a person who, even though I enjoy alcohol from time to time, responsibly, I'm not a person that the beer is fissionado. So when somebody says, is that a Pilsner versus a pale ale or something, that doesn't mean anything to me. I assume the pale ale is lighter in color, but I abstract all that up to beer. Well, the next level of abstraction beyond that is alcohol, and you can, again, imbibe by drinking beer, or you can imbibe by drinking either of these things. I'm not sure we're on a rum kick today, Megan. We were just thinking about the weekend coming upwards past. But anyway, so look at these abstraction issues. Every use of metadata is going to a higher level of abstraction. In this case, the higher level is the lower level is the data, which means that one person's metadata can become somebody else's data, and that goes down in the concepts. In fact, there's a concept of a haul-on. Some of you may be familiar with that line of research that says the two things are really inseparable. We won't go too far down that particular path. But absolutely, you can have layer upon layer upon layer of metadata. And as you're managing this, most of my graduate students as they're going through the class come to the inevitable conclusion that it can all be managed in one table eventually. And the answer is yes, but not productively in order to do that. So the question here was around, if I've got metadata at one level and I go to another level, can I use the same techniques to manage the data at the next higher level? So again, the example that I used here is a Pilsner versus another type of beer. I forget what I even said it was, because I'm just not that attuned to beer. But if you look at it to beer, that works. You can extract that up to a double, which is an alcoholic beverage or an adult beverage. Then you might go on one level up to a liquid, but then you could have a different advantage of a liquid, which may be actually good for you as opposed to the alcohol, which is probably not the best thing for you, at least not in large quantities. Again, I hope that works. I hope that makes sense to you guys. It's exactly the type of thinking that you want to do when you're thinking about your metadata practices is to say, how can at large levels, higher levels of abstraction be helpful in delivering business value, particularly around, in this case, data and integrating projects, but in general, providing value to the organization? The next question is, how does metadata management relate to data governance? Don't we govern through metadata rules? I think you answered the question there. So when you are dealing with data governance issues, if you are not talking about specific concrete speech expressed as metadata, you will require an additional layer of translation. Again, let's go back into the beer examples since I beat that one today. If the governance around this is that the alcoholic beverages should all be treated alike, that doesn't work very well in the state of Virginia because you can sell beer and wine in certain types of stores and harder liquors in other types of stores. So that approach to doing metadata management is typically not as useful. The idea is, with metadata management perspective, if we understand what we're trying to do from the organizational perspective and the strategy, we'll be able to implement these rules. And the governance around those rules should be applied appropriately. I don't think I did a terrific job on that, so let me take that one more step further here. And again, I'll go to my iTunes example here. CDs. And the pointless example here was to go a little further and say the same code, the same processing, the same data structures can be applied to podcast movies and PDFs files. Well, that works terrifically, but my metadata governance or my data governance doesn't express it in terms of proper labels. They say alcohol can be sold in stores. That doesn't take care of the subtle differences between hard liquor and beer and wine. And so, again, we want to be careful and make sure that when we are speaking and using data governance terminology, we are speaking in explicit, precise words and in explicit, precise metadata terms. So, as we said in the seminar, we're saying that is the language of data governance. And I think the question said that very well as well. Can you give an example of how you would set the use of metadata to application development teams? Yes, that's a tough one. Here's the best way to do it. If you're in an agile environment, it's easier when you can apply them with metadata. But they should only be allowed to start their agile project if the data governance group understands that they have precisely defined their data requirements. I'll give you an example. I'm working with a group at one point that was building a fairly large data warehouse, corporate data warehouse, going to be implemented worldwide. And they would start spending money. They were like hurry up and get going, right? And I said, well, it's very bad idea to get going when we haven't stabilized the requirements. They said, well, what do you mean I stabilized the requirements? And I plotted them a graph over time that showed them how one week they thought this much data should be included in the warehouse, and the next week it was this much data, and the third week it was this much. In fact, over the last six or eight weeks that we had been doing this, the amount of data that was going to be confirmed in this warehouse had varied by several orders of magnitude. So people want to get started on this. A good governance role is to say, no, I'm sorry, requirements are part of data governance, and your requirements, when they're available, will actually help the applications group to speed up. Now, that's a very high-level piece. Let me give you a very low implementation as well on this, which is to say that when you're building applications, most of the time you have data-based access. In other words, you want to put some data at the center of a system of programs so that they can all share the same data. We'll give in a specific example here. We'll take a university registration system, so students are registering for classes. We wouldn't want to input the student name each time. We would, in fact, want to grant a student ID number and use it to name this student ID the seat in this particular class. It will be a whole lot easier for the applications developers to work with a stable data model than it will until we work with an ever-changing data model. One of the projects we were on recently, in fact, we asked them to provide a model that they were going to have, and they said, well, we're only two weeks from shipping, so we haven't quite stabilized the data model. And once again, we were able to predict that they were going to have some trouble with that particular system when it was delivered because it had an unstable data model. So the providers want stability. They want factual information, and that's what metadata is. It's providing them facts. Another place that you can help your area is around the business process metadata. If you have an accurate and correct business process model, then it will be much easier to build and test the effectiveness of the software that you're doing to support the business processes than it will if you don't have that. Again, let's just go with the idea of a friendly user interface. Everybody wants a friendly user interface, right? If you make it a little bit more precise and say that this user interface should enable somebody to achieve 99% accuracy with a maximum of one hour training, then there's a very different set of specifications around the interface, and those specifications can be metadata that you can use to help your applications people develop better systems. Again, big question. I hope that helped. There's one question. I just want to make sure that we did get it answered. I didn't want us to get lost here. And you can tell me if it's already been answered. How would the sync of metadata stores happen against data stores, explain for highly dynamic and unstructured data? That is a very difficult question. What you're looking at there is a situation where your data structures are evolving in real-time in minutes, and if that's the case, you're going to also have to have a dynamically evolving metadata structure. I want to see a physical example of that. The Program Language Mumps actually uses that and there are some papers that describe how that is done so you don't actually have to reinvent the wheel in order to come up with that. But let's just say it's a non-trivial problem and that the amount of dynamism in the data evolution is going to have to be similarly reflected in the metadata evolution as well. One interesting question. I'm real curious to see what project that was. One question is, metadata management seems to be a low priority in many organizations. What are the core arguments or value-add statements for metadata management? Perfect. Again, it has been core. You can see that not only from probably your own experience, but from the results that we presented here in the webinar as well. Let's just go back to various guiding principles that are involved in this. It's the idea that we really do need to be able to articulate this. First of all, it is a technical discipline, so we absolutely can't just expect it to be anybody and put them in place. We've got to have somebody with the specialized knowledge, skills, and abilities in order to do this. The value for these things is absolutely critical. And once you understand and are able to articulate these benefits in terms that your organization can understand, they will be able to do it. So, again, both of them are from Gardner, which is one of the reasons I'm so pleased that Gardner did a terrific job on their definition. That increases the value of your data. Their work requires management attention. I've never shown that to you. I've seen lots and lots of IT and business managers over time. They say, well, if Gardner says it, then I guess it must be true. So, we like to use the Gardner reference there. It's a great thing. They've done a good service there. But the other part of it is, if you think about data as your soul, non-depletable, non-degrading strategic asset. I'll just say this at the same time because I don't have it on any of the slides here. It's your soul, non-depletable, non-degrading, durable, strategic asset. That's a pretty interesting class of assets. And it's also probably the asset about which your organization knows the least. Again, our comptroller here at Data Blueprint absolutely has an idea of where our cash flow is. Notice that she can make full on a weekly basis, all the rest of the things that go into this thing. You have in your organization probably very tight control over what's going on with cash as an asset for your organization. Your HR manager probably has a really good idea of what's going on from an HR perspective in your organization. But your data being its soul, durable, non-depleting, non-degrading strategic asset is probably not as well known. And that's a really good reason for paying a little bit more attention to it. Another example that goes on this as well, I was working for a company that had literally hundreds of thousands of employees at one point in time. And I asked them how many managers did they have over their HR resource? And they said they had several thousand HR managers to manage several hundred thousand HR assets. And I said, great, you've got three people watching your data. Some of you are trickling on that because it does kind of drive home the point. So do some comparisons, look around and see what other things are being managed. I've got the benefits up here on the slide again. Increase the strategic value of information, lower training costs, reduce the research time and fixing problems, improve the communication, increase the development speed, reduce risk of project failure, and decrease the amount of data rot that you have in your organization. All of that are going to be helpful, and hopefully that gives you some information to take away on that. And the next question is, is metadata management the same as master data management? And how do you use extensively by apps like Facebook? Data management is the idea that you are going to be keeping track of, and we do a webinar on this one as well. But master management is the idea that you're going to be keeping track of major values of people's places and things, if you will, at the highest level of abstraction in the organization. Master data management cannot be done unless you have metadata management. So it's an implementation of metadata management in a specific area, and they've developed some tools and techniques around this. Actually, I like to use MDM to represent a different concept. I call master definition management. I shouldn't say I call it that. I call it that because my friend Ross Lair calls it that. I think it's a much better definition than master data because most organizations have trouble defining what they mean by master data. So master definition management is what I like, but they are different things. Again, metadata unlocks the value of data. Master data controls the values or certain things. Again, if you're keeping track of your customers, your main suppliers, your main shippers, your locations in people's places and things in your organizations, then these are things that it doesn't make sense to keep in multiple places. This organization keeps their customer information in 17 places. If you're doing better than 17, you're a little above average. If you're doing fewer than 17, you're doing better than average. 17 is probably not the right number. One is probably not the right number either, although if you can get to one, that's terrific. Master definition data management is distinct. It is the idea you are keeping track of some of the major person places or thing values around your organization, and it is an instance of metadata management, but it is not in itself metadata management. I guess that's not clear as to be a qualifying question on that. Good question. Master data management. What's coming up? Can we look at the calendar here? That will be in November or the 12th of November. All right, so hang on tight. It looks like a couple questions. It's about a minute to see if anyone submits anything. I'm asking some really tough questions today. It's a really good one. It looks like that's it. Thank you, everyone, for participating in today's event. We hope you have enjoyed it. Thanks again to Dataverse City and Shannon for hosting us. Once again, you will receive today's materials as the next two business days. Our next month will be Data Systems Integration and Business Value Part 2 with support. Hopefully, you'll be able to join us for that as well. As always, feel free to contact us if you have any questions. Thanks, everyone. Have a great day. Thanks, Megan. Thanks, Megan, for another great webinar, and thanks, everyone, to attending. I hope everyone has a great day. This is Megan's turn.