 Hello and welcome my name is Shannon Kemp and I'm the Executive Editor of Data University. We'd like to thank you for joining this month's installment of the Monthly DAMA International Webinar Series. This Webinar Series is designed to give our Enterprise Data World Conference attendees education year round. We are excited about the upcoming Enterprise Data World 2016 to be held in San Diego, California April 17th through 22nd. We've already had a lot of inquiries about that so to be sure to save the date. This Webinar is being presented by long-time well-known EDW speaker David Marco. Today he will be discussing 10 keys to world-class metadata management. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the Webinar. For questions, we'll be collecting them by the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions by Twitter using hashtag DAMA. As always, we will send a follow-up email within two business days containing links to the slides, the recording of the session, and additional information requested throughout the Webinar. Now, let me formally introduce today's speaker, David Marco. David is the President of EW Solutions, GASA Schedule and Chicago Headquarters Strategic Partner and Full Life Cycle Systems Integrator, dedicated to providing companies and large government agencies with best-in-class award-winning solutions using Enterprise Information Management, Big Data, Data Warehousing, Data Governance, and Managed Metadata Environment Technologies. You can find them at ewsolutions.com. For more key details, he is best known as the industry's top authority on metadata management, wrote the two top-selling books in the field and is the father of the Managed Metadata Environment. He is an internationally recognized expert in the fields of master data management, data governance, big data, data warehousing, and Enterprise Information Management. In 2004, David Marco was selected as the world-famous Crane's Chicago business top 30, or excuse me, under 40, and in 2008, he was awarded the Dame of Professional Services Award, the highest honor in our industry. And with that, I will turn the presentation over to David to get us started. Hello and welcome. Shannon, thank you so much. And welcome to everybody here on the webinar. So the webinars are interesting. I've had an opportunity to do many of them over the decades in this industry. And they're one of the most challenging things because I don't get to see all of your bright shining faces. But the good news is we have tons and tons of information. We're going to walk through. We're going to have a little bit of Q&A at the end, so let's dive into the topic. So we're here to talk about metadata management, and we're going to talk a lot more than just about the top 10 things to avoid. This slide just gives the company background. We've been very blessed. We've had many successful clients, and we've won pretty much all the awards you can in this industry. So what I'm going to attempt to do in today's webinar is to give you the best practices. What are companies doing today to be successful? And what are the things companies do that lead them into not so successful implementations? Because really, this is all about building successful solutions for your company. I also included on slides for my background and an email address where people can reach me. And with that, let's look at our agenda. All in under 45 minutes, we are going to look at metadata management fundamentals. We're going to talk about the differences between business metadata and technical metadata. I'm going to walk you through the metadata management use cases so you can actually see it in action. We're going to talk about metadata return on investment, or ROI. Why is this valuable? I'm also going to teach you the managed metadata environment. This is the application that manages our metadata. So I'm going to show you its key architectural components. And we'll talk about it for a little bit. And then it's one of the favorite things people love to hear at talks I give is my top 10 list. If you're doing, if you're building a metadata management solution, these are the top 10 things you want to make sure you avoid doing, if you want to be successful. Last but absolutely not least, I'm going to give you two world class case studies. We're going to look at two companies, or I should say two organizations. One is a large company Fortune 500. And the other is a massive federal agency. So for all of you federal folks out there, you're going to get something for you too. So if that all sounds good, let us move forward. So let's look at some metadata management fundamentals. So first off, what is metadata? I teach a three day certified course on this topic. And I love asking people their definition for metadata. So let me make sure I define these concepts so that we are all on the same page. So what is metadata? Metadata contains the knowledge that a field is called customer named, or it's 40 characters in length that it exists in all these different systems. And maybe our company has three systems, which contain customer master data. These systems are so on and so forth. So metadata is all that information, all that stuff around the data. When we talk about data, what we're talking about is a specific instance of data, for example, customer name equaling John Doe. John Doe is a specific instance of the attribute named customer name. And then what's information? It's data that is meaningful to our business users, our decision makers. What does that mean? It means they understand it and they know exactly what they are supposed to do with it. So let's kind of develop this topic a little more. I can go up to anybody in this audience and I can present you data. I can tell you 24, 38, 7. All right, make some decisions about your company. 24, 38, 7, go. I'm your boss and whether or not you have a job tomorrow depends on your answer to that question. You'd probably be looking at me oddly saying, well, wait a minute, 24, 38, 7, how could I make any decisions with that? Well, that's good clean data, but what happened? I gave you data or content, but what didn't I do? I didn't give you context or metadata. So if I told you those are sales figures for your division over the last three quarters, you could see, oh, sales are going up, sales are going down. You would actually then understand what you're looking at because what we are trying to get to is information. And when you take data, when you take content without context, you don't have information. It's like when you present data to your knowledge workers without metadata, you don't have information. Content plus context, data plus metadata equals information. And the term I like even better than information is actionable information, meaning I present this information to my business user and they know exactly what action they are supposed to take. Oh gosh, I need to call Mary right now because we have a problem or I need to avoid Mary because my group has a problem, whatever the case may be or I need to do nothing at this point. Meaning you present them the information, the content and the context and they know exactly what they are supposed to do. That's the real goal because a huge challenge we have in our industry today is we are presenting our business users with a glut of data, a glut of content but it doesn't have metadata and it doesn't have context so they are swimming in the data, they are making non-profitable decisions or actually very damaging decisions as we will see as this presentation progresses. In addition, they are not getting value and they are falling behind their competition who is doing it better. So at the end of this webinar you should be well on your way to understanding what it takes to do this properly. So let's look at a little bit of the managed metadata environment and that's a term used for not just the application but the environment that manages our metadata and I will show you this as we move forward but first we are going to look a little bit at ROI. So the key to your company's prosperity is how well you gather, retain and disseminate knowledge and a managed metadata environment are all about gathering, retaining and disseminating knowledge that's what this is about. So hopefully when I show you these use cases you will kind of see what I mean so let us press forward undaunted in our study. So there are two major categories for metadata, business metadata and technical metadata. You can read an article out there that maybe will show you six different kinds or eight different kinds. I think I even recall seeing one that had 16 different kinds which is very binary for you old coders out there but when you look at it really they are just derivations of these two and I really believe the terms business metadata and technical metadata in my experience having implemented dozens of these applications it is the best way to communicate and categorize what we are building for our company. So let me hit it, what is business metadata? Business metadata helps provide a semantic layer between your company's IT systems and your business users. This way when you are presenting them data, the content, you are also giving them the context. So again business metadata provides a semantic layer between your company's IT systems and your business users. Technical metadata provides, helps your IT department better manage, maintain and grow your company's, your organization's IT systems. So I will say that again, technical metadata helps your IT department better manage, maintain and grow your IT systems and I will develop these thoughts as we press forward. So let us look at business metadata. Why is it valuable? Why is it valuable adding context to the content, metadata to the data? Number one, it reduces training costs. This is a big deal. Let's suppose you worked at a car insurance company, major car insurance company and you have been there 20 years. You switch jobs, you go to another car insurance company. One of the big problems you are going to deal with are their code values. They have a code A means mains car, a code B means SUV, a code C means luxury car and you came from a company where code 3.4 meant luxury vehicle and 2.8 meant SUV and so on and so forth. And just learning those codes and how it translates can take months if not years to learn. And for those of you who are in the insurance business, you know exactly what I am talking about. You live in a very code driven world. So it really reduces those training costs. Number two, it makes our strategic information, that enterprise information so much more valuable. So for example, if you look at companies today, everybody is trying to make better enterprise decisions whether it is data warehousing, whether it is CRM, customer relationship management, SCM, supply chain management, big data analytics, all those different things. They are all about enterprise level decisions and what they really want is actionable information. They want to limit incorrect decisions. They want to help our analysts find the information they need. Notice I said information and not data and to do it in a timely manner. And it really helps bridge that gap between our business users and our IT professionals. And of course, all this increases the confidence in our IT system. So I have kind of talked in general what it is. Now let's take a look at business metadata. What we have here is a classic data warehousing report. The exact kind of report probably many of you have seen over and over again. It is the global and I am going to try to use, we are going to try to make this interactive. Laser pointer here, the 2015 monthly global sales report. This report shows by month, by product category, sales in US dollars, sales international dollars and then total. Seems like a pretty straightforward report. However, I am going to show you that there is a little bit more to this. What if you could right click or hot key or hit F1 on this column, US sales dollars. What if you could do that and actually pull up a business metadata definition for that column. And that is exactly what I am showing down here in this balloon. And what does it say? It says sales dollars in the United States is comprised of aggregated sales revenue. So we are aggregating. We are bringing things together from the United States, Canada and Mexico. But we do not subtract sales dollars from returned orders. Wait a minute. How many of you, when you just read, I am going to try to use a new piece of functionality here. So we will see how this looks on the screen. How many of you would have known? Well, that didn't look too good. But anyway, I will just go back to my checkboxes here. How many of you would have known that US sales dollars were comprised of Canada and Mexico? Probably nobody would. Now, some of you are saying, well, wait a minute. I have seen this speaker's bio before. He is taught at the University of Chicago. This is some academic theory thing. Absolutely not. If you have worked at a manufacturing company, you are probably looking at this saying, I know exactly what this is. Because many manufacturing companies consider Canada and Mexico as part of US sales dollars. And why do they do that? Because they can get their product there on a truck. The same companies, many of them consider Hawaii and Puerto Rico international. Why? Because you can get their product there because they have to use a plane or a boat to get their product there. And then when you look at this definition, how many of us knew, just by looking at that column heading, that we were not subtracting sales dollars from return orders? Well, none of us would have known that. We would just be guessing, is that a factor? Absolutely. What if there is a massive recall on our televisions here for the month of November? Well, would you want to know about that recall? If you're the vice president of marketing or of advertising or a finance and you're looking at this report, you better believe you want to know that information. And you can see this definition that I selected. And I'm sure there are some of you out there who have you built MMEs in your past or maybe you're currently building one. Or supporting one. You know I gave a very simplified definition because in the world, and I did that so that it would be easy to explain, but in the business world we get much more sophisticated. So hopefully this makes sense because I'm going to move on and show you some more use cases. So let's take a look. Same exact report and earlier I showed you column level business metadata definitions. Now let's take a look at a row. Again, wouldn't it be great if you could right click or hot click on a row and actually get information quality or data quality statistics? If you could on this row, what you would discover is 1.7% of the records were not loaded. Well, that's a problem. But look what else we see. 8.4% of the dollar values were not loaded. Now is this valuable? Absolutely. If I am making strategic decisions based on the sales numbers for television in the month of November, I want to know that the numbers I'm looking at are skewed by as much as 8.4%. Now some of you may be sitting out there saying, wait a minute, wait a minute, how are you getting this? Is this some kind of special industry guru magic that provides these numbers? Well, absolutely not. When you build, I'm a past data warehouse architect, and I used to build ETL processes. And so even with that I'm working with a client now under data warehouse architecture. Well, one of the things you do as an architect is you trap errors. There's always errors that happen in an ETL process, ETL extraction, transformation, and load. And so many times we should already in our error process and capture the statistic that 1.7% of our records were not loaded. The 8.4% is nothing more than summing up the dollar values of those records we didn't load, and then loading all this metadata into our MME. That's really all we're doing differently than what a data warehouse does. We're just summing up to get the dollar values and loading this valuable metadata into the managed metadata environment. Let me continue on. I could spend another 20 minutes on that slide. So that is a quick overview of business metadata. I should mention if you go to our website, edwsolutions.com, I have probably over 100 articles that I've published that are available. And you can download and read them at your leisure if you want to get a little bit more of an in-depth discussion. But let's look at technical metadata. What's technical metadata? It's metadata to help metadata that helps our IT departments that are managed, maintained, and grow our IT systems. That's what it is. So let's take a look at some case studies or some use cases in this area. So before we do that, we need to ask the question, what do our current IT systems look like? Well, I venture to give you, venture to hypothesize that I think our IT systems look like this. If we were all together in a room, I would ask somebody in the audience to walk me through in great detail what this chart means. Well, clearly you can see by looking at it, it is incomprehensible. And this chart was actually modified from one of our clients. They're just a small, I shouldn't say small, but a mid-sized company. So they're not one of our massive customers. But when you look at it, and it's only data warehousing, what do we see? We see all these different operational applications feeding eight independent data marks. And this type of architecture, which I am saying is the common one used in companies. And it's absolutely, as I've seen it, over and over again. We had a chance to re-engineer this architecture, and I'll quickly, I could spend the rest of the webinar on this slide because it's so riveting. Let me share with you the problem. Massive amounts of process redundancy. You could just look at it and see it. Massive amounts of data redundancy. In this particular ecosystem, this data ecosystem, they had seven-fold needless data redundancy. What does that mean? If they were using seven terabytes to load and manage this, they could have done all that work with one. That's how much needless redundancy. And when I say needless, I mean that word needless. They still have backups. They still have copies. They still have staging, the whole nine yards. And when you look at it, all these problems put together, they give you erratic results. You don't have a single version of the truth. I could think of a large telecommunications company. Massive out in the Midwest. And I remember we got to work with them because they had a new CIO. And why did they have a new CIO? Well, the old CIO had spent $50 to $70 million on data warehousing. And the CEOs went up to him one day and said, I want to take our top 20 customers to this big PGA event that was happening locally. Here's the problem. He got four different answers to his question. At that case, the fit hit the sham, and the old CEO lost his job. And because he said, hey, I spent all this money and I can't even answer such a simple question. And that's sadly the state of our systems today. So let me keep moving forward. So technical metadata, why is it valuable? It's first and foremost, and it's the first bullet you're going to see here. It dramatically reduces the probability of project failure. And this is a big item. When you look at our IT projects today, if we are attempting to do any kind of significant large IT initiative, the failure rate is somewhere between 45 and 70%, depending on how you measure failure. Well, imagine if the brakes on your car failed that often. None of us would drive. We would all be world-class tour de France bike riders. If a brake failed that often. And I live in Chicago, where we always have a foot of snow on the ground. So it would be very hard for me to get around. Anyway, and this issue of project failure is significant. I was just in Phoenix keynoting their big day-a-day, and it was all on big data. And I shared the failure statistics around big data, and they are shocking. 55% of the projects don't even complete. So they don't even get the failure. They can't even complete. Of the 45% that do, they're failing at, depending on the citation, you look at somewhere in the 60 to 80% tiles. So these are very, very significant statistics. And these failures are happening because we don't understand our data. We don't know what it means, and we don't know where it's located. We don't know it's valid domain values, and we don't understand it. Metadata management, along with data governance too, but there's a metadata talk, provides that answer. So let me continue forward. Okay, slide 22. What is a technical impact analysis? A technical impact analysis is a metadata-driven report that helps you assess the impact of a proposed change on your IT system. So it is a technical, metadata-driven report that helps you assess the impact of change on our IT system. So I could show you hundreds of these, but here's a classic one. We have a source system, order entry, and it has the customer table. And we are going to change that table. We're going to change the customer name and the address somehow. And this impact analysis will show you which programs, which tables, or files, remember we still have files, and what feels will be impacted or could be impacted downstream by changes in this table. For you data warehousing managers out there, please raise your hand. Okay, I see you. How do you typically find out about changes in your source systems? I'll give you choices. Is it A, you get a phone call nine months before the change is implemented, describing it to you, seven months out you get detailed design specs, four months out you do integration testing together, and then you roll it out together on time. Or B, do your ETL processes blow up? Typically you find out about the change in B. And by the way, there's another way you find out about the change your business users call you. That's the worst way. Anyway, another form on this slide of an impact analysis. Let's suppose we needed to change customer name. Today it's an alphanumeric 20, and we need to expand it to 30. Wouldn't it be great if we could run a report from our managed metadata environment that would go through all the technical metadata and show us, oh, here are all the places where we use customer name throughout our organization. How do we get this information today? Smart people perform grub commands, and they pull copybooks out of pan valet, and they spend days, weeks, and really months trying to figure it out. So these are some examples of technical metadata. Oh gosh, I have to go through this one quickly. Metadata for systems consolidation. So the managed metadata environment for systems consolidation. If any of you out there work at a financial institution, I guarantee you that in the last 10 or 20 years, even if you stayed in the same office, your company has either bought someone or has been bought probably multiple times. I have a friend of mine in the world of accounting, and he has been at the same company for 15 years. He's been at the same, I should say, let me take that back, he's been in the same office for 15 years. He's had the same administrator for 15 years, but his company name has changed four or five times. That's how often it happens. Anyway, wouldn't it be great if we could run a technical impact analysis. Let's say we are Big City Bank and we just bought Small Town Bank. Wouldn't it be great if we could run an impact analysis that said, hey, our customer number in our system, which is the attribute of record for our bank customer numbers. By the way, that's not the best definition. Customer numbers should never be defined by the same words. Anyway, what are the attributes and systems from this company that we're acquiring that map to our customer number? We'd find out it's cuss num, purchase num, and borrower num from the loan sys, cuss sys, and cussed application. Some of you are saying, my goodness, David, do you know how long it would take to capture that information? I do, and it would take a lot of time. We don't have time for that. Okay. Well, you want to migrate the systems from Small Town Bank over to our bank. How are you going to do that without doing this analysis? Answer, you can't. The only question you're answering, whether or not you want to store it in an MME, is this. Do you want to keep this vital metadata on cocktail napkins, word docs, Excel spreadsheets, or put it in your managed metadata environment so that we use it not only for this project, but for the next 30 projects that will need all of the information that we see to the left, to your left, of the little clicks? I think you know the answer is pretty obvious. This next page just gives you a more detailed transformation role, but we must progress forward on our journey. I want to give, I mentioned I'm going to give some ROI examples and some little customer case studies. Let me give you one that happened for one of our massive clients on the East Coast, large healthcare insurance company, $1.6 billion IT budget. I mean, so this is one of the big boys. They estimate that it costs them $2 a month to store each gigabyte a day. That's just physical storage. When you add services and maintenance, that cost goes up to $8 a month. They estimate that they have 1.6 petabytes of redundant data. So what does this cost them annually? Well, I didn't do any of the above calculation, but I am an expert in simple math, and when you calculate it out, it comes to $153 million and a little $600,000 of odd change. This is a big number, and some of you are looking at it and saying, my goodness, that is a very large number. However, the actual cost of this redundancy, now this is a big number, don't get me wrong, but there's another number that's much harder to quantify, but in my professional experience of doing this over, now two decades is a much bigger number, and that's the cost that people are actually in this company using. The 1.6 petabytes of needlessly redundant data, and they're making real business decisions with it, and the ramifications of that can be severe. You know, I think of a large automotive company, they had a huge problem. They had to issue recalls to their cars. I'm sorry, not recalls, they had to issue recall checks. So if you bought one of their cars, you would get a check in the mail for about $500 or $600 if you had bought the car so you can get this part fixed. Well, so what they did was they sent these checks to thousands and thousands of people. The problem is the CFO, the chief financial officer, received one of these checks. Here's the problem with that. He didn't own the car. Well, guess what? Remember the fit hitting the sham store earlier? That's exactly what happened when he came back in. He said, we've spent hundreds of millions of dollars to be able to answer this simple kind of question. And you're sending me, and I've just been sent a check for $600, $500 for a car I don't own. And he obviously thought, how many other people did that happen to? What's interesting is he's the only one, nobody returned their checks. Kind of odd. Anyway, let's move forward. I think it's fascinating we build systems to manage every aspect of our business, except one to manage the business themselves. So we build systems that manage payroll, vacation days, even the football pool, or in Chicago's case the hockey pool. I have to mention the Chicago Blackhawks did win the Stanley Cup last night, pretty fun. It meant I'm on very low sleep because people were screaming and yelling in my neighborhood last night. Anyway, but a managed metadata environment is a system that helps us manage our system. Let's move forward. So, oh gosh, ROI, I'm going to have to fly through this. So Intel, there was a study by Intel in Computer World Magazine. They estimate $6 of savings for every dollar they spent on their NME. That's a very good number. That's what I typically see. There was a Canadian government agency. They found that when they would build new systems, they were reusing more than 90% of their existing data definition. And they had an 85% improvement in their application integration and their percentage reduction in analysis and design went way down. They could do those impact analyses. They were doing them in two hours when it was taking them 36-person days of consulting. So, and in my mind, these are very typical statistics you see in our client base who installs the NME successfully. And it's fascinating. Gartner Group had this study where they estimate 50% of developer time is spent searching for data as opposed to actually utilizing. And they say here that 20% of this 50% can easily be reduced by implementing a metadata management solution. Well, I would say if you only reduce it 20%, you've done a very poor job. That number should be, you should be able to reduce it by three times that amount to four times very easily when you do this correctly. So let's look at the managed metadata environment. I'm going to have to go through this somewhat quickly. But again, feel free to go to the website. You can download some articles for free on it. The managed metadata environment, it represents the architectural components, people and processes that are required to properly and systematically gather, retain and disseminate metadata throughout our company. So when you look at the managed metadata environment, it has six basic sections to it or six basic areas that I want to talk about. So the first is the metadata sourcing layer, the metadata integration layer, the metadata repository, the metadata management layer, the delivery layer and the metadata mark, six of them. So I'm going to go through these very quickly. The metadata sourcing layer, its purpose is to extract metadata from all our different sources and bring it into our integration layer. That integration layer then loads this metadata into the tables of our metadata repository, which is important. Good metadata repository is subject oriented. It's integrated. It will be time variant and it will be sensitive because it will be changing. And then the metadata management layer, think of that as the brains of your MME. It controls sequencing and purge statistics and performance statistics. And the delivery layer is, and this is something you see in an MME, we could be delivering metadata to a website. It could go to a third party. It could go to a messaging system. It could go to business users. Maybe we're loading it directly onto an MME data warehouse. Maybe directly to the users. Maybe we're loading a metadata mart. I'll talk about that in a second. Maybe we're doing closed loop metadata architecture and putting it in an application. By the way, when you see these end users here loading metadata, think of those as our data stewards. And we don't have a lot of time, but I want to at least give this concept to everybody. Data governance are the people processes around our data. Metadata management is the technical enabler of our data governance processes. Because guess what? Data stewards spend 80% of their time working with metadata and 20% on data. And again, having built over a dozen data governance programs, I can tell you that is about the ratio we see. Oh, if I move on, metadata mart. What are those? Just like a data mart. It's a group of metadata for a homogeneous user group. What does homogeneous mean? I mean, that's a good $50 word. It's a group of users interested in the same stuff. That's all it means. Let's move forward. 36. So, okay. This is going to be just a quick case study. I mentioned I'm going to share with you guys a couple case studies. This is from my second book on metadata that Shannon was nice enough to mention called Universal Metadata Model. And in this, I feature RBC Financial. RBC Financial, at the time of this writing, they were the largest financial institution in Canada, along with one of the largest in North America. They have been very successful. So I'm sure all these statistics have gone up. They provide personal and commercial banking, wealth management, insurance, investment banking, all this other stuff, and they do it on a global basis. They have over 60,000 people, more than 12 million public sector clients in over 30 countries around the world with millions and millions of customers online. So, wow, sounds great. What's the problem? Well, way back, and this is back in the 90s, they built the data warehouse that had more than five terabytes of data. For those of us who used to build data warehouses back then, that was basically the equivalent of petabyte size data warehouses today. I mean, when you were managing a terabyte back then, that was really difficult. It's not like today where any of us can walk to Best Buy or any kind of computer store, and for $80 by a terabyte external hard drive, that's about the size of a pizza toast. So it was much different back in the early, early 90s when we used to do this. Their end users needed to gain knowledge on the data, and they had hundreds of applications that were all interfacing and sharing data, just like our companies today. They really needed to improve their time to market when they were modifying their system, but I can tell you, the real driver behind their MME was this last bullet. Their core systems, the vital ones, were only known by a handful of people, and they were afraid that this knowledge was going to be lost when they moved forward. They built an enterprise-level MME that provides an inventory for all of their information, all of their metadata across these hundreds of applications. Here's just a quick overview of their environment. They've since re-architected it using a different tool, and I'm working on getting that updated. I can share with you all kinds of great statistics. I highly encourage you to read this slide in detail when you download it, but I will stick on this third bullet here. In the late 1990s, they were working with a major credit card company, and they asked RBC to change their credit card to expand it from 13 bytes to 16. That credit card company assigned three people for four to six months, and they identified 122 changes. RBC used their MME, and they identified 144 changes, and they completed the analysis from start to finish in 15 minutes, because they had those enterprise-wide impact analyses. That's what they had. That was their capability, and the results are astounding. I could spend a lot of time on this, but let me share with you just one last statistic, and I love showing this to executives. When you look at large banks like RBC, they spend very little of their revenues on their IT systems, very, very little. However, and some people may say, well, you know, they're not doing anything hard, they're just doing easy stuff. Well, no. They have a world-class award-winning data warehousing environment. They were one of the very rare companies to implement Siebel successfully. Siebel is failing in the 90% houses, the highest I've ever seen in our industry. Yet they were successful, and when you talk to it, so they go after big, difficult enterprise challenges, but what they will tell you is, their metadata management solution, that's the secret sauce to making them successful and able to manage it across their environments. Let me keep going. We're on our last two topics, and 10 minutes left, no problem. We can get it done. This is my top 10 list. What to avoid when you're building a managed metadata environment, and I always like to tell people when I give them a top 10 list, feel free to ignore these. We learn in one of two ways. I can tell you that the fire is hot, and you can believe me, or you can shove your hand into the fire and learn that what I told you is true. The way you want to learn is up to you. Let's move forward. I wish we had, maybe, I can get Shannon on the next webinar to shed such fun music playing before we began. Maybe she can have some David Letterman on top 10 music when we do these next time. But number 10, the MME team creates standards none of the supporting teams can follow. This is a massive problem. The standards we set need to be simple and understandable. Number nine, not creating an MME team or trivializing the effort. You cannot have one person part-time doing this like any other enterprise effort. You need to have a dedicated team of highly skilled professionals just like we do in data warehousing, just like we do in master data management, so on and so forth. Number eight, sailing to have an experienced project manager architect leading this effort. You know, I'm at a client today where I'm going to do, once I'm done with some data warehousing things I'm doing for them. You know, we have a team there. I'm going to actually be working on their metadata strategy. And one of the key things we know is that when it comes time to implement it we need to have somebody experienced who's been there. And then number seven, and I know we have a lot of DAMA people and data management professionals, you know, on this call. I recognize some of the names on our list we've called in. And a lot of the people, you guys are high-end professionals. And one of the things that I believe in is our job as data management professionals is to change the status quo. If at the end of the day we've built a managed metadata environment, we've done enterprise modeling, we've done data governance, and our company runs exactly as it did before, then we've failed. We are here to be a massive strategic advantage. That's what we're going to be. Number six, creating metadata silos or islands of metadata, an absolutely disastrous problem. Managed metadata environments are integrated. You heard me say that when I talked about the metadata repository component of the MME. Make sure that you are not just building a bunch of silos. It needs to be integrated. If you don't know how to do that, you can look. I think I have some abstractions for my book, Universal Meta Models. If not, I have a whole model in there. You can look at it. Number five, too many manual metadata integration processes. For business metadata that stewards use, you may need to have some manual processes because that business metadata doesn't exist today. But for technical metadata, you should be able to automate it. Number four, not providing easy access to the metadata. Do not be a metadata czar. When you build your MME, provide access to it. Don't just lock your hands around it and grip it so that nobody else can look at it, so they have to come on vended knee bearing gifts of frankincense, myrrh, and gold that you will provide them access to the metadata. That is the wrong way to do it. Number three, selecting a metadata tool without conducting an evaluation or defining requirement. One of my pet peeves, people do it all the time. To me, the selection of a tool or not selecting a tool is just a line item on a project plan. We still do our orientation. We still do our strategy. And at the end of strategy, we'll know, we've done a roadmap. We're trying to build. Then we know if a tool can help us and which tool is the best. Number two, trying to do a big bang or waterfall implementation, boiling the ocean. Iterative is the best approach. I've used Iterative now. I'm entering my 29th year of consulting. And Iterative is by far and wide the best approach. All right, what's the number one thing you want to avoid? Drumroll? Not defining tangible business and technical objectives of our MME. We've built it, we've rolled it out, and it doesn't solve a single problem in our company. So good business drivers are increased revenue, ensure public safety, decrease costs, saving lives, education. If you're a Department of Defense or government agency, assist the warfighter. And I'll tell you one here, regulatory adherence is huge. That is an area that at one time maybe 40% of our clients were interested in. In the last seven or eight years, I think probably 100%. Every client I've worked with has had an interest in adhering to various federal regulations. So that's the top 10 list. All right, last section, and then we're going to get to our Q&A. The Department of Defense, this is one of our award-winning projects, and we were blessed enough to win a DM review award and an intelligence solutions award. Who is the Department of Defense? Well, this is specifically Department of Defense logistics. So what are they? They are a $480 billion supply chain. So you're talking about half a trillion dollars of supplies or a half a trillion dollar budget. An $80 billion supply chain. I mean, the numbers just stagger the mind. Three million people, 80 million parts, I mean, eight million parts, sorry, global, 150 countries, and a dynamic supply chain. I get a kick out of the term dynamic supply chain because in this supply chain, people may shoot at you. So that's about as dynamic as it gets. Federal Express and UPS people don't shoot at them. Wait a minute, I live in Chicago, so I can't say that where I live, but in most of the places where you guys live, that would be the case. Anyway, a little bit of local Chicago humor. We are the, I think, homicide capital of the United States. So anyway, what's the challenge? So why am I talking about the Department of Defense Logistics? Every year, they cannot account for several billion dollars of inventory. They have massive just staggering data quality issues. And then look at these last couple issues. They fix or refine a process that causes them to break several others. Hmm, does that sound like your company? And this happened because they never planned the enterprise. They just grew over time. When you look at what the Department of Defense does, their scope has grown radically since the days when George Washington brought the militia together and formed really our first army. It's now just radically different. They do, they build, you know, they establish power lines. They build cities. They do humanitarian rations. They do search and rescue. I mean, their scope is monstrous. And that's the same as our companies. Most of our companies, we never thought we'd be as big as we are. So, all right, what's their architecture? The Department of Defense architecture is based on deploying their troops rapidly and reconstituting. Any of you who study military history know your military literally lives and dies based on supply. And if you can't supply them, you're going to have problems. The great example, the classic one, is Germany and World War II when they progressed so far into Russia. They got nailed by the winter. The supply line froze up. They couldn't reconstitute their force. They couldn't feed their troops. They couldn't get gasoline to the panzers, and big problems happened. Kind of interesting. I have this picture of the, of this aircraft carrier. When we were doing this project, there was a business user who, it was thought we might have to interview, who was on an aircraft carrier. And I said, I personally want to interview that person. Unfortunately, we ended up not interviewing them, but I wanted to. Anyway, enough of my stories of opportunities lost. They had their own enterprise integrated data environment, and I would love to take credit for drawing this, but I didn't. You can see when you look here, they have various e-business solutions, enterprise applications, all these processes. They have data warehousing. But if you notice, everything is flowing into this disk, and that's their metadata management. They realized metadata management was the key to data architecture. Let me just kind of wrap this up and open it up for Q&A, because I know we have some questions out there. When you look at the Department of Defense, this just shows you, based on supply, the basic concepts of logistics, which are plan, source, make, deliver, return, and enable. And this shows you, for the Army, Navy, Air Force, these little lines of business, Marine Corps, how many systems they have that do these concepts. So when you look at plan, we see the Army has nine systems. We see the Navy have two, and so on and so forth, just all doing this portion of plan. So it shows you the redundancies dramatic. So what we did was we, our client partner and us, we put together, we built them a managed metadata environment. They had a global one that was for the logistics domain. They had one for their little lines of business, Air Force, Navy, DLA's Department, which is Defense Logistics Agency. They brought in metadata from all these key sources, and it was all a seamless, beautiful environment that actually gave notices to people when changes would happen. So it was really, you could see why it was an award-winning project. Let me kind of summarize this, and we'll go to our Q&A. Number one, when you are looking to build your MME, plan your enterprise around the 2B processes, not your as-is. We have a lot of stuff that really doesn't work the way it should be, and we should be moving the processes that are superior and more standardized. If you're a federal agency, and I left this in for you federal guys, they always require to use COTS products. COTS is commercial off the shelf. They're very software-driven. Data strategy is the key to data interoperability, and what you need to know, no metadata management means no data strategy. You have to get this right. When I go into a company to do a data management assessment, I consider metadata management and data governance as foundational pieces along with enterprise modeling, foundational pieces, and if you don't get those right, you're not going to do well at master data management, at big data quality or whatever else is your liking. Compliance is an ongoing process, and guess what? Your business processes are really not that unique. You would think the Department of Defense Logistics would be unique, but they're not. With that, I'm going to pass the baton back to Shannon and opening up for questions. Thank you, David. Of course, one of the most popular questions that we get during most of our webinars is regarding when people will get a copy of the files in the recording. I will be sending out a follow-up email within Two Business Days to let everybody know with those links and anything else requested through the webinar. David, a question from Steven. We are facing a build or buy situation for our metadata management platform solution. We have limited experience in creating a scalable data model specifically for handling metadata. Is this something we need someone with a specialized metadata skill set for? What a great question, Steven. So let me give you a little bit of insight on that. I have had fantastic success taking really awesome data modelers, teaching them metadata management, and then having them met a model for us. So when you're by your build situation, I'd recommend a couple things. We do sell an industry-standard metamodel for our clients, but you could also just buy my universal metamodels book. And I mean, that model is not near the capacity of our other one, but it's still very comprehensive. I think if you took a really awesome modeler and taught them the concepts of metadata management, they learned and read about it, you can get them up to speed. Obviously, if you could find someone who has this experience, that is the preferred route, but that is not that easy to do. It's very difficult. Great question, Steven. And actually, Amos, the follow-up to that, he says, or is it better to procure a vendor product? But I think you are a vendor product and do the heavy customization. So there's a little bit of expansion on that. Absolutely. And I see his follow-up now. Shannon, thank you for pointing it out. Well, here's the deal. Just because you go with a vendor product, I cannot think that, oh, it's just done for you. The analogy I use, it's like you're building a fence. If I needed to build a fence, what products do I need? Well, I need a hammer. I need a saw. I need duct tape. You know, the tools I need. And when you buy a vendor product, they're the equivalent of the hammer, the saw, the duct tape, the shovel. If you have all the hammer, the saw, the duct tape and the shovel, do you get a fence? Well, no. You need somebody smart to architect the fence. Like, is it three feet, six feet, 10 feet? Is it metal? Is it wood? And then you need people to do the work, to dig the holes, to hammer in the nails, to duct tape the saw. I've never built a fence. Sorry, I actually don't know all the steps. And tools are the same way. So whatever tools you buy, Stephen, you are going to have to get trained up on them. You need to bring somebody in who has heavy-duty experience with them. A world-class kind of architect, I would recommend. Because you're going to need to know those tools, what they do and what they don't do, because that is much trickier. But, and I don't want to sound anti-tool, there's some fantastic tools in the market that can really help your program. Excellent question. Thank you, David. The next question is, what processes happen within the integration layer? For instance, how does the integration layer facilitate which final metadata must prevail over others for the same elements? You know, what a great, so very good question. Now that's a very technical question. So I would say it's just like your data warehouse in one, in the sense that you're going to look and say, what is my most trusted source for this data? For example, I had a client once where we were extracting physical table names and attributes from a data modeling tool. It was Irwin. And when they wanted us to do that, my first question to that client was, do you guys keep Irwin up to date? Or are you guys making changes in production? And they assured me Irwin was kept up to date. Guess what? When we did our own little analysis, because I never believed those things were being kept up to date, what did we find? That production differed from Irwin. So when we built our MME, we read the relational database catalog, pulled out the entity tables and attributes, and did a comparison to Irwin when there was a difference between the two. Obviously the RDVMS catalog ruled the day. Great question. Very technical question. I hope everybody followed that one. Yeah, we've got a pretty technical crag going on here. In fact, the next question is a two-part question going on here. Sure. What difference do you make between master data management and metadata management? And the second part of that question is, could a nontology play a role in metadata management? Absolutely. Oh my gosh. So the second part of the question, let me go after first, in the Department of Defense case study I walked through, we used a nontology. Well, we actually used a conical model. And all, when you look at an ontology, that is a really fancy word. And actually, as a consultant, I can build double if I use the word ontology. All it is is a hierarchy with a fasori. That's all it is. And certainly those are incredibly valuable too. As far as differentiating metadata management with master data management, I'm just debating if I want to use up the rest of our time on answering this, but metadata management is foundational for master data management. If you are trying to do master data management and you don't have a world-class metadata management function, good luck. You're going to have big problems because you do not know where your data is at. You don't know what it means and you have no organized way of managing it. So metadata is just a vital foundational component of master data management because it gives you all this technical stuff, your common, like, how are you going to define common processes? Well, you better have a great data governance program. I teach all over the country our data governance framework. And in it, you need to have a world-class framework where your business users can make decisions on what are our common products, what are our common customer types, what are these things. And then you take the results of your governance and your metadata and that's what drives your master data management. If not, many MDM efforts, all they do is mimic the existing point-to-point interfaces with the messaging bus. And that is literally the definition of insanity. You do not want to do that. Anyway, I hope I didn't go on too long on that one, Shannon. No. Time for one more question here. There's a lot of great questions coming in. And I will send out David's contact information along with the follow-up email with the links to the slides and the recording. So last question coming in here, can you speak to your experience in managing metadata in an enterprise data lake environment? Oh, my gosh, I wish you were at my talk at Dana Phoenix two weeks ago. I talked all about the data lake. All a data lake is. So we've not done it in a data lake, but you did one because you're most likely about to drown in your data lake. Data lake, I want to define it so everybody understands that all a data lake is is taking the tables that we have today in our operational systems, porting them over natively, meaning as is, and putting them into this new environment, probably with a dupe over it. We have a term, data warehousing people call that data staging for years, decades. So when you have a data lake like that, the way you organize it, understanding it, it's vital because it's going to look more like data soup than data lake. Because where is our definition of customer? Where are the customer tables? Oh, I found two of them here. A little do you know in another part of the lake, right by the bastard, there's 20 more of them. So an outstanding question. And the whole concept of big data and data lakes, guess what? For all the data management people, I know this is a Dana talk. We are more needed than ever in the big data world because they are failing at an astronomical rate and they need great data management to help them. Outstanding question whoever asked it. David, thank you so much for this presentation. It was fantastic. And thanks to our attendees for being so engaged in everything that we do. I love the questions coming in and continuing to come in. Like I mentioned, I will get a follow-up email within two business days. So for this webinar by end of day Thursday with links to the slides, the recording, David's contact information, and additional information requested. Again, David, thank you so much. This is just really fantastic. Thank you. You're so kind. Thank you, Shannon. I hope everyone has a great day. Enjoy.