 And I'm Kim, and I'm the Executive Editor for DataVersity. We would like to thank you for joining this month's installment of the DataVersity Webinar series, Big Challenges in Data Modeling, moderated by Karen Lopez. Today, Karen will be discussing modeling metadata with guest speaker Ian Rollins. 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 will be collecting them by the Q&A section in the bottom right-hand corner of your screen. Or, if you like to tweet, we encourage you to share your highlights or questions via Twitter using hashtag BCDModeling. Karen is probably one of the most active Twitter data or Twitter's people there at DataChick. You can always find her there. And as always, we will send a follow-up email within two business days containing links to the slides of the recording of this session and additional information requested throughout the webinar. Now, I'm going to introduce today's guest speaker Ian Rollins. Many of you are familiar with Ian as we invite him often to speak in Data Diversity webinars and conferences, but let me give a quick introduction. As Vice President of Product Management, Ian is responsible for the Enterprise and Application Management or Metadata Repositories, ASG Rosade and ASG Manager products and ASG BQIC and other strategic solutions. He manages product launch and delivery plans and correction and management of partner relationships. He was previously VP of Metadata Development, and Ian has many years of experience in application design and development and has managed ADABAS, IDMS, and D2 databases and design systems to run on a variety of hardware and operating systems. Originally from the UK, Ian is a chartered IT professional and standing member of the British Computer Society and like Karen, he also blogs for Data First City. As many of you know, our esteemed moderator, Karen Lopez, Karen is a senior project manager and architect at InfoVisors. She has 20-plus years of experience in project and data management on large multi-project programs. Karen specializes in the practical application of data management principles. She is a Microsoft SQL Server MVP specializing in data modeling and database design. She is an advisor to the DAMA International Board and a member of the advisory board of Zachman International. And if you can meet Karen in person and learn more from her, she'll be giving a couple of day workshops at Enterprise Data Diversity in Chicago. The first one will be on driving development projects with Enterprise Data Models and the second one on new modeling challenges, Big Data, Hadoop, NoSQL, and the Cloud. And with that, I will turn it over to Karen to get us started. Hello and welcome. Hi, Karen. You always do that so well. I wanted to thank everybody for attending, including my guest panelists. But as all of you out there who are logged in now, because I also consider you panelists as well. So make sure that you have your questions put into the Q&A, and that you can have discussions on chat as well. But it's easier for us to see the questions in the Q&A. And we'll take those throughout, so no point in saving them up to the end. Karen, I heard that you mentioned in the pre-show that you were traveling. Where are you located? What part of the world are you today? I'm usually in a hotel outside Heathrow this evening. I'm seeing that US Airways will get me home tomorrow. There you go. So today I'm in Charlotte, and I'm supposed to be trusting that Air Canada will get me home tonight. So last time I tried to get home from here, it took me 39 hours, so we'll see. So excellent. So we have a bit of slides today. For those of you who have attended a few of these, you know there's not only slides. I've just turned together a few slides with some terminology of things to help guide some of the conversation. One of the things about this topic is meta and data modeling. Like we do use the term metadata as we're doing traditional conceptual and physical data models. Karen's going to tell us that there's a lot more to it than just the definitions that we put around entities and tables. As we have a poll, we don't have one set up, but if you are a data architect or a data modeler or a developer or DBA or anything, you can put that in the chat just so you can say hi to all of us so that we can deal for it out there. Anyone to focus on the terminology and foundations and thoughts around metadata, what that might mean, some of the myths and gotchas, and also questions and answers that we have from attendees. I'd also like to hear in the chat and the Q&A, any specific topics related to metadata that you'd like for us to chat about. I want to see those coming down. There is another question of will you get a copy of the presentation? Yes, you'll get a copy of the presentation because Shannon's excellent at sending these out early next week along with notes and any links that we mentioned and probably also a link to promote the Data Diversity Education seminars that I'm doing in Chicago that Shannon talked about. One of the things that she didn't mention is the reason I love that event is all the sessions are half-day sessions or more, so they're not one-hour, quick slide deck things that they're in-depth with a lot of workshop quality sessions, not just someone reading you a PowerPoint, plus a lot of excellent speakers. Things that I always like to do in the webinars now and in my presentation is to talk about what the expected outcomes at the time we're going to spend together and I always like to talk about them in terms of the interrogative so very much as Ackman influenced of who, why, and where, why, and how and how much related to this topic and I like to frame that because this is a big challenge in data modeling along that stage. So here's your third question because some of the things we're going to talk about today and I'd like to start as a good data modeler with terminology and some thoughts around them. These are some of the words that I hear when I talk or research about metadata. The first one is my normal complaint is how do we spell it. So Ian, do you have a preference on how we spell metadata? You know there's some of the things to have patented the term metadata as you have it at the top here. M-E-D-A-T-A without spaces or hyphens. Research that, dug into it a lot. It really doesn't stand up. I'm happy with the way you have it at the top here. M-E-D-T-A-T-A. No space, no hyphens, no extraneous punctuation. If anyone wants to do it differently I don't do that much. I'm not a bigot about that particular item. I'm going to get about some other items. We might get onto some of those. But that one, yeah, I prefer the one at the top. It's the simplest, but I'm not going to start a religious war about it. Yeah, so I'm not either. Actually this kind of follows the flow of the lifecycle of most compound words. They start out being two words, like metadata, and then they get hyphenated, and then eventually they get adopted and they become one compound word. We actually went through the same thing for those of us that are experienced, like Ian and me. We went through the same thing with database, right? So we had database as two words, and then hyphenated, and then I would say almost universally, except in some academic publications, we'll see it all as a compound word. And then what I think on that is before we had Enterprise Data World it was two conferences to gather, and one of them was the metadata forum. So if any of you guys out there remembered that it was the International Symposium and the metadata forum, and there was always that question about how we sell it so that we could promote it consistently. So typically, so now that we've got that administrative out of the way, and we've agreed on... Wait, wait, wait, wait, wait, wait. Yeah, I'm going to stop this whole thing now, so people will know that we did... We haven't really scripted this like a reality TV show. This really is interactive and real-time stuff. Here's what's interesting though about what you just said. The reason it was two separate words at the beginning and it was saying the database is because somebody was making a conscious statement about what they were talking about. The data was somehow something that extended and said something about the nature of data. That was some kind of high-footed and intellectual idea and a meta was the Greek sort of term for doing that. Over time, one of the things that's happened is people have got confused about what the term means. And that sort of happens as the original kind of spelling and typography goes away. So one thing I kind of want to nail to the mast, if I can, is what I think metadata is. And I have a very, very loose statement of what I think metadata is. Metadata is all the other stuff that you need to know to make information assets useful. Let's kind of throw that out there because if anybody say data about data again, I'm going to beat them up ahead with wet letters. Exactly. I'm going to see that in a moment because I went to the intercubes and asked the interwebs what the definition was. So we'll see that in a second. And it's definitely something I want to talk about when we get to that. Some of the other things that come up as you search or read or have a book on these topics, you tend to run across that there are glossaries involved and that there's a data workflow and that there are repositories involved and that we're concerned about data formats as a type of metadata that we manage metadata for compliance for regulatory reasons. And we might have tools that do metadata extraction and I love all of these technical terms that have the word extraction because it sounds so violent or forceful. It's sort of an interesting term. We usually work about data life cycles and data lineage is the key thing about sort of traceability of data is how I learned it and a lot of people just talk about source-to-target mapping but I think it's more than just mapping of those things. Data lineage is a big discussion but it's kind of cool that you've got a taxonomy or you've got a bunch of terms there that could have been linked into some kind of taxonomy because some things you've got in here are about the data and metadata processes. So life cycle with lineage and extraction. By the way, I think metadata extraction is a great tool with that particular aspect because it is like pulling teeth, isn't it? And then you've got things on here that are sort of related to use cases like compliance and regulator and stuff like that. And then you've got things there or you've got one thing at least that pulls out the semantic aspect because glory is more about semantics and perhaps more about the business aspects of metadata and less about the structural and technical aspects. And I think as we get into a discussion about the modeling of metadata we want to talk about the fact that it's understanding that it goes from the highest conceptual business level down to the deepest and most technical kind of level who also need to address the fact that the range of assets being dealt with is very broad. You know, I was kind of appreciative of the fact that you, Karen, are on the Ackman board because one of the great things as Ackman Framework does is it actually does a really good job of drawing out those different aspects in the distinct levels of detail. And you almost take this bunch of terms and put them at appropriate levels and inappropriate cells as some kind of framework connection. If there's a thing about modeling metadata, that's a good architectural perspective. So we know we've got somebody who's really whining about, or sorry, complaining about the fact that we're over egging this particular cake, so I guess we need to move on. One of the things, so I'm just going to make sure I'm clear here. When you propose a taxonomy of metadata terms, I'm pretty sure you just pose metadata data, didn't you? Oh, yes. And then we need a taxonomy of those terms, wouldn't we? You didn't know when, right? Actually, there is and there isn't. It actually goes to one of the few formalized approaches to modeling metadata, which is the one articulated by the Object Management Group in the Meta Object Facility. And it has exactly that notion of, so there's many things, data-like, and then there's the model of real things, which is metadata. And then there's the model of the model, which is the Meta model. And in principle, it feels like you could go on into an item. But in fact, once you get to about the third level, it would be self-defining, and we don't need to go any further than that. But yes, it's worth understanding that if you want to be really model-driven, understanding the idea of the Meta model is a really good one. Excellent. So one of the reasons, though, that I wanted to set a definition for this term is I think there's a lot of confusion of just what it would be. So the number one thing that I've kind of got listed later is that something like all the stuff you put in your Meta model using potentially available data modeling tools defines the full extent of all the metadata we'd ever need to collect, manage, or control. So how do you feel about that? Well, there should be no way to ever know what all the metadata you would ever find useful is. It's hard to predict that in advance. And secondly, it's extraordinary how many people collect far more metadata than they can ever usefully use. Sadly, I think what happens is when we collect all metadata and we figure out use cases, we don't start with defining use cases up front, and then decide what the model needs to look like and how we need to populate the model to support those use cases. Often it's kind of thought of as a generic keeping type of exercise. Perhaps because it's just too challenging to try and speculate about what the useful uses might be. There's an argument there for being able to be fairly agile and go back and add new types and add new attributes and things like that on the fly or relatively simply because things change all the time and you don't know what you know. So we're going to start with the first question of what you mean by metadata, and you did come up with a definition. Can you repeat that again? Because someone else has asked for it again. My definition is a very simplistic one. It's all the information that you need to make your information as it's useful. Excellent. One of the things I've pulled here, like I said, I asked Google for a definition of metadata knowing that I would probably get data about data because that's the literal interpretation of that term. Maybe the denotation of it. And one of the things that I like about when you search for definitions in services is they give you sort of the occurrences of that and how it appeared over time. And you can see from here that this is a relatively recent term and there's a nice discussion on how it came about in Wikipedia so I'll put a big asterisk on that because I don't use Wikipedia for research but it's a good way for starting out things. And the reason we bring this up is that I've tried to do metadata work on some projects and there's a resistance because it sounds like a word that the business terms would never use the business people would never use and the one exception to that these days even though it's been around for decades is that there's a lot in the news over the last couple years about metadata due to the NSA surveillance and governmental surveillance not just in the US but around the world. And I think that's both a good thing for those of us in the data architecture world because it's now making people think about metadata as something that impacts them directly. It's not just a database term. It's not just a design function that actually is of information as well. Do you agree with that? Absolutely and I think there's a much more practical or classroom use case. I'm a big fan of iTunes and you know you pop up a screen that shows you the 17,453 tunes that you've got that you never play. All that stuff there is actually metadata about the digital asset that represents your... And it's funny. Your folder is actually called metadata so I popped that up and I told the people I was dealing with with the standard body that the young people know what metadata is. Maybe you should too. That's a low blow. I was. But do you think that people use metadata a lot but they're still right to say that the M1 itself is somewhat intimidating and actually I encourage people not to use it if they can get away from it. And other things that we've noticed about successful and sustainable metadata management projects is that they're usually branded with some friendly kind of name that is different from the metadata repository. So a lot of them are called things like ME and MS or Enterprise Metadata Management and that's kind of... You want to use the information, right? Yeah, excellent. So one of the other things about... So what's different about it is that what's the difference between just... What do you mean between the difference of data management and modeling metadata? So a few data models about the business or about databases. What's the difference between just sort of managing the metadata to do those functions and modeling the metadata? Or is there a difference? There very definitely is a difference and you can almost say it's the same difference qualitatively as the difference between modeling data and data management. And there's a whole collection of functions like collecting, storing, managing, disposing of securing, protecting. There's a whole collection of activities around metadata that collectively constitute metadata management and modeling is on one component of that metadata management. So do you use regular data modeling tools to model metadata or do you use it as well? So as you know Karen and some people may not I'm incredibly old. So when I was young I was very, very carefully educated in how to do relational modeling and all of that good stuff. And then somebody asked me on the shoulder and said, right, well, we've decided that you're going to be in charge of this new thing called metadata and repositories and I know, well, that's cool. And the other thing I looked for was the modeling and I thought that there weren't any and actually it turns out that things like relational modeling or the standardized kind of applications, modelings, capabilities that we've used don't really work very well for modeling metadata. And one of the things I keep hoping is that somebody will come up with some really cool algebra for modeling metadata. But so far nobody's really done that and that means that to an extent will be important some of the concepts and disciplines from both class data modeling and from application modeling and from the EA space. There's still an influence of this that is artistic. And there's a number of reasons for that including the fact that the nature of the relationships are actually fundamentally different. The idea that modeling metadata is dealing quite often with reflexive and recursive relationships which means have interesting requirements for representation. Yeah, that's a very interesting point. So why should an average data architect or developer or a DBA isn't this just documentation? Why should we care about it? It's not intellectual? Why should we care about what? Which question was it? Metadata and metadata modeling. So I would argue that it's pretty important to be able to model metadata for exactly the reason that you talked about earlier, the notion of abstraction and, yes, indeed, enabling agility. If I want to be able to, for instance, pull together metadata that relates to a whole bunch of databases or a whole bunch of logical models, it would be really nice if I had a layer of abstraction that allowed me to define those things. And really one of the things that metadata modeling allows me to do. So it actually enables me to do things like aggregate and add the relationships between and predict changes related to underlying the assets that I'm managing and modeling. So, yeah, I think it's important as an enabler and one thing is about modeling. Can I just make two very quick points? Two quick points about modeling. One is modeling is always a good discipline because it makes you think about use cases. The other thing is modeling is always a simplification. If you think about what a model is, it's always a simplified representation of something for a particular purpose. And so, yeah, simplification in use cases is essential reasons for modeling. So one of the questions that Eric had asked is, would ontology be a model of metadata? Ontology is a lot of some of the semantic aspects of metadata. And I'm sorry, but I wasn't the one that introduced $10 words. So we have ontologies which please semantic specialists out there forgive me for what I'm about to do. But ontologies are essentially descriptions of the relationships between the concept that an organization uses to think about itself. When we get down to the center level, the things that we think about or the things that we're describing don't really behave in different ways. And one of the things I tried to do recently because I'm thinking about how to put together the semantic world and the data world in a more structured and disciplined fashion is that the the algebras used in the semantic world and the algebras used in the delta world are actually different. And mapping one onto another is an interesting challenge. So ontologies are an aspect of the data, if you like. Interesting. That was good because that's my next question. So what is a typical IT organization? What roles or positions are usually responsible for and tasked with using metadata modeling or managing metadata? Do I keep talking about both things at the same time even though they're different things? So in a way, she typically is two things. Data developers eventually get some part of data modeling and enterprise architects or architects in general get tasked with some aspects of it. One thing that is very unusual in the organizations that I talked to is that somebody kind of gets assisted to do metadata modeling without having any kind of prior modeling background. And I think that would be a pretty tricky challenge because as I said earlier, we import some of the notions from other modeling areas and so I think it's natural that data modelers and architects are the ones who usually acquire this capability. Is there a job like meta-analyst or meta-data-architect? Like what sort of... Yeah. Those are the job titles. And I always kind of thinking more about who are the people that tend to end up owning those titles or in those positions in the actual job titles. You're absolutely right. Those are the kind of titles that people get. And it's an unfortunate title to inherit in a way because, you know, you're in a party and somebody says, what do you do and you say, meta-data-analyst, and of course, are you over? Well, now I know you work for the NSA at this point. So, again, also, where do these people sit? Are they on the business side of the organization? Are they NIT? If they're NIT, are they in some data-based, state-data group? Are they in a private lecture group? Are they in a community group? Where would those responsibilities lie in a typical organization? Actually, it's transitioning to be a pure IT function. And, you know, as well as I do, I think that all of this started in really three places. You know, it started with people doing data-dictionary types of things to put together definitions of record outs to make sure that programming was efficient and reliable. And then there was another thread that started with document management and things of that nature. And then there was a thread that started with DBAs and things of that nature. So it tended to be very, very technical. And I suppose I should qualify and say, look, I'm talking about the kind of metadata management that goes on in the typical business-centric enterprise. I'm not talking about library metadata management or geophysical or stuff like that, which has different backgrounds. But the classic kind of enterprise business-type metadata management started as very, very technical, but it was shifting towards the business layer. And it's shifting in that direction because it's being driven by governance and compliance requirements. Can you expand upon that? Because that's more of the why. Why would keeping your boss out of jail cause you to worry about metadata? Well, that's a large assumption. What makes you think people want to keep their bosses out of jail? But assuming that was the case, we're increasingly seeing regulatory compliance requirements tie back to that thing you talked about earlier, which was traceability, right? Data traceability and lineage and things like that. One of the really interesting things that happened to me recently is that it's part of the vital set of requirements. One of the things that came along was the vital compliance requirements for something called risk data aggregation, which is, okay, you're a bank. How do you figure out your total exposure to all the various risks that might apply? And then there's a really interesting core document that actually explicitly establishes the requirement for metadata management and things like glossaries and other inventories that business requirement. It's the first time, I think, that I've seen all those business regulatory documents explicitly call out the need for data management and traceability and things of that nature. They've been there before in an implied fashion, but increasingly, it seems regulators are starting to make explicit requirements on very senior management to establish that the data management practices and traceability, their governance are as they should be. And so, an order or compliance regulator goes along to a bank and says, okay, show us the numbers. Show us where you got them from and prove that the underlying mechanisms are around. And at that point, you really turned what sounded like a pretty technical issue into absolutely a business issue. And I think, you know, I've told a lot of people if you want to do something as part of your data management process is that linking on compliance, audit, regulatory, impartiation is a good way to motivate the business to understand how doing this might mitigate their risks of compliance with those things. I think we talk a lot about, you know, great it's going to be if we only did all these things, but making it real for the business makes it difficult for the business to want to invest in it. If you can establish for a financial institution that if they do this stuff right, they have more capital available for investment, then you establish a positive business value. Or if you establish that if you do this wrong, you'll go to prison, then you establish a fear factor. But trying to persuade people to do it because it's just good practice, it's the right thing to do. It doesn't work. It doesn't work at all. And I'm talking to a fairly senior executive in a financial institution here in Europe. And he said, you know, if we didn't have to do this stuff, there's no way in the world that we would want to do it. What do you want to do it for fun? Let's see. Next slide. Trying to answer questions in the Q&A at the same time. So, can you get a judge on this? So, how does metadata modeling happen? So, using the reference to my first exposures to metadata management, which was the use of the first occurrences or usually called repository tools. And what we did was, you know, you could download all your data models in there. And this was before we had data modeling tool repositories or model model managers. And we would download all of our data models in there. And we would also use some scrapers or scanners that would go through and scan through all of our databases and code copy books and file layouts. I can't remember all the things. And that would pull in all that data and we would use this use the repository product to link everything together. So, that was my first exposure to it. And a lot of it was a lot of manual effort. We're going to link those things together. And then, but we also did some metadata management, at least through whiteboards and spreadsheets and spreadsheets and probably Microsoft Access database that we had now. So, the how is a really interesting question. By the way, there's a very good, there is a very good discussion going on in the chat about, you know, the challenge of trying to find where a particular piece of data came from and how it got where it got. And I can say that that could take not just hours but weeks and even months. So, that's really the point about this thing. Pretty every source of information you deal with has metadata either explicitly in a catalog or implicitly embedded in itself somehow. And one of the things that you're going to do when you're among metadata is try to figure out what types of entities are within particular information sources and how they relate to entities in other information sources. And we can kind of describe that at the very elucidest way of saying, this is what metamodeling does. Metamodeling says there are types of information assets. The types of information assets contain particular types of information and those types of information relate to types of information and other information assets. So, that is a kind of abstraction of the process. And remember, we're talking about modeling here, so it's always an abstraction and a simplification of one that you could do. And a lot of people start this way. As you start off with a cheat and you say, well, I've got these information and some asset types. So, I've got databases and models and KL tools and BI tools and so on. And I've got an inventory of each class and in each class, I reference these particular information assets, whether it be rows and columns or logic models or transformation rules and things like that. And I actually manually kind of track the connections. And as long as you're really only dealing with a small subset of all the information in your enterprise, that's actually a good way to get started. It really gives you a handle on the nature of the problems. So, a little later though, you're probably going to get some kind of technology like the repositories you talked about. And almost any technology that you get is going to have this language if you like to describe things like information assets and the types within them and the relationships and things of that nature. And in the end, a meta-model is a linguistic description of information and all the tools have that kind of linguistic description of the animation. And then that's really what you end up doing whether it be an OML type tool because it's an OMG classification or sort of analogous thing to that which tools like the ones that are responsible for have something of that nature. It really comes down to that very simple idea. We have information classes. The information classes contain information about item types and the item types of attributes and the connections between them. Good, thanks. One of the things I've experienced is that people want the outcome of metadata management, having leveraged some metadata modeling. We'd like to be able to say, okay, on this form, what data comes from, which systems, which integration points, all of those things. Can I find out who the data steward is for that person? Can I find out what legal issues are surrounding that data? Is it HIPAA? Related data? Is it required data? Is it personally identifiable information in metadata? Is it personally identifiable information in websites? Because those are separate designations for a data point. They do all that. But there's a lot of work in amassing all that data and keeping it up to date. So how do organizations, even if you went through and established all these relationships, is it something that can maintain? How does that maintain? So that's an interesting aspect that we are really seeing people start to wrap their arms around now. Most of the major enterprises that we have been working with over the past couple of years or so have started to get very explicit about determining what their critical business entities are. And we're only really worrying about the detailed metadata management for things which they have deemed for some reason or another to be critical. There's an element of risk involved in that because, as I said earlier, who and I don't know. And there is an element of pragmatism to it because the sheer volume of information assets that might have to be managed could well be overwhelming. The management has... Sorry, Heather. No, I'm not agreeing with you. Data. One of the things that people don't really grasp is that actually, metadata management is a super set of all the applications that you're managing. And the databases, and should be spreadsheet and extra documents floating around. And you're learning through them, monitoring things, email, voice calls, all of that, right? Yeah, and of course, we've avoided the elephant in the room so far that big data is coming along, and big data kind of spans it in multiple dimensions. Well, you know, for me, a statement on big data and all those things is it doesn't change our fundamental data management response, right? It's just one of the things that I've thought about is that enterprises are using things that are traditionally associated with big data, like video, like voice, like very rich files and everything, is that, you know, those always fit into our traditional relational database management systems, and they don't always fit in our traditional development processes that in the past made an assumption that that's where enterprise data went. And so outside of some of these big data projects and implementations are being done totally outside of our normal processes and our normal data governance, so we start to see that they're being managed the same way either, that they're not getting data protection and analysis, that collecting the age of the data and no one's tracing the data lineage, can't we? Because we point our regular tools to them. And lots of webinars over the last year about, you know, data modeling and big data, but I think meta data and big data is still the same, we still want the same outcomes, don't we? Well, we do, but one of the things that we're seeing is almost a real visit of what happened with the data warehouse world, you know, and people, you know, built data warehouse technologies, and in it was, we're just going to do the data warehouse stuff. This is great. We can learn so much that we could never learn before. And then after a while it was, why is this becoming a real lab or why are our results not what we expected? And it turned out to be the difficulty of impact analysis and change management and things like that as things changed. And it wasn't until people had been doing that for a while that they figured out that they really needed to be collecting the metadata because that was how they held the whole thing together. Well, I see the same thing happening in the big data world at the moment, you know, people are saying, you know, we don't want to do metadata management, we don't want to do governance because we're getting great value out of all of this activity. And you know what? There isn't this value being got out a lot of the activity. There's a bunch of risks built up and I love what somebody said about metadata. I think somebody said metadata is a love letter to the future. I've seen that picture. I love that. So one of the things, you know, and Zachary would say about your status there is that what I would say to people is you are doing metadata management. You probably just haven't formalized it. So now every single person on your team is doing that separate metadata management. We could say that about any of the data-related disciplines that you are doing in it. You could be doing it 20 different ways. Or 50 different ways with no data to really leverage that when you want to integrate data or share some of the understandings about the data across an individual developer. Oh, we were. The only thing worse than islands of data is islands of metadata. Yeah. Collecting it many times over and over. Yeah. You know, all those things that are data-related. Yeah. Yeah. You know, about the metadata in the big data world is very often the big, the metadata isn't in any sense externalized. You know, you actually have to go and scrape it out of things like Pig Latin or HiveQL and things like that because it's not actually, because it's made through the environment, it's not separated out from the data. Yeah. Excellent. Next question about where. So where do we do, so we've talked a little bit about where we do the metadata modeling and everything, but where should we store and manage all of this metadata? I know a lot of my development tools and my architecture tools all have a place to put it. I can use my enterprise architecture tool to store some of it. My data-related tool, I store it at some time because people have given me requirements that way. I know my DBAs have tools where they're storing metadata. It needs the best tool for whatever we're collecting data about. So that's a very interesting question because it also has shifted over time. There was a point where every individual tool had its own metadata and there was no rationality between it. Then we went to a cycle of building big enterprise metadata repositories and populating that and letting that be the small and single place in which metadata was supposed to reside. We are moving, and the next thing was a kind of desire for some tight federation of multiple metadata stores. I think we're actually heading towards a world where there is a central kind of co-ordinating laboratory of enterprise metadata but there's also loose coupling to a bunch of other metadata stores because they're legitimate reasons for the various tools to have their own stores and to manage them in different ways. But I continue to think of the enterprise repository as the little ring to rule them all to drastically shake. I think it's the same architectural question we have for just databases and federating them. Should you put all of your data on one database server or is your data warehouse to be the one data warehouse to serve them all? Or do you break them up into specialized uses because there are a lot of them that sit there? I think it's a classic architecture question. It's just a meta-architecture question. That is exactly right and I can make good elements in different business spaces for all of us as it were. So in my last slide, I just stole one from another presentation so this is definitely very project-oriented meaning an application development or acquisition or integration project. Typically, we might see database architects and I'm using that term very broadly. We usually see them invited to the game very late in the process like during development and deployment. I use this slide to talk about how their roles for an enterprise architect is right at the beginning of a project and maybe a design slash development architect coming in slightly after that. But if I were doing a typical IT development project and I wanted to both leverage metadata that we already have and maybe identify and collect some data on where that work happened and a typical life cycle of a project. So this is the when-to-use metadata question rather than the when-to model or create it. This is a pretty waterfall perspective on staff. But if you take this kind of perspective, then you use the metadata at standing through five on this chart. In other words, all of that. What you use may shift as you move down but for instance, project administration. Well, all that stuff you've got that's representative of your application portfolio, your project portfolio, that's metadata and then you're getting into architecture and infrastructure design. You've got enterprise architecture models and maybe you've got the CMDB which by the way is metadata. It just happens to be the data about infrastructure. I want to explain what that is for people. Explain what a CVM is. CMDB is a configuration management database. It's the thing that the service management people use to store information about anything that is needed to deliver an IT service. So that could be hardware, software. It could actually be people. It could be furniture. And the interesting thing is if you look at it closely, what it comes down to is that there are entities which have attributes that need to be related to each other which is remarkably like what the enterprise repository looks like and really a configuration management database is the infrastructure analogy to a metadata repository in the information asset world. And one thing that's really interesting is you could define an enterprise architecture and you could say, so this is our enterprise architecture. These are our deployment patterns. Let's go out and look at the thing we've actually got deployed which were represented in our configuration management database and see if they actually match. That's all. I mean, that is helpful if we manage metadata just like if we manage data models, like how do we make sure they're kept up to date and you know, as part of the process they're more likely to be kept up to date and all of that. So we're getting down to just the last five minutes and I wanted to make sure because I always like talking about this. What are the unicorn myths related to about metadata? Like, so you came across your first one that the definition is data about data. So we'll just get them out of the way. What are the other myths about it? Well, you threw out a good one actually which is you could do anything with data without actually having metadata. The idea that you're not managing metadata is a myth. That's a good one, I think. The idea that it has to be difficult and expensive is a myth. It's really only difficult and expensive if you're applying it to an average and difficult challenge. So those are a few. So I did mention one early on that business people can't understand the concept of metadata. I think we just have to have them and using the analogy of photograph metadata because that's what they call it as well and the things that come out of the library sciences and document management people, they talk about metadata all the time. I think I can show them our server people and our operations people track all kinds of metadata. They might not call it that. They might not call it the configuration data or any of those things. I think it's one of our problems in the IT world and also unforgivable in the data management world since we're supposed to be all about semantics and definitions and having good examples and single definitions of the truth is that we tend to throw these terms around and because this one has the word metadata in it that people are just sort of turned off by the term or allow the marketing people to business. I think you can get the business engaged and excited about managing these things would be possible to them and we don't have to insist that they call it that about data. The thing is to say that people can't understand metadata is to be grossly insulting. Those people understand very well if there's business value in them understanding. It's an assumption that business people should have to understand IT is to my mind an ill-founded assumption. They ought to have to understand as much as they need to know to evaluate their business functions. Yeah. I think that the other myth about metadata is related to the fact that you have to do all of it or none of it. The big metadata management program and the big repository tool that's highly automated or you shouldn't bother at all and let metadata just sort of be haphazardly managed and collected new. You're right on. You made the point earlier that everybody is doing metadata management. I touched on the point that a lot of people are starting to run down what they do to the stuff that is regarded as in support of critical business processes. That is where the truth lies. You should do just as much metadata management as you can prove business value before. Yeah. Excellent. Down to the last few minutes, and I was just looking at the Q&A and some of the chat, I had to ask people to give an example, a data example of understanding or lacking of metadata caused some sort of data free, I like to say, or data problem. Do you have anyone off the top of your head? That's an example of how that data is part of metadata management or understanding costs and issues. We were already old, but there was a presentation from a teleorganization once. Well, then the DAMA conference is now the UW conference and a gentleman stood up and said, well, we had trouble changing our rate plans far enough because we simply couldn't understand what applications we're doing. That was a pretty interesting business application for metadata management, I thought. The other one is an organization that had an misunderstanding of what people were talking about when they were talking about revenue, which is the value use case, of course, and as a result, they created resources from one area of their business to another, much less from their profits. Yeah, so I think we hear lots of those, and it really does come down to misunderstanding or misusing data that you thought. So I know we're at the end of the time, but my classic example that I use a lot is that people want to use the ISO list of countries as their reference data for their drop-down to the country because it's managed externally and it's kept up to date, but the problem with that is not understanding that the future, the meaning of that is the current list of countries. So I'm asking a question about where someone was born. If the country were born and longer exists as a country, it's not going to be in that drop-down. So that's not understanding the data. It's a great practice to use data that you have to understand its limitations, its timeliness, how long it's updated, where it came from, and all of those things. So it comes to the end of our hour, and boy, that went by really fast, didn't it? I know, Ian, that you have to run, and I've got about 10 more minutes that I can hang around, but, Sharon, did you have a closing thing? I just want to, of course, thank Ian so much for joining us this month, and, Karen, thank you as always. And as always, a big shout-out and thanks to our attendees who are so engaged in making comments in the chat and getting involved in the conversation with questions and on Twitter. So I hope everyone has a great day. I will stop the recording, and I will be sure to get out the links to the recording, the slides, and other things mentioned throughout the webinar today by end of day Monday. You should have that, so if you don't have it in your inbox by Tuesday morning when you walk in, send me an email, and I will be sure and get that to you.