 My name is Shannon Kemp and I'm the Executive Editor of DataVersity. We would like to thank you for joining this month's installment of the DataVersity Webinar Series, Enterprise Data World. This Webinar Series is designed to give our Enterprise Data World conference attendees year-round education, a conference we produce in partnership with DEMA International. Enterprise Data World will be held this year in Austin, Texas, April 27th through May 4th, 2014. And if you want to save $200 off your registration, be sure you register by this Friday to take advantage of the early bird discount. Today's Webinar is a preview of one of those talks you can experience at the event, metadata management, getting off on the right foot with Ian Rollins. And just a couple of points to get us started. Due to the large number of people that attend these sessions, he will be muted during the Webinar. For questions, we'll be collecting them via 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 via Twitter using hashtag EDW14. As always, we will send a follow-up email within two business days containing links to the slides, the recording of this session, and additional information requested throughout the Webinar. So let me introduce to you our speaker for today, Ian Rollins. As Vice President of Product Management, Ian is responsible for the Enterprise and Application Metadata Repositories, ASG Roshade, and ASG Manager Products, and ASG BCubic, and other strategic solutions. He manages product launch and delivery plans and creation and management of partner relationships. He was previously VP of Metadata Development. And before ASG, Ian is Director of Indirect Channels for VIAsoft and leading EAM vendor acquired by ASG, owning relationships with partners outside of North America. He has worked extensively in metadata management, IT systems, and financial management, and presented at conferences worldwide, including DAMA and CMG. He has many years of experience in applications design and development, and has managed many different databases and design systems to run a variety of hardware and operating systems. Originally in the UK, Ian is a chartered IT professional and a standing member of the British Computer Society. We have worked with Ian often and always look forward to him speaking with us. He also, be sure to check out his blogs on Data Diversity, and we're very lucky to have him here with us today. And with that, I will give the floor to Ian. Hello, and welcome. Thanks, Shane. You know, for anybody who didn't do it, you always need to check early to these webinars, because Shane puts on the greatest selection of musicals. I wanted to say I really don't think there's a link between the hard-hearted Hannah, the vamp of Savannah, and the screening section. Metadata management, getting off on the right foot. You know, that's my EDW 2014 session, and then Shannon came to us and said, well, we'd like you to do a preview presentation for that, and I thought it was great. Yeah, I'd like you to do a preview presentation for that. I just discovered that the preview presentation is about as long as the LeFauvre EDW 2014 session itself. So I'm taking a slightly different spin here to focus really be on one of the topics that I'm going to be talking about in Austin Meta. Because there's a range of topics that I think you need to deal with to make sure that when you kick off a metadata management program, it's successful, and not just successful, but sanable as well. It's taken a whole different half-dozen topics, probably, and put them into this list, too. But this time around, I'd focus on what I think of as, in a way, the soft topics rather than the hard topics. There are other things that I could talk about, like the structure of the project and what metadata is and all that cool stuff, but I thought we'd talk about some of the management type and process type of things today. And I want to talk about why these things really matter. And then when we get to Austin, we'll do something slightly different. There's a big pre-question that we might want to address as well. And the big pre-question really is, well, why do metadata management at all? And as I thought about that, I thought, yeah, I'm going to shamelessly steal this great cartoon that I saw. That is a love note to the future. Isn't that a wonderful idea? And sort of it really is, I've been in this IT business for 35 years. Now, anybody who meets me, looks at me and says, that can't possibly be true. Be true, it couldn't possibly be more than 30, but it's getting to more than 35 years now. And I look back over all those years, and I think about all the time I've spent researching data and applications and models, and all those great things and thinking, if only somebody had documented some information about this stuff when they were creating it. My life now would be so much easier. Maybe that's the point. The metadata that you attach to your information as it's now will be of incalculable value to those that craft you. Actually, there will be of incalculable value to yourself too. And you get into trouble trying to say that word twice. Another is the way of making sure that you don't lose track. So that's really why we're here and what we manage metadata and what topics matter. Well, to Austin, I'm going to kind of change gear a little and shift the focus to specifically the how of all of this stuff. How do we justify the data management? How do we take stakeholders? How do you wrap your arms around the scale of a metadata project? How do you market a metadata solution? And if that's good enough, notion is making your eyes open a bit and making your eyebrows good, because that's one of the things that I feel very passionate about. Manage sustainability. And I'll talk about what that means. I have to say that I really don't mean how to avoid printing metadata models on the reams of paper so that you save the trees. Those are good things, but that's not what we're talking about here. And finally, how do you work with vendors? Now, I'm aware that I've got some of my colleagues on this webinar and some of them may be disappointed because I'm not in the business today of selling ASD's metadata and management solutions. They're very wonderful. And trust me, we will plug them to you. We'll be happy to do that. But today, when it gets to the vendor session, I want to talk a bit about how the relationship needs to work and just how complex the VET ecosystem can be. But if you don't manage that successfully, that will trip you up as well. And really, my objective here is to avoid or help you avoid the things that I have seen being metadata and management programs hunching down around the ears of those that have been tasked with dealing with them. So let me try and give you these topics and give you a sense of my view of why we care about some of these issues. So let's start with the big one. I have to say, by the way, that I hope to be speaking for 40 to 45 minutes and leave a fair amount of time for Q&A at the end or random abuse, if that seems to make sense. When we get to the end, I'm hoping that we're going to have a fairly lively discussion about some of this stuff and maybe also tee up some of the discussion for our customers. Let's talk about why bother justifying metadata management. That is a serious question. And why should bother justifying it? Really, it is a serious question. And it is a serious question because quite frankly, metadata management is not cheap. It's not cheap in terms of the software you buy. Well, frankly, that may be the least of it. It's not cheap in terms of the effort that you're into it. And it may also not be cheap in terms of what I might call the political capital that is going to be expended if there's going to be a really valuable initiative for your organization. So let's talk in just a tiny bit more detail about some of the reasons for justification. First of all, of course, and sadly, it's the one that people perhaps spend more time on than anything else is funding. There is no doubt there is money to be spent on those things I just talked about. There's money to be spent on buy software. There is money to be spent on infrastructure. There is money to be spent on education. And there is money or resources that needs to be spent on implementation. There is money to spend or resources consumed, populating or propagating the set of facilities around your organization. So there is undoubtedly a cost to your own business. And frankly, if you do not sit down at the front and figure out the cost and benefit of what you're going to do with metadata management, it's all getting through and somebody pulled the plug on you. Worst case, you actually get years in. A sad story that I know in the metadata businesses, when I went to an organization, actually it was an organization in South Africa, which allowed them to identify themselves. And I sat down with the technical people and the technical people said, we've been working on this for three years. We've got all the metadata into our repository, ready to go. We're launching next week. And perhaps 30 years later, I went next door and talked to business folks and their executives and I said, so you're launching your metadata project next week. And the metadata, you know, we remember that. You know, those people have been working on it for three years and we've got nothing. We're pulling the plug on that. You know, that's the risk. So you have to figure out your funding and even your cash flow. The soon reason for justifying metadata management is it's more subtle. But if you go through the justification process, you ask yourself the question, why are we doing this? And if you ask some people, I know, you go through the question, if it is, why are we doing this? Well, that doesn't matter. Yes, but it's that important. It actually enables you to focus your program. And focusing the program is a very important issue because there's a ton of stuff you can do. I think there's anybody on this webinar who hasn't looked at metadata management and said, oh, that's kind of like a mountain range because there's all that structure, traditional, classic data that I want to manage. And then over there, there's all that kind of content stuff, documents and things like that, and maybe I want to manage that too. Now somebody's come along with this big data stuff and maybe that's got metadata too. And by the time we come to Austin, we can chat about that. That's a whole other story because there are a lot of thinking in metadata. So, you know, there's the issue of focus, which actually drives you to define the boundaries of your project. Thirdly, there is the topic of accountability because you establish the funding and you establish the focus. You're starting to establish a straight line of responsibility between payment and benefits. And that actually establishes accountability and makes people responsible for the program. Not the people that are busy doing the metadata management implementation work, but the other people that should be playing nicely with them. And that is a very serious issue. These are things that can very easily trip you up. Lack of funding, lack of focus, or lack of accountability. Justifying the metadata management program and making sure everybody knows what the justification is and communication justification is a very important issue too. It's kind of great to work in your office and create yourself a nice little spreadsheet with a little numerical justification. If you help me indicate that and sell it, it doesn't work. Justifying the justification is very important. Probably the first thing you have to do before you can get off the ground is the topic. Imagining your stakeholders. By stakeholders, I mean anybody who can be impacted by your metadata management activities so it might be people who have to lose money. It might be people who have to gain money. It might be people who have to increase time. It might be people who are getting business value or people who are working for them. It might be people who are getting IT value or the folks that work for them. It may even be the people in your organization who are responsible to help you who are responsible for protecting and managing your infrastructure. At least this set of people are the stakeholders. And as you can see, I've kind of vulgarly called people at the top left-hand corner, the me. In the end, it's signing a check for all of this. It might be a CIFR, it might be a CIO. Don't know who it is, but whoever is signing the check is a local stakeholder. They have to, in the end, get value to money. Another thing I learned fairly early on in my career, at least my career in the underworld, went down with somebody and they said, essentially, well, I can open a new branch office or I can buy your stuff. Why should I buy your stuff? Well, that's something that needs to be addressed. There's nothing to do, clearly, to understand who your stakeholders are. But why should we bother managing them? What's the point? Should it be explicit concern? And I'll pull out these four major things to think about. The first thing is your stakeholders are the people who will bring you resources. Of course, the fairly basic resource of cash needed, your resources in terms of people, resources in terms of the citizen of metadata, the data, the content, the big data, focused in the Q&A already that somebody's observed. But really, there is metadata with big data. I just threw that one out there to provoke a discussion. Shame on me, and we will talk about that a bit. But the stakeholders will bring you the data. They'll also help you understand use cases. It's vastly unlikely that any task with managing metadata or building a metadata management program will go from the beginning, site unseen, all valuable things that metadata could be used for in their enterprise. It's equally unlikely that they'll be able to put a value on it. It's really hard to understand why is this particular use of metadata one that we should invest in, and this is one that we shouldn't? The stakeholders will help you understand that. The stakeholders have influence. They have influence on the funding. It's not just the people in the top left-hand corner of the previous slide that control the money. All of the stakeholders have influence on the funding. And that's all the stakeholders talk to each other, and so they influence each other. And it can be scary pretty quickly because all of the stakeholders, of course, have contacts internally and externally. They know stuff. They know stuff about the software that you might be using. And one of the things that we run into fairly frequently is somebody will say, oh yeah, I used Rochette in such and such a place. And that influence one another. So your stakeholders will influence each other, and they will influence your enterprise as a whole, your business. You're not further and further into the business. Perhaps the individuals may be touched by metadata, may individually. That's a great deal of influence. But curiously, it can be enormous. And the overall impact on the business and the business's perception of what you're up to is extremely important. And therefore, you need to be managing the positions that stakeholders have on your program and on what you're doing. It's a key source for your requirements. And this is a subtle one in its way, too, because it's ongoing. Not only can they tell you what you want you to do, but they can tell you when they want you to do it. And over time, you'll kind of adjust those expectations and desires. And the more time you spend managing your stakeholders, interacting with them, communicating with them, the more likely you are to be 6-4. A message to deal with. Because there's a lot of people. You know, it's a lot easier in some ways to tell a small group of people, sit on a side to do a metadata management project, deliver it, and then proudly sit back and expect the world to consume it. Fortunately, as probably everybody on this call knows, that's not how it works. You have to explicitly manage it. In a way, your stakeholders have impact. They impact on your sources. They can actually either explicitly or explicitly determine whether to have what you need to get the job done or whether you don't. They have impact on your schedule. They have impact on your schedule both because they can tell you when you need things and because they have to participate in what you're doing. And they can decide to be available or not be available. Again, a lot of us, I think, that have been involved in significant projects of one sort or other know how frustrating it can be when there are maybe a dozen key people that you need to get together for a meeting or an agreement or a discussion. And it's simply impossible to get them all lined up. Now, their impact on your schedule can be drastic. And what I add up to as a bottom line is they impact your survival. Your stakeholders are really what you live and die by. Their role follows that failing to make a very explicit understanding of who your stakeholders are isn't death matter. I'm going to talk about this more in the following presentation, but I would strongly recommend that you think about your stakeholders as a portfolio. And also kind of map them out as this classic kind of matrix kind of mapping. You map them out according to their influence and resources and their impact and determine who the high-impact, high-resource people are and make sure that you look after those folks very carefully. So much for managing stakeholders. Shamelessly stolen cartoon number two. What do your stakeholders think of today? Explanation from Geekhook, whoever Geek and Poke are. That's how people somewhat think about metadata. And actually, I'm going to wander a little bit off the wide path and on to the how-to for a minute. One of the things that we have found increasing affective for people we work with is to avoid the M word. Don't talk much about metadata. And ideally, give your metadata management program a personality. You know, what we work with, actually called their metadata management program, the echo brain. And they actually created a little category, the little brains that they gave to people. It gave a program a personality, and that actually was part of their success. So that's something to think about. People don't much care to think about metadata. Sending your stakeholders, that's something to take account of. Next topic, seeing a project. Why does it matter how big the elephant is? That's a really good question. And I'll tell you, just to how do elephant metadata management is an elephant. All kind of thought experiment that you can do. The elephant of the number of different tidal causes of information asset have in your enterprise. And then how far you can get, I don't know, with a sheet of paper, let's say, just escalating about how many of each class you've got. Numbers get big pretty quickly. So you will approve that you fit into the same class as most of the other enterprises that you've met at data management. And secondly, you will likely have scared yourself a little bit. The next thing, scope and resources and time and meet are effectively, flexibly related. Scope, how much it's going to cost, what resources you're going to need, and how long it's going to take. And on the other hand, the resources you've got, the time you've got and the money you've got are limiting factors on scope. The whole thing about cutting your coat according to your cloth. So actually defining the scope is a very important activity. And the scope really comes in four sort of areas that you're going to be thinking about. One is the youth community. How many different groups are you trying to support? And one is that has happened, which is really interesting in the metadata world over the past 50 years. 50 years ago, the number of people who were using the results of metadata management programs explicitly was small. In this, maybe up to 100, if it was a fairly advanced organization and the data analysts and the modelers and things like that were explicitly using metadata. It has exploded to the point where in some organizations that we're dealing with, it is in the thousands or even tens of thousands. Do people necessarily know they're using things, some called metadata or things called metadata management facilities? No. Not necessarily. They know that they're using the infobrain or where it is to get information about the site they're looking at. They're looking at a report or a data store or something like that. They need to know more about it. They're asking a question. They're getting a response in a management. That's happening into the thousands now. You're dealing with 10 or 100 people that scope for something. You've been easily wrapped your arms around. Now, not so. So I'm not going to scope in that area. It's very important. That's the metadata sources. I talked about that a couple of minutes ago. If the papers are writing down the number of sources you've got and the connections between them, you'll really realize that this is very challenging and somehow we're going to wrap our arms around this. Otherwise, we'll never have a project that is delivering value. Certification capability. What can we do about that? What can we do with metadata once we've got it? We can do an awful lot of stuff with it. We can do it with support glossaries. Make sure people are using the same business language. We can use it to support reference data. Make sure people are using the same data for the same things because the categorization is accurate. We can use data management to support work processes and business access flow and as it goes. So we're going to have to think about, okay, what information capabilities are we intending on supporting and why? There's integration opportunities. Integration opportunities inside the enterprise and across enterprise borders. And it's the blob in the middle which is why this is so important. It's about expectation management. So if somebody, you're going to do a metadata management project and the discussion might go something like this. So how do we do a metadata management program? Wow. So what's metadata management stuff? Well, it's kind of like, you've got all this information and it's difficult to use because it's hard to find and when you've found it, it's hard to understand and when you understand it, it's hard to know what it's connected to. Well, we're going to fix all that. And suddenly you've created an expectation that one piece is going to break out. You created a massive expectation. Designing scope is extraordinarily important because it measures expectations and managing expectations, of course, and it ties back to managing your stakeholders. And one piece we often encourage people to do, in fact, is to identify key stakeholders and know that all of the key stakeholders are getting something in an extremely short period of time with a metadata management project. You know, a historic tendency to structure metadata management programs technically and it's really the kind of thing putting the cart before the horse. You really have to think about your stakeholders and their business drivers and figure out how to satisfy those. So we'll talk about some of that stuff. See, I was going to say, when we get to Texas and from where I thought, is that the right state? Yes, that's the right state. When we get to Texas, we'll talk about all that stuff. Next, I want to talk about how this is the strangest idea of all if you're on the technical side of the metadata management. How you're on the business side, this probably makes perfect sense, but on the technical side, the idea of marketing your program might not seem to make any sense. But really, here's how it goes. First of all, you program that you want people in your enterprise to invest in. You want sponsorship funding and involvement. Think about pretty much any activity that has a significant amount of sponsorship funding and involvement. They have a management aspect, right? They have marketing. There is an advertising, if you like, of what we're going to do for you. These are the benefits. This is how we will improve your bottom line. This is how we will eliminate your risk. There is a whole marketing process which leads you to the point where people will say, I believe in what you're trying to do. And by the way, there's a matter of believe, tell you later on and get your results matched your advertising. And so I see that in all too few places. I see the benefits of going back, let's say, after 12 months and saying, remember what role do we were going to do for you? Well, we did. And what we did matches what we said we were going to do. So this is what we're going to do, which can be some more for the next 12 months. That marketing is an iterative and ongoing process of communicating back to your stakeholders, getting what they're staying in. And that investment, of course, can be tiny or resources. There's adoption. Adoption is getting more people to use your solution. I have my vendor hat on for a minute, if I may. It's not really getting more people to adopt my solution. It's getting more people to adopt your solution because this is a program that you have ownership of. And the people that are using the results of your program and benefiting from it, that it's going to be for you. So that is about gaining users and value and direction. I will talk about how to do that. Gaining users, you know, is almost self-evident. So let me ask you this question, things to think about. How many people are there who work with organizations that depend on the profitability of the proper information at the right time to get their jobs? I have a question 20 or 30 years ago. The proportion might have been fairly high. There were a number of people who, frankly, were very self-directed and were just doing things that they were supposed to do again and day out. There were a lot of people there in typical businesses, the types of businesses we worked for. They don't depend on information to get their job done, very small. So gaining users for your metadata management solution has a major impact on the success of your business, hence the value that you're achieving. But the part of marketing is the in-down part of marketing. It's not about outward communication. It's all about collecting information from people that you are marketing to. And that enables you to get your direction right. It's a constant marketing communication with your stakeholders and their user community. They are giving you constant direction about whether you're doing well or badly, what you should be improving, what is already great, and what you should be doing next. They give you direction. That is a huge value. The third part is actually the extension part. Data management is not a product or a project. I've said it a couple of times, I think. It's a program. It is something that goes on. And the way we like to look at this is, Lee, you want to release your program into manageable pieces. And think about the appetite for value of your organization. Now, there are some organizations that if they don't see in three months' board and move on to the next thing, there are some that are perhaps to wait 20 months. I never suggest that you have a phase of your program or a sub-project that goes along as 18 months. In fact, I always suggest that you delay them at three to six months' bytes. But think about that. Each time you want to get started on the next byte, you need support for the next thing. And definitely you're thinking about the next big thing for the business. In a straightforward kind of way of looking at metadata management, it's about doing information technology better. It's about making the business use of information better. If you can focus on the business use of information, you're going to have a hugely more significant impact than if you focus on the efficiency of IT. So ideally, the third part of marketing is understanding and getting support for the next big thing for the business. Now let's talk about managing for sustainability. So kind as to mention my data blog at the beginning of this session. I have one of the things that started me blogging for data diversity was the thought that I'd like to spend time writing about why sometimes metadata management projects just fall apart or programs fall apart. And I just cycle in a few places. And frankly, it doesn't matter very much what kind of technology people are using. It's all to do with this kind of cycle. An organization can determine that information assets are out of control. Triggering events that occurs usually. Triggering events can be, you know, something like a compliance failure. Yeah, we've accidentally exposed first identifiable information. There's a storm in the media and people get fed and there's big embarrassments. Or it's as simple as there's another new CEO. You know, I was talking to their organization last year and they said, how did a new CEO come in? And he asked for what he thought was a pretty simple piece of information. He said, yeah, so tell me, how long did people occupy their bed in one of our facilities? And he got six different answers. Well, at that point his response was along the lines of and I think I've entered this for a mixed audience. Really, that's not very good, is it? I think we need to have one. Go ahead and fix this for me, please. It's an event for a made-a-managed project. So some kind of triggering event occurs. A management decides to invest in metadata. And it's interesting. Management decides to invest in metadata and they usually point somebody to be in charge. And it's not so simple. But most of the people who get put in charge are at least reasonable communicators. There's a certain amount of ability to market their ideas and provide a solution. So I tend to think of these people as the metadata evangelist. Yeah, the metadata evangelist. Build it in two ways. First of all, don't be that person. Do the one person on the metadata management is perceived to have. If you're a manager and you're in charge of this operation, you're actually setting up a metadata management program, why not to let somebody become a metadata evangelist? Because if you metadata evangelist, all kinds of bad things can happen. Then I've seen it all too often. One team metadata evangelist. And you know what? Because that person is such an enthusiast, the initial project is successful. And operation declares success. So shall the pain or appropriately fizzy water are popped and everybody rejoices and daps. Second of all, enthusiasm wanes for a whole variety of reasons. And I could spend a long time on what a variety of reasons are. But let's just take it that enthusiasm wanes and the evangelist get lots of metadata management program decays and things kind of go bad for a while and information is out of control. Now this is not unique to metadata. It's a challenge to every project. It depends on technology that's kind of hard to implement. So it's the same thing with data warehouse management projects with ERP projects. And if there's people on this webinar, I would think quite a lot of you have seen this kind in one project or another. We're going to spend some time in Austin talking about how do you avoid this cycle? How do you manage for large-term sustainability? The thing we're going to talk about is working with vendors. The first thing I really want to say is it's not us against them or me against you. Let's be clear about that. I have no investment in you failing and you have no investment in you failing. We have different goals. You are focused on your needs and your needs only and ultimately our vendor has to be aware that I've got quite a few customers to look after. I also have to look to the future and not just do where I am right now. So that's kind of my perspective as a vendor and in the metadata management ecosystem you've got a lot of different vendors. You're a vendor of the metadata technology assuming that you didn't write your own. If you write your own, we have a whole different conversation to have. The relation for your courage is unbounded but it's a whole different conversation to have. Let's assume you have a metadata technology vendor and then you probably have all kinds of technologies from which you are acquiring metadata. Might be applications, might be data wetting and decision support technologies, modeling technologies. Things like your e-modeling technology or business process modeling technology. Could be big data technologies. There's plenty of others around. Add them all together. These are a lot of things that are all changing according to different cycles and so you have to coordinate those cycles recognizing that the big wheel ought to be your business needs and the needs of your business are changing constantly. One of the telecom organizations implemented a metadata management program because they simply could not change their plans fast enough because the application that managed their plans was just too complex. A metadata management probe to deal with that. The issue of working with vendors is recognizing that everything is changing very rapidly. You have to coordinate the changes because if you do that it is extremely difficult ever to have, as it were, a fully working cohesive environment. Some of those are the things I mostly intend to be talking about in Austin. I dare say we'll talk about other stuff too. My thoughts about how we do those things and drawing on the experience of our colleagues who have done a lot of projects and putting in some hopefully practical wisdom about making all of this stuff work. I've spoken for my contractual 40 to 45 minutes. I'd really like to open this to take questions. Thank you so much. This has been a great presentation. Of course, you always deliver to us such talks. As a tribute, there's a lot of questions coming in. Of course, the most popular question we always get is if people are going to receive copies of the slides and the recording. I will be sending out a follow-up email to everybody by end of Thursday with those links to those slides and the recording so everyone will get a copy of all of this information that Ian has presented. So, Ian, with the first question here, just kind of a foundation question. What's the difference between metadata and master data? Oh, cool question. All right. Let me see if I can explain this. Think of a business transaction. I sold 5,000 grain widgets to Polyopinopolis in Pasipani, which happens to be as far as I'm concerned in my Northwest region. Ian, with the second question, I have a number of things that I have. One thing that I think is pure numeric quantitative data, 5,000 quantitative numeric data. Then I have other things that I think of as root data. In Pasipani, in my operation, it happens to be in the Northwest. I've got a table of regions that is classification information which doesn't change very often. And it's essentially tabular. I'm going to call it reference data and it's said by lots of different applications. Then there are things that I think of as master data. And my master data are things which enable me to uniquely identify important entities for my business. In this case, I had Polyopinopolis, who is a customer. And Poly has a name and an address. And hopefully I've only got one name and address for Poly that uniquely identifies this particular customer and that master data. I also have information about widgets and which products are products and there is product master data. And hopefully in my transaction record, the thing that says green widgets is a piece of master data that usually identifies that unique product. All those things are really data. So I have transaction data, I have reference data, I have master data. Now, there is stuff that describes all of the elements. So the stuff that says a person's name has two parts. First name, second name. First name can be four characters long. Second name can be 200 characters long. It's alphanaric. And the stuff that describes the name field is master data about the name field. So master data is descriptive information about information assets. Master data is information that is used to uniquely identify instances of entities which are important to the business. Reference data is essentially school moving, categorizing information and numerical data is numerical data used to add things up. Great question. Great answer. So we hit the topic of big data, has metadata? Yes, I know. I was being mean. A lot of the stuff that we're used to working with has long data and that cataloged data is very easily identified and you've got record layouts and you've got models and also those things are predetermined the type of information you're working with. So big data, it's a little different because actually a lot of the metadata that applies to big data is really almost post-operatively applied. I collect information from a lot of different places into what some people call a data lake and then it can be either the way you write the code to do the collection to put things into my big data environment or it can be information in the analytics that I use that actually kind of post-operatively applies metadata. So it's kind of different, but yes, to say there was no metadata was actually a bit of a tease and I probably shouldn't have done that. That's always good. Make sure you have everyone's bagging attention. Next question is, why do you think a tool is needed for metadata management? As I always say, a tool with a tool is still a tool. What is lacking is process, not a tool. One should look for tools to fix a process. Can you comment on that? Sure, I disagree. Yes, a tool with a tool is still a tool. That's actually true. You should know a smart person without the appropriate tool still is going to get the job done. We can kind of trade little aphorisms, but bottom line, there's information which determines information assets and it is useful to be able to manage that information because it enables certain interesting activities. For instance, it enables impact analysis. It enables you to understand the impact of change. It enables the lineage. It enables you to understand where information came from. It enables you to understand the provenance of information. It enables you to understand the structure of information. If you don't have those things, then the other good process in the world isn't really going to help you. You don't need a tool. Now, does everybody need a great enterprise metadata repository? No, but be not. In other organizations, small groups that can do a very nice job without a massive tool, without an industrial strength technology. But listen, if you're on the hook for responsibility for the governance of let's say financial or health care information or information in the energy industry, if you do want something rigorous, a rigorous process is good. A rigorous process probably depends on a rigorous tooling as well. Next question is, again, about a tool, but more in terms of purchase. Should you develop an MDM strategy and framework that works for the business and then purchase an MDM solution that fits that strategy, or is it the other way around? No, the answer is yes. You should determine your strategy first and acquire your technology second. I'm not sure whether the person who asked that question was asking about MDM master data management or MDM meta management, but actually the answer is the same in both cases. I kind of think about our realities here. In certain circumstances, would you buy a tool for your home improvement project, without deciding what the project was first and what you were trying to achieve? Is it important to understand your strategy first, understand your requirements, and go looking for my technology which will be the right thing to do it with? Fantastic. A little plug here for ASG. Somebody is asking about the most popular metadata products available and if you have any recommendations. Of course, being the VP marketing of metadata projects at ASG, maybe you can give us a little quick blend on the solution. Yes, so ASG's metadata management technology. We have a story that we focus on. We have ASG or Shade, which is an enterprise metadata repository technology. Now, the implications of enterprise metadata repository is dealing with a broad range of potentially complex information sources and allows them to be tied together to give a broader understanding of the enterprise information environment. ASG for cubic, detailed application metadata repository, formal level of granularity and understanding of applications, and federate the one to the other to provide probably the deepest depth into the lineage that anybody can pull off at the moment. About 200 out of the box, distinct metadata sources, the data glossary, or enterprise glossary laid on top of that, rep-data management, and all being well, we'll be showing off our data metadata extension for that, which will be very cool. It will be healthy stuff. Very cool. And, you know, I'm not going to plug the other guys. Sorry. I'm not going to piggy you away, but that's great. And, you know, we had a question actually in here for out to all the attendees, as well as you, and just how about the panelists and attendees share their favorite effective euphemisms and synonyms for metadata that were effective in communications with non-IT people. And if you want to type those up in the chat there, I feel I'd be happy to publish that and send that out to everybody. I think that's a great conversation. And, Ian, what's your take on that? What's the meaning of that? Great. Euphemisms and synonyms. Synonyms. Stuff. Stuff. That's the stuff information. It's the, you know, actually it's the stuff that makes your information useful. That works with a lot of people. You'd be surprised. I am going to throw out one observation on that question, though. One is, as you said, metadata is data about data. You must go and stay in a corner and bang your head against the wall for the next 30 minutes. That's it. That's perfect. Thank you for this question. Can you implement a metadata program if you don't have funding? What's your opinion on that? You can, but you won't go very, very far, and the coin of scope becomes absolutely critical. If you don't have funding, not for a problem which is a case of being addressed fairly simply, but will solve a problem which is dear to the heart of somebody with money. And yes, you can do that. After when it comes down to it, I just define metadata as the stuff that makes your information useful. Is it possible to collect some metadata and articulate a use case for a limited amount of metadata that might be valuable? Yes, you probably can. Can you do a full-scale metadata management program without funding? No, not really, because there's always a trade-off between funding, funding, and manpower. And to give you an example, we're just finishing off a project with Data Diversity with a wonderful white paper in it which I hope you'll all be hearing about shortly, where a major financial institution was trying to understand some data flow for critical data elements. It was taking months and months and not working doing it manually, which is kind of doing metadata funding. And we were able to pull it off very quickly once they'd acquired the appropriate building. So, yes, you can do something with your full-scale data. I'm afraid we are... We have a lot of great questions left, but I'm afraid we are out of time. Maybe I can send these over to TAE and see if you have any answers for them to follow up with in the follow-up email. I promise I'll send them up, but, you know, this is a great way of sucking people into my EDW presentation. I'll be sure that they will get covered there if they don't get covered before. That sounds perfect. I love it. All right, and thank you to everyone and thanks to all of our attendees, especially those who hung in there for who are having sound issues at the beginning of the presentation, and all these great questions. We just love how interactive everyone is and, Ian, thank you for this great presentation that just has heard a lot of conversation. It's always a great sign. And just in time, we will be hosting the recording of the webinar and the slides to dativersity.net within two business days, and I will also send a follow-up email to let you know the links and other requested information by end of day Thursday. So, if you don't have it in your inbox by Friday morning, just let me know and I'll make sure to get you the information. And don't forget to register for Enterprise Day in the World by this Friday to take advantage of the early bird prices and save $200 and to hear and meet Ian live. And, Ian, thank you so much and everybody. I hope you guys all have a great day. Thanks. It's been a pleasure as always. I hope you all have a great rest of your day and we'll see you in Texas. Bye-bye. Stay in. Bye.