 As I said, my name is Sandra Suleiman. I work for Fannie Mae, and I lead the Enterprise Metadata Management and the Enterprise Logical Data Modeling Team. So just to make sure you are in the right session, and I want to make sure these kind of set expectations, the goal of this today is not to have a technical discussion about metadata. There are great sessions. I attended a couple yesterday. So there are a lot of great sessions on technical metadata. And I think for the most part, people are much more comfortable with, at least in our space, right, in the technology space with the technical metadata. And I'm also not going to talk about sort of have a 101 on metadata in general, right? So the intent is to talk about Enterprise Metadata Management, which to most of us, at least when I started, was sort of an abstract and kind of esoteric topic. So I will focus on three major themes. One is, what is the business case, right? Because a lot of times, I have a technology background. And a lot of times, I think folks go in and get all excited about the technology sort of value proposition of metadata. And then you get in front of your SVP or your CIO. And they're just, they look bored with the topic, right? And you really don't get any traction. So that's sort of, what's the business case? The other thing that I think is just as important is when you talk about implementation, right, where should you start? Again, I think most people want to start just simply because of our backgrounds, right? They want to start with the technology aspect of metadata. Just very easy for us to understand, right? But when you get in front of your CFO who actually controls the money, right? And you talk about how great it would be to kind of link your term to your logical metadata and then from there to the physical and reporting layer there, they kind of, their heads start spinning, right? And even if you're lucky enough to get your program, you stand up your program, you can't sustain it, right? So implementation and in terms of where you start is very important. And then the last piece is really around how do you make sure you have metrics and you can measure the program, right? So when I started the program, I met with one of our SVPs and he said, Samra, just remember, this is great, you know, everything you're talking about great, you know, I got it. But if you can measure it, it didn't happen. So I don't want to hear you at the end of the year that, you know what, this is really hard to measure. And I have to tell you, that really scared me. And it's really hard to measure. So I'll talk about that a little bit. And then we can have a discussion about it because I'm sure a lot of you are running into the same thing. So as I said, I work with Fannie Mae. I think most people are familiar with Fannie Mae. So if you Google, you'll probably get more information Fannie Mae than I can provide. So I talked about myself a little bit. My background is from technology, mostly in technology. I've done a lot of work in the enterprise architecture space. I've managed development. I consider myself pretty technical. However, in this role for the metadata and modeling, sort of I have the enterprise hat and sort of the liaison between technology and business. All right, so metadata and you, right? This is a slide that's not, I think everybody in this room knows what metadata is, right? And then the topic is not introduction to metadata. But this, I put together this slide because of the challenges that I was having when talking to our business people. I think a lot of people were told in our space people were trying to simplify metadata, right? So it became so simple that the business was thinking about metadata, business glossary, OK, terms definition. And that initially was good because it kind of started the dialogue. But after a while, that became a real problem for us, right? Because we still needed funding to get to the next level of metadata. And all they could think about was, oh, well, you told me. Metadata is dictionary. Metadata is business glossary. I have terms, definitions. I'm done, right? And we were sitting there like, oh, yeah, this is just not just the beginning, just the start, right? So I put together this slide in the way and also my friends and family, right? What do you do for a living? Oh, I lead a metadata program. What is that? And most people, when I started talking about it, they were like, yeah, yeah, yeah, OK, I don't deal with it. It doesn't impact me. I really don't care, right? So after a while, I said, no, actually, you are impacted by it, right? You do care because you deal with it every day. You have a Facebook account, yes. And more and more people are on Twitter or Groupon or whatever, right? You pick your social media media. So I said, yeah, but remember the other day you were telling me about this customized, personalized content that you got, right? You got an invitation to something that you cared about or something that was customized to you, right? So that happened because of metadata, right? So even at work, I started talking about metadata in that sense because without connecting the dots for people, the dots for people, I think they repeat what you say, right? Like I said, with business glossary, it became like everybody was repeating, oh, we need to have a business definition, terms and definition. And then any time you started talking about the next steps, it was completely lost on them, right? So the idea is, find a way. This worked for me, for you, maybe something else, right? And find something that people can actually grasp, right? And then after that, every time you give them a little more information, they can build on that, right? In the absence of that, they're just repeating what you're saying. And really, it doesn't help you cause a place that didn't help my cause or our cause. So enough about that, right? Metadata is around us, and people need to know that. It's way through processing, your social media, personalized content, right? It's about search, discovery. It's about sharing information, right? Across the enterprise, if you're sort of in the work environment, right? And across your friends and family, whatever the case might be, right? Semantic web, right? It's all about metadata. All right, so the agenda, I think I touched on that a little bit, right? I'll provide a high level overview of what enterprise metadata management is. Then I'll talk about the business case. And within that, I have about three use cases. And you know what? This has worked in progress for us, right? Also, I don't have all the answers. All I'm doing is kind of sharing our experience, right? What helped us? What were some of the challenges that we had? And there were many. And then, you know, we can have a discussion. Hopefully, I asked Greg to keep me in check because I don't want to talk too much. So we'll see. And then the implementation. I think there are a couple of things in the implementation that I will touch on. One is, so once you stand up your program, right? You really need to think hard about a strategy for populating the content, right? Because what you don't want to do, as I said, I think loading your technical metadata is the fastest, the quickest, is what we can wrap our minds around, right? But that does not give business a quick ROI, right? I think the hardest thing with metadata, from my perspective, is the justification for ROI, right? And I'll talk about that a little bit. And then the maturity model in metrics, right? My SVP put the fear of God in me, right? What do you mean? Don't come back to me in a year and say, you know, you couldn't measure it, right? If it didn't, if you can't measure it, if you can't show me progress, if you can't provide metrics, it didn't happen. And then some key takeaways, sort of my humble two cents about what may help you. All right, so an overview. So enterprise metadata management. What is it? What are the benefits and why most programs fail? This is based on some of the conversations that I've had with other groups and other people who are leading metadata management at the enterprise level, and also some of our own experiences. All right, so what is metadata, right? What is metadata management? I'm sorry. What is enterprise metadata management, right? So I really like this Gardner sort of description. It's very simple, right? It's about, so you can read it, the primary concern of metadata management is ensuring that data is usable across the enterprise. So OK, what does that mean, right? For me, simply it means the information, the context, or meaning that metadata provides context and meaning to your data, right? So we're on mortgage business, right? We do mortgages, right? So there's this most popular data element that we have is unpaid principal balance, right? So most people here probably have mortgages, right? So we have your principal, you have your interest, right? And then every month you make your payments, and then there's that little balance that carries over, right? If you have the loan for 30 years, you have it for 30 years, or whatever, right? That's a little bit. Yeah, yeah, that's right, that's right. So that's sort of what we call a critical data element in our environment, right? So without, and depending on where you stand, where you are and how you're using that UPB, right? If you bring in a loan, we're a mortgage company, right? If you're bringing a loan, right? That piece of data has a different state, right? You acquire a loan, right? So the people who are processing that information, right? That piece of UPB during their acquisition, they have a very different view of that data versus when you go to foreclosure, right? You miss three payments, the bank is calling. The people who are dealing with that, they have a very different understanding of what UPB is and how it should be dealt with versus people who are just getting a loan, right? So sort of different states of an entity, right? So the idea is, without the metadata, right? You can't uniquely identify that information, right? And then you have all these business units across the organization, right? And everybody, if you don't have metadata at the enterprise level, everybody has a slightly different understanding, like I said, right? The people who are dealing with that acquisition, they think of it differently, they describe it differently. We have gone over and over the definitions with them, right? From people who are sitting at the, you know, lost mitigation or sort of at the end of the loan, right? So without having a common vocabulary, sort of a common semantic, it's almost impossible to communicate that, right? So I have a use case, I'll talk about that, right? So what is data? So what are the benefits of enterprise metadata management, right? What kind of data is available at the, what we call shared data, right? So what are the pieces of data that are available across the enterprise, right? You don't wanna put everything in your enterprise repositories in general, right? So in Fannie Mae, we have a couple of different concepts around that. So I'll talk about that later. One is sort of the business of critical data, data that goes across the entire information supply chain, right? From the beginning all the way to the end, right? And if you wanna do straight to processing, right? If you wanna do lights out or whatever, right? You have to have that information available and everybody speak the same language, right? You may have a little accents here and there like me, but you all have to have the same vocabulary, right? Otherwise it's just, it's not gonna work. And how the data is linked, right? So that has a modeling aspect, right? You have your business constructs, right? And how, you know, and your relationship, so. And then how data is classified, right? As data on non-public information, right? You need to know that that information needs to be available at the enterprise level, right? Your enterprise risk folks will tell you, you know? They'll come after you, right? If you have a slightly different understanding of what the NPI is, right? And you kind of do your own thing and they say, what do you mean? So everybody needs to have the same understanding. A metadata repository, it's a great place for that, right? Who governs the data? I'll touch on that a little bit, right? There are a few concepts that you really need to, you cannot have enterprise metadata management at the, can't have metadata management at the enterprise level without the sort of the governance side, right? So I'll touch on that. And then the root cause analysis and impact analysis, right? So root cause analysis and sort of the geek talk, right? We call it data lineage, right? And then, but you go in front of your CFO, you talk about lineage, their head will spin. And, you know, or impact analysis or what if scenarios for us, right? It's sort of taking a piece of information, going through all the layers of architecture, right? And kind of trace that, right? See what the impact of a change, potential changes across all the layers of the infrastructure or architecture. So effective enterprise metadata management is truly enable and is an enabler for increased business productivity, right? But you need to get there, right? Because initially it is so kind of hard and abstract. Once you get there, I think people will see it and the ROI will be there, but how do you get there? Why most programs fail? So the first bullet is something that I really believe in, right? When you go, so you may be able to talk about metadata, right? Sort of the technical metadata to your technology leadership to a point, right? To a point. Even the CIO, right? He may get all the concepts, right? But he has restrictions because he's getting his money from the higher people, right? The financial people, right? So if he cannot go in and say, you know what? And at that level, they're not talking about how do you do data lineage, right? So at that level, they're talking about, okay, so this is what I get. These are my expenses and my costs, right? Does it affect my bottom line, right? And unfortunately, it's very difficult to tie metadata to directly to your bottom line, right? To your financial statement. And I think it would have been a little easier if you could get people to openly talk about how much time they're spending on their individual spreadsheets and access databases and all these different sort of ways that they're pulling information together, pulling metadata together, right? But you can't. I can speak from experience. I cannot get a single person to tell me, I know there are five people in our acquisition space that are working on metadata all day long, right? Either it's technical metadata, but I cannot get anybody to admit and give me dollar value, right? So because of that, I don't have a baseline, right? So how, you know, so that's why it's so difficult. And you really have to have sort of a C-level sponsorship, right, either your CIO, your CFO. And so we are very fortunate in that, unfortunately after 2008, right? The sort of the financial meltdown, right? There was a lot of incentive for financial industry in general, right? To sort of provide some transparency in the data movement, provide transparency in the sort of identifying the financial instruments, right? That have a long life cycle, right? And they go through different entities, right? So I'll talk a little bit about that. So the impetus was there, right? So we have from our regulator down to our CIOs, to CEO support for entire enterprise data management program and we have an initiative and metadata is part of that. So in that sense, we're very lucky. That said, as I told you, right, my SVP said, if you can measure it, it didn't happen, right? So you still have to go back and justify. So I think that's, I want to highlight the fact that despite our regulators and despite our CEO support, right? We still have to go back and constantly justify and be able to sustain the program, right? Because I think the one thing that happens quite a bit, people can justify sort of standing up the program putting a metadata repository, right? And then because you start with the technology and I don't want to kind of harp on that too much, right? I'm a technologist so I know why we do that because it's really, it's a huge productivity gain from that but it doesn't resonate with your business people, right? So we just have to think differently about that. And another thing, and this again, we are very fortunate that our metadata program is not considered a project, right? This space is too complex, right? Too many layers, too many different sort of, different disciplines within the metadata, right? You have technical metadata, operational metadata, business metadata, right? Then you have unstructured metadata, right? It's too complex to kind of say, okay, it's a project check, I'm done, right? And that's why I think one of the major reasons these programs fail. And then I talked about this before, right? Our inability to baseline and kind of show progress over time, right? So one of the things that I always tell my team is you gotta think big, right? You have to think big, you have to think, you have to know where you wanna go, right? You have to, if you have these big aspirations, okay, I wanna be able to do straight through processing in three years, right? Across all my business, take a transaction, all my business transactions will be straight through processing, lights out. That's a great goal to have, but you have to be very practical, right? You have to be able to kind of deliver value quickly, but also show how you, what you're delivering. It makes, it kind of puts you one step closer to the ultimate goal of whatever it is, straight through processing or whatever the case may be. So the one takeaway from this one is you have to make sure you deliver business value otherwise adoption will not happen. And we have had a couple of metadata programs in the past that sort of unfortunately didn't go very well. And it was because of that, right? We were either think, we were either very tactical and kind of thinking technology, or we sort of didn't have a good roadmap on how to build the program and then kind of show progress along the way. All right, so the business case. So I said the beginning, right? I'm gonna talk about three themes. The business case, the implementation, the maturity and model and how to metrics and kind of how to provide metrics around the program and show progress. All right, so I think if you think about, if you work with your business folks, right? I think there are a number of different business use cases that you can come up with. These are the three that I decided to put on here. So and I tried to have sort of three different audiences and mine when I put this slide together, right? So the first one is regulatory compliance and I will get into a little more detail in the next couple of slides. So those are your enterprise risk people, right? Or your operational risk people, right? Then straight through processing. This is one area that I have to tell you that resonates with our technology leadership, right? Our CIO or we have business information officers. They get that, right? Their whole life is spent on trying to figure out how to get the system to produce faster quality data, right? These are all the things that resonates with them, right? And then when I talk about metadata in terms of straight through processing, how am I doing with time? Okay, half it done. Ooh, okay, gotta speed it up. All right, so I'll talk about that. And then the third audience is the financial modelers, right? We have a lot of financial modelers, right? It's about the analytics, right? Business analytics and I won't get too much into that but obviously if you wanna do modeling, I'm sorry if you do analytics, metadata is key and I'll touch on that as well. So again, metadata is sort of provides the necessary meaning and context to your data and kind of we say it turns your data into information, right? Without that is just another piece of data. You don't have context. You don't know how it fits in in the larger picture. All right, regulatory compliance. So I'll just use a couple of examples and I think they probably resonates with most people. So one is the sort of business vocabulary, right? So after 2008, I think this became sort of a big deal in the financial industry, right? The ability to trace an asset, right? A financial asset in our case, right? Through the entire transaction life cycle, right? And be able to identify each instrument, each financial asset, right? Uniquely across the life cycle, across multiple entities, right? So where do you do that, right? So metadata has a huge part of that, right? Because all of that is metadata. So I think that has been a huge impetus around some of the efforts in the industry around semantic repository, which EDM Council, I remember, Enterprise Data Management Council, so they're sort of trying to kind of move that forward and a number of other organizations, right? Trying to move that forward. The second one is root cause analysis. Really it's about data lineage, right? And this is a true story. Before we started this program, my boss came to me and said, I need like two or three people to go and do a lineage because this one part of the business has a SOX finding. And the finding was that they had about 112 data elements that were appearing on the financial statements on the 10Q and 10K. And the auditors were very uncomfortable about what that was. So they wanted to trace that information back, see where the data came from, what were some of the transformations around the data, right? And why, you know, so how do we trace that, right? We did not have anywhere in the company this information readily available. And to further complicated, this was sort of at the end of, and I have a lineage picture, I'll talk about that more. But anyway, so this was going through about three or four different systems along the sort of the information chain, right? From the minute we got the information to the minute that appeared on the report that caught the regulators' attention. And we really, we were relying on internal SME network, subject matter experts, right? Network and our friends and you know, whoever. So that body of work, we traced 112 data elements. It took a month and in terms, and this is a true story. And they, my team had to touch 1,100 data elements. They had to analyze that, right? They had to go through transformation. They had to go through ETL code, right? And then they had to kind of figure out no documentation. So you call your friend and your friends calls you. The other friend and it's just a mess, right? Took a month, we got it done, right? It was, so that became our lineage spreadsheet. But then you have to maintain it over time, right? That resonates. So now every chance I get, I talk about this. And it resonates internally with our people, right? So I think everybody in this room can probably come up with two or three sort of major issues that you have, right? That you can say as a, hey, this is a use case. This is what you can do. This is how you fix this, right? We also have disclosures, same thing, right? If the disclosures go to investors and if that information is incorrect, that has happened a couple of times, hit the news, right? So I kind of, it goes immediately on my little list and I talk about it and talk about it. So it kind of gets annoying, but it crosses the point, it makes the point. All right, so this is, as I said earlier, this slide really resonates with our technology leadership. It's really about automating the data handoff points, right? You have all these interfaces, you get data into your system and then you spit it out for a report or whatever. You need to be able to have, you speak the same vocabulary, right? Excuse me, and you need to make sure you have the same data standards, data types, the precision, whatever the case may be, right? And then impact analysis is your ability to provide traceability by linking different layers of architecture and we've done some work with our vendor partner which has been really good. So I'll touch on that a little bit as well. Business analytics, I think there are so many great sessions. So in this conference about that, just the point here is again, you can do analytics without metadata, right? And more and more people are trying to do virtual marks, right? Your ability to kind of provide data very quickly to a dedicated set of business users, right? Virtual marks, you can't do that without metadata, right? So it's again, metadata, really write this about your ability to search, discover information, the faster, the better quality data and metadata you have, you're more successful. All right, how am I doing on time? 18 minutes, okay. All right, implementation. I think in terms of implementation, you really need to know the culture of your organization. You need to know how much support you have from your leadership, right? Your immediate leadership, right? Are they completely in sync with you, right? And also at the enterprise level, right? You're again, you see level, right? How much willingness there is to provide funding and to support the program, right? And be able to sustain it. So there are a lot of words on this slide, so I'm not gonna go over everything. The idea is, as I said, you really need to think big, right? Because so in our case, the mortgage industry is in the middle of a huge transformation, right? Not just because Fannie and Freddie and the GACs are impacted by that, but it's larger than that, right? It's about housing market. It's about how we do sort of deal with mortgages and housing in general in the future, right? So we're just part of that, but it's a much larger conversation, right? And so you need to think about how are you gonna look like in our case, right? In three years from now and five years from now, right? So we need to think very big, right? We need to think about, you wanna get out of these silo modes, right? You wanna be where all these transactions are done very fast, very quickly, right? So you can process volume, whatever the case might be, right? So you have to think big, but as I said, you can't think so big and you can't try to boil the ocean, right? And kind of go and say, okay, I'm gonna do all of this and it's gonna be perfect and I need the program to be perfect. You cannot, this will never be perfect and if you shoot for perfection, you're paralyzed, right? Because there's always somebody somewhere along the way who'll tell you, you're wrong and you know, so, and you know, technology, part of technology is there, part of it isn't there. So think big, but be able to execute incrementally, right, in a smaller, in a way that, as I said, right, have a roadmap, that every step on that roadmap that you deliver needs to map to your bigger vision, right? And so for us, that big vision is eventually, everything should be straight through processing, right? We wanna get out, we wanna be a data-driven organization, right? So everything we do is sort of kind of tracks along that spectrum. So in terms of implementation, there are four types of metadata that, you know, sort of the way we're thinking about it, right? Business metadata, that to us is the semantic vocabulary, right, your business vocabulary or semantics, your technical metadata, right? And then within that technical metadata, you have the design time metadata, right? Sort of your physical models, your schemas, your, you know, sort of those artifacts, right? And then runtime metadata. One of the things that we have stated for now for the program is we're not getting in the runtime metadata, right? So the way my simple brain, I talk about runtime metadata is in the dynamic information that you need to run a program, to run an application, for instance, your configuration file, right? Something that's sort of while an application is running, you need to go dynamically and pull some information, right? So what we said was, we think big, that's definitely part of our strategy, right? It's part of our vision, it's part of the strategy, but you know what? For 2012, don't even talk to me about runtime metadata because I'm trying to figure out how I do the rest of it, right? So I think being a little practical about it probably helps in kind of setting expectations ahead of time, right? Because I have the senior technology leadership who are telling us, you know what? Oh, this will be so cool if you can do that. And I'm like, yeah, yeah, yeah, but you know what? You told me I have to show progress and, you know? And until then, I can't do it in 2012. And surprisingly, they get that, you know? Cause that's how they think, right? It's, they don't want you to be all over the place. And if you can show that, you know what? Here's where I wanna go. This is where I am. And just help me, you know, get there and don't kind of refocus me every, you know, two months cause then I won't deliver anything. The one question that I get all the time, not anymore but at the beginning was, oh my God, we have five, you know, different metadata repositories. Now you're gonna stand up a sixth one or seventh one and eighth one. What is this? We don't need another metadata repository. Yes, you do, right? You do need an enterprise metadata repository that becomes your trusted source, right? Both for governance, for a number of reasons, but even, you know, you can't have a governance program without that and I'll talk about that a little bit. Hey man, he's our governance person. It's Greg Wright. All right, again, the takeaway here is think big but know how you wanna get there and have answers along the way and be a little assertive when they tell you, no, no, no, don't focus on this, right? Once they bought into your roadmap, you gotta stick with it, right? And you gotta remind them, hey, you gotta stick with it. All right, 12 minutes. All right, so the use cases, so I'll kind of go over that quickly. So what we did is, as I said, right, there are different types of metadata and I didn't even talk about operational metadata on structure in previous, right? Oops, told you I'm bad with this, right? So I didn't even talk about these two and what I have said to our leadership is, don't even talk to me about unstructured, about operational and runtime metadata, right, in 2012. We need to get the sort of a static view of metadata, sort of design time metadata, both from the technical and operational, technical and business, and then we will build on that and they get that, but you just have to remind them of that a few times. So within that little world that I've created now, right? So we said it's gonna be design time metadata, it's gonna have a business aspect and it's gonna have a technical aspect, right? So what does that mean, right? So there are three use cases here. One, your business glossary, so I'll kind of talk about that a little bit, right? Two, your ability to do impact analysis, and I'll talk about what that means, right? The ability to trace a piece of information through all the layers of architecture and be able to articulate, do what-f scenarios, right? And also articulate, okay, if there is a potential change at this level, right? How many databases, how many servers, how many whatever will get impacted? And then our beloved root cause analysis lineage, right? Everybody, I don't know about you guys, but I'm always told, oh, I want a data lineage and it's not easy to get data lineage, especially if you have a lot of legacy, right? That's another point that I think you have to have a really clear vision and know where you wanna go in terms of the amount of time you wanna spend on your legacy system versus the new, right? And that I think is something that's very different for each organization, right? If you're in a sort of transformational state, you may not wanna spend too much time on your legacy, right? If your business model is changing, whatever, but that I think is very individual and, you know, depends on your organization. So, three use cases, right? Your business vocabulary or glossary, your basically impact analysis, ability to trace the data and do what-f scenarios, and then root cause analysis, right? Ability to trace a piece of information from the point of entry into your organization, an archives and point of entry into Fannie Mae, all the way through all the, for instance, a disclosure report that goes to the investors, right? And if there's an issue, how do you trace it back, right? How do you walk it back and kind of understand what are some of the transformations with how many data derivations were done, right? And things like that. All right, so the goal is, right? The way I communicate it to our business folks is consistent, length and traceable data across the enterprise for your core information, right? For your core business information. So, I'll talk about that a little bit next. So, business glossary. So, business glossary, this is what initially when we started, people talked about this and it became something that business understood and resonated with them, but unfortunately it became, that was the only thing that they were focusing on, right? So that presented a little bit of an issue for us. At a high level, what we have done for business glossary, we've kind of divided our data landscape in a couple of different ways. One is the enterprise view of data and that's any piece of information that crosses the transaction, business transaction, sort of the information life cycle, right? It goes end to end and completes a business transaction, right? So, that is what we call sort of core data or critical data, that's critical data for our business, right? And we have a couple of other classification and categories. I wanna make sure Greg doesn't kind of get mad at me. And then after that, it's the, we bring in the individual business units view of the world, right? That view is still very real, right? So that's something, especially if you have legacy, you really have to sort of deal with that too, right? Because you can't tell everybody, okay, from now on, we're only speaking about these 200 terms and the rest is, we're not interested. You need to have some level of governance, right? Sort of a more of a federated model. What's included in the business glossary normally, right? Is the business terms, your definitions, your trustees, right? The accountability, who's accountable for the data? That's a governance concept, so I don't wanna get into it too much. Did I do a quick summation? Yes, yes. So we have data stewards, we have, we call them business data leads, we have business trustees. These are people who truly are on the business side and they own the data and we have business custodians who are sort of the operation folks. I'm kind of going through that a little fast because Greg is telling me I need to speed it up. All right, impact analysis. So impact analysis really is about how do you trace your data through different layers of architecture, right? It's sort of a kind of technical term and that's when, initially, when we were talking to our business people, we were getting so excited to say, hey, imagine if you can do that. And they just kind of looked and say, really? And so that was not good. So basically it's at the highest level is your business glossary of semantics, right? And you have to make a decision what that is, right? It could be your enterprise logical, right? Or you can decide that you're gonna have a different business vocabulary. So I'm not here to recommend one way or the other. I think these things are entirely dependent upon the culture of your organization, how you're thinking about data, what you know, how much influence you really have on how political your organizations are, right? But the idea here is you have a semantic layer and then you usually have a canonical, you know, sort of a model layer. We call our enterprise logical data model and then you may or may not have an application logical and then a physical and then your database and your business intelligence, right? So the idea here is, how can I trace this information, right? Link it and then trace it. And then if somebody comes, so our regulators, right, come to us and kind of tells us what to do sometimes, right? And so for instance, they come and say, you know what, we're gonna launch a new program and as part of this program, you need to have these five new terms and these are the allowable values and all that, right? So it's not just as easy as going into the, you know, our metadata repository and adding it, right? We need to know what applications need to leverage that, use it, right? And what's the impact, right? So you can kind of go through that if everything is linked properly, right? You can say, okay, 25 databases were impacted, three applications, you know what, give me three years and $2 million, now I'm kidding. All right, root cause analysis. Again, initially when we were talking about the root cause analysis, we had these pictures of models that, you know, an attribute was linking to another attribute and, you know, to a column or whatever and people's head were spinning. So the idea here is, right, there's this normal flow of information, right? Which comes from either a trusted source or a system of record, right? It goes through system one, goes to system two, goes to system three, right? And along the way, there are transformation of that data, right? You add to it, you kind of, you know, multiplied by 100 or by 100, whatever you do to the data, right? And then it ends up in a report, right? We have, obviously, we have investors, so we do a lot of disclosure, so, you know, it's very important that the data that you provide on a disclosure is correct, right? And if you have an issue, how do you walk it back, right? How do you know where the issue occurred? We also are outsourcing a lot of our technology pieces and so this SME network is no longer there, right? It's not like you can call your friend and say, hey, you know what? Tell me what's going on with this UPV, right? So something to consider, but I just kind of put this picture because all this modeling stuff, people were giving me weird looks, so this tends to work for them, so oops. So this is the normal flow of the data and then you kind of walk it back from system A to B and all these things are hops along the way, right? And kind of document it that way. Excuse me. Oh my God, I have three minutes. All right, so I'm not gonna go over this. Basically, the idea is your metadata management, enterprise metadata management should be part of your governance program, right? It should be, in our case, the way we're structured, we have enterprise data management as a sort of umbrella group. Within that, we have four disciplines. We have enterprise metadata, enterprise data quality, enterprise data governance and enterprise logical data modeling. So I always joke that my governance colleagues are my biggest customer because it's really about governance, right? It's how do you track your trustees to your point earlier, right? How you define your terms, definition, allowable values, how do you provide consistency and data standards across the enterprise? I was gonna get into this, but I'm running out of time because I wanna allow time for questions. So enterprise data quality and architecture are also good use cases. We're working with Mega right now. We're doing proof of concept with Mega, which is an enterprise architecture tool and sort of kind of trying to do impact analysis across the enterprise assets, right? And then kind of do part of it and adaptive, which is our metadata repository tool. So just a number of different use cases that you can come up with here. I'm gonna touch on this a little bit. So at the end of the day, you need to be able to baseline your program. As I said, it was incredibly difficult to baseline the program. So what we did was, I think I mentioned I work with the Enterprise Data Management Council a lot and they have come up with a maturity model for the enterprise data management in general. But you can use whatever is your way of measuring the program, right? The idea is you need to show progress over some spectrum, and you need to show where you are. So this is not where we are, but so that I just kind of exaggerated this because legal and communication told me I can't talk about our program. So let's say there are five levels, right? And then I put some expected behaviors for each level of maturity, right? So in complete, as you know, everybody's doing whatever they wanna do. It's ad hoc, spreadsheets all over the place, right? Even perform, right? People are very reactive. They know, they build a database and then they go, oh wow, we need to have some sort of a, Greg, you're killing me, okay? All right. Anyway, so to end of the spectrum, right? You need to, as I said, you need to think, but you need to know what your goal is, but you also need to show, and I actually have a dashboard that tells my management, right? You know, there are a number of areas that, in terms of, so I have something called awareness, metadata population, content population, increased capabilities, those are on my dashboard. So I kind of come back and say, all right, so we're here, we're here, and then this year we're going here, and next year we're gonna go here. All right, Greg, I finished it. So key takeaways, C-level sponsorship, all these things, but at the end of the day, keep it simple. You cannot overthink this, you cannot make it complex. I think technology people tend to kind of go in meetings and try to wow people, don't do that because they will backfire, right? If you deliver the program, that's the wow factor. Don't go and kind of dazzle them with all these graphics around how these models are coming together. They just, they don't care. All right, that's it, thank you. Thank you.