 Karen Lopez. Karen is a senior project manager and architect at InfoAdvisors. She specializes in the practical application of data management principles. Karen is a frequent speaker, blogger, and on-data issues. She is a Microsoft SQL Server MVP specializing in data modeling and database design. She's an advisor to the Dana International Board and a member of the advisory board of Zachman International. She wants you to love your data. In the name of Karen this month, there are three esteemed guest panelists, Dr. Annmarine Smith, an information management professional and consultant with bad experience across industries, Ann Marie holds a PhD in management information systems and has earned the designations of certified data management professional, CDMP, and certified business intelligence professional, CBIP, along with project management certification. Ann Marie serves on the board of directors of Dana International and is on the faculty of North Central University. Also joining us today, David Loshan, president of Knowledge Integrity Incorporated, a consulting company focusing on customized information management solutions including information quality and consulting training, business intelligence, metadata, and data standards management. David has written numerous books, the most recent being The Practitioner's Guide to the Data Quality Improvement. Last but certainly not least, Pete Stiglitch, a senior healthcare data architect at Proficient. He has over 25 years of IT experience having worked in enterprise data architecture, data management, data modeling, conceptual, logical, physical, dimensional, data development, EDW, data quality, BDM, master data management, metadata, data and database administration. Getting to know Pete holds a mastery level certified data management professional, CDMP as well, and certified business intelligence professional, CBIP as well. So please welcome Karen and our panelists, and with that I will turn it over to Karen to get us started. Welcome. Thank you, Shannon, that was wonderful. I also want to thank Dataversity for hosting these webinars, and if you haven't been to Dataversity.net, you should get over there as soon as the webinar is over because there's a whole series of blog posts, webinars, videos, articles, all kinds of great stuff. I know I just got back from Enterprise Data World in San Diego, and what an amazing event. I really enjoyed myself. You should also consider going next year to EDW and actually submitting a talk. I think that would be wonderful if you would do that. I also want to thank Shannon. She's the rock star editor at Dataversity, and she makes all this magic happen for these webinars. I'd also like to thank CA Technologies of Irwin Data Rolling Fame for sponsoring these webinars. Without them, we could not make this happen. And finally, all of you attend these. What's really important and different about our webinars is that we encourage all of you to interact with us, as well as each other in the chat. So the chat feature is probably in a sidebar over on the right of the WebEx, and that's a way to talk to everyone or to people privately if you'd like to, as well as the formal Q&A. And the formal Q&A is the best way to get your questions about what we're talking about or even really witty comments to our attention. We do try to read the chat. We do try to monitor Twitter, but if you really have a burning question, stick it out there in the Q&A, and you don't have to wait until you ask for questions. So get over there and get writing. Also, there will be a recording of this made available in case, I don't know, your boss calls you away and makes you solve a particularly tough normalization problem or something like that. So this month's topic is data modeling governance. And I don't mean data governance, per se, but how do we model, how do we manage and govern and protect and extend and promote our data modeling assets and all of the artifacts that go with that? We spend all this time in our enterprises and our organizations convincing the business that they need to do certain things to get their data to protect it, to keep their customers happy, to keep their CIOs out of jail and all of those great things. But I think at times, and I want to ask all of you, all of you panelists, including the attendees, if we're not maybe more like cobblers or shoemakers' children in how we manage our data, or are we saying practice what we preach, but we're better than that and we're not. We don't just manage the data in a really, our metadata and our models in a really informal way. So that's what our questions are going to be about. If you have a question or observation about data modeling governance, go ahead and get those into the Q&A. So I'm going to have an open question from our three panelists of do you think that data models, metadata, other system artifacts, gosh, I think Shannon's tongue-twitting is correct. Do you think our data modeling and data management artifacts require the same level of data governance stewardship, enforcement, compliance measurement as what I'll call the real data? I think I'll start with David. What's your thoughts on that? Well, you know, I guess I could use an analogy, which is if we're building a building, I would expect that all the tools that I use would conform to some level of data so that I would not expect that after the building goes up that the girders suddenly start buckling because we didn't institute some level of standards. Now that said, you know, I think it's interesting because your question is should we or have we? I think that because we are still in a maturing phase of our industry where we're continuing to get some level of, you know, some navel gazing leading to self-awareness, I think that we haven't because we haven't focused on the need for that level of governance and now that we see that we've gone for 40 years without having as much as we needed, it seems to be a little bit of a dilemma. Yeah, it's funny. You started out with tools and I thought, what a fabulous analogy because I thought you were going to go the way, not just of the girders and the components of a building, but also the hammers, the fences, the impactors, the cranes, you know, things that don't become part of the thing we're building, but the things that help us do the design building of it. Like one of the things that I know about engineering governance is while engineers use CAD-CAM systems and design systems and lots of computing software to do their designs and their tests, they're still professionally accountable for all the work that those tools do. Like it's not a practical defense for a licensed engineer to say, why did all my work right? It was an error in the software that caused the beam to be under-specified. Yeah, when you asked the question, the image that I had in my mind was a hammer that was shattering when you actually struck a net and that would be intolerable in context. We were discussing how we seem to have some summary of laissez-faire when it comes to the same for the systems. Excellent. So Anne-Marie, before we get your thoughts on it and your great analogy that you may or may not have that I just put you on the spot for, what do you think about that? Have we had a laissez-faire attitude towards tools and methods for the parts that we do? Yes. I realize that most of the organizations that I've been involved with have less than a laissez-faire attitude. I would say they have an ignorant attitude. Even if you don't know that Anne's modeling should have governance and should have it, they admitted and you, Karen, have both pointed out the underlying cause for the ignorance. Unlike professional engineers who have a body language that has grown up for millennia, engineers have gone back to at least the Egyptians with a set of best practices. The data management community, although we've had long, they can't claim to have rules that go back that far, around the need for governance. Many people who come to this profession came to it from an understanding of a need to have specifications and education in aspects of data management, including data architecture, meaning that many people are ignorant of the need for governance and practices in the development of models, and in the development of them. So they are using hairless shatter, nails that are soft. Yeah. So Anne-Rae, I just want to clarify. Some of the answers, you're using the word ignorant there more in the cognitive sense and not in sort of the common, you know, conditionalism of stupid, of believable of understanding, though, right? Not using it in the cognitive sense. Exactly. Exactly. So I think that's an excellent point, and I put down another question to follow up on later. So, Pete, we're now two for three. What are you, and also, if you have any comments about... So I want to ask you, do you think that we're doing a good job governing our models and all the other... And I'm going to use models today. I mean, I don't just mean ERDs and modeling files, but all the stuff we use, all the components of what we do as data architects or modelers. Thank you. And also, do you think... Actually, I'll just let you answer that first. Okay. All right. Thank you. Yeah. There's certainly a lack of governance around models, and it's part due to ignorance, but then there's also been, I think, with the push for agile, there's a big pushback on some people consider models to be documentation about documentation. And anybody who does documentation, just for the sake of documentation, but there's a purpose for the documentation, or at least there always should be. So I think there's some pushback. There's a push to get things done, maybe some of the management of the model and governance of the modeling tends to take a backseat, which is unfortunate because you want to be agile. You want to reuse and leverage the models that you've already developed. You get caught in the trap of making the same thing multiple times, giving it different names. And then, of course, you have the enterprise integration that we have. We've got different names for the same thing. And so I think definitely that governing the modeling environment and the data models is very important. And it needs to get raised up to the level of the data governance board or committee that you have. And I think a lot of people are really understanding the importance for governance. Governance of data, governance of models, maybe not much, but it really needs to get escalated to the level of data governance to make sure that our good practices in place are always critical to have a model of modeling standards document, models going off doing models in different ways. And so that leads to lack of standardization. One of the things is that the document, and what we know from the data governance world is that writing a document and throwing it up on SharePoint or some enterprise portal doesn't make it so. It's not, if you write it, they will follow it. You know, and it has to have some teeth. Of course, somebody has to be using and ensuring compliance. So how much do you see that? How much do you see in the real world? You know, not too frequently, but it's something that I always emphasize with my clients. You know, you don't have a standard document when I ask them, and it's one of those things that I developed. It's helping me to make sure, am I doing kind of what they're looking for? Am I complying to the standards they have now? Even though those standards might be spread out all over, in the comments or in people's heads, at least if you collect some of those standards, then I know their expectations. And then, of course, down the road, other people leverage those standards. Are we summary-capped by the way we do our job, which is, you know, I'm reflecting back on what I said before about building and building standards, and Marie commented that, you know, there's thousands of years of best practices. We don't have that. We also, you know, like, we have our buildings pretty much look the same, you know, mod some decorative stuff on the outside, but, you know, every skyscraper, you know, fundamentally is, you know, steel girders in the guts and pretty much standard, while everything we do is all based on some typically different requirements that are distilled out of conversations with non-technical people who don't understand the difference between what is visible to see and the desire for the input that goes into it. So, I mean, maybe, you know, it's hard to impose a set of standards when it's not clear that those standards are always going to enable us to address the needs of the people who are living in the world. Right. And, you know, standards, of course, you know, always have to be, you know, flexible if you try to nail the standards down. Honestly, there's nobody else's, you know, everybody's leverageable project, you know. So, to have it, you know, you don't have to be a, you know, 100-page document or anything like that. You don't have to, you know, get your teeth in there. The enterprise data architect or data manager, you know, should be responsible for making sure that the standards are being adhered to. You don't have to have flexibility, you know, because it's not always going to be, you know, the same when one case you might be doing your transaction processing, you know, like the normalized modeling. In other cases, you're doing star schemas and there's not going to be flexibility. So, since we keep coming back to this building analogy, I mean, one of the reasons, so, David, you said all buildings are mostly the same. Now, I'd say all buildings in places that have formal building codes that are actually measured and enforced, all buildings tend to be the same, or all bridges, you know, they don't look the same. They might have a huge variety in design approaches, fundamental differences between a suspension bridge and a cantilever bridge and all the other types. But the reason we have those is because people were harmed and killed in the past. That's why we have licensed professions. And, you know, I don't want to get into the whole licensing of the software world thing right now, but that's one of the reasons why we have those. The buildings do have common traits and we have not only the professionals who have to measure and try to enforce, but they also have the backing of building codes that are statutory-based, as well as standards of practice, plus sort of the weight of life behind them. And as we've seen in other locations in the world where there might be building codes, but they're not enforced, or there's no building code at all, people still continue to be harmed. And what do you think about that analogy? Do you think, you know, the issue is that we don't have the authority of data folks? You must be a mind reader. That's the sort of, that's where I saw your train of thought could be going. One of the differences I see that we have in the licensing world specifically and in data management generally is that we have the authority in most organizations for that we can recommend procedures. We recommend that best practices that we've seen work in places where we've had the authority and those places could be like raisins and tapioca pudding, fuel and farby. But we don't have the authority to enforce that, not without using just for-profit companies. I'm sorry, I did not use that word. So that's the result. Our client recently, with a complete list of any data management standards, starting with their data architecture. Data was such a mess that they are in serious financial trouble and serious legal trouble as a result. Right, and so I always say, if management, you know, one of the things I always say on these webinars is that we data people in general, but I think we data people are terrible marketers and are terrible at expressing our value statements and being able to draw a distinct line between a company enjoyable or a company's finances or a company's profit or customers or what it is. We're terrible at expressing it and all of those things. So what could a data architect do, a lonely data architect in the mass of a vast corporate framework infrastructure do to try to draw those lines? I think that, you know, this, Pete, I think that, you know, the data architect can only do so much. There has to be, you know, some data, and again, you know, I think data governance is the way it trades that visibility. I mean, you know, the data architect, you know, can start implementing some better practices and try to use and influencing, you know, capabilities. You know, it does become very hard, and you know, at the end of the day, there's only, you know, so much you can do. I mean, you can park at the window only so long. But I think, you know, we have to raise the visibility. I think, you know, data governance will help us to have better data modeling governance. Excellent. So, you know, I think there's part of that. There's part message and everything. But I want to ask all my panelists, including you audience members, is what are the parts that we should be seeing implemented in a proper data modeling governance, data management governance, whatever we want to call it, environment? So I'm just going to throw out data modeling tool because it's a real data modeling tool because I can't see, you know, even beginning to do this with drawing tools or spreadsheets on an enterprise level. But what else? What else needs to be there? I mean, you brought up standards documents. So, you know, that's policies and standards. But what else? I'm going to jump in here, which is, here there's an opportunity to standardize for characteristics of data using, such as, you know, I met the data, you know, I'm kind of not sure, but things like unit measure, like standardizing the information and how that corresponds to conceptual gains so that you don't have the problem of having to frequently redefine the concepts as you move from system to system. I mean, a good example that we use often, which is pulling examples of definition of state from the United States federal documents every single time there's the use of the term state, there's another qualifying term that says, you know, whether it includes, you know, territories, whether it includes Alaska and Hawaii before they became states, you know, like if you have to continually refine a concept, then you can't even get to the point of using it in a standard way. A really great point because I'm glad you brought up, you know, reference data because most modelers aren't involved, most modelers I work with don't think they need to be involved in managing something like reference data. Even reference data can be implemented a ton of different ways, right? It could be in a table, it could be in an XML, it could be in drop-downs, you know, in the code, that's very common with states. And if anyone could change that architecture in just a minute's notice and put it somewhere else that we don't even know about and it never gets updated again, I mean, that's kind of like, Ann Marie, what we were talking about in the pre-show about chairs being changed beneath us. So that's difficult. Someone from Q&A, Gail LeWaire, has said that one of the things is we need accountability for data within the project, and I think that's important as well. And you're bringing up metadata and metadata as much as I also cringe at those phrases. One of the things I remind data architects is that this metadata, these models we're playing with, there are data, right? So the whole data is really about perspective. So a lot of times I have trouble getting all of our tools and the databases our repositories and marts use and everything treated just like other production systems, even though they're our production systems, right? Right. But developers' tools is their production. They're not writing development tools. It's their production. It's how they do their work. Exactly. And one other thing that I would add, this is Pete again, that I think for enterprise data architects, it's very important that you start building or reaching out your enterprise data modeling because that's a very important reusable artifact to help drive your organization. And of course, also, modelers should be reusing models. If you have the same needed, we don't have to redesign a new table. We leverage that existing table definition in our models. And so we try to reuse models wherever possible. And I think with regard to reference data, I think having this distinction of metadata because if everything is data, then it can be kind of hard to talk about it sometimes and to distinguish. I mean, when you're talking with your business people with other technologists, but with reference data, you should try to document in your models in order to understand like the reference, you know, let's say, well, what's the state? Is it a United States state? Is it a trans-processing state? And so having the value to use enumeration wherever, when you can within the model metadata is a very valuable thing to do. One thing that I think people overlook when talking about the concept of data governance is that in an organization that has data modelers and or data architects, whether they're different roles in the group or if they're the same role with different titles, it doesn't matter, is that they should be involved in the data governance program. Too often organizations silo functions and don't see the benefit of between data parts of the data management community. One of the things that I try to do in the data governance initiative of any size is to make sure that the data modelers, data architects are involved in the data governance program because a lot of the knowledge of the data the usage, the reside in the data modelers' heads, especially earlier, a lot of stuff isn't documented. So we try to then try to drag it out from wherever sources, using the coverage that exists from the data modelers in the organization makes the data governance program development go so much faster. Do you agree with you? Okay. Because I think that most of the knowledge is implicit. And so this goes back to something Pete said, which is seeking to do model reuse or model element reuse is very different from the person who is defining the item as opposed to somebody who's using it. And what people do is look around if they're encouraged to do model reuse. And we've seen this in things like Neem or its precursor. Yeah. The data architecture model. Right. The Justice XML model where the enumerated catalog of data elements, but the rule was you could and you could redefine it. So there's this presumption of the ability to reuse it, except that, number one, you can pull it off the shelf and then you can just tweak it a little bit. While you claim that you're reusing it, you're actually creating a new thing. And then you, let's say, let's use the government technology, take it one step further, which is now you're responsible for creating some kind of transparency data set and you dump it on data.gov. And somebody else comes along and looks at a set of columns in this table and without the definitions that were used for the processes that were creating this data set that may have pulled data from five different data sources, all of which has slightly tweaked. Now, I'm a user of that data. I don't even care. I'm going to reinterpret state as to mean what I think it means, not what the five data architects were thought of when they built the original system. It's who we're involved in the integral process. So, I mean, the data is not there. It's in the eye of the beholder. If you don't involve the people in the organization who are data architects at all in this program, you won't know what anybody meant, especially in companies that never had any documentation. We walked into it quite a few times. One thing I would like to throw out here is... Oh, sorry. Go ahead. Okay. One thing I would like to... I think this is highly related to data models, but it's very important. And I think we're realizing that they really need to have a business glossary. Of course, you want to try... Well, you want to strive for standardization. In reality, it's not going to always happen. You know, you have to package applications which have their own names, and all things by different things, and you're not going to, you know, rigidly enforce standard across the enterprise. I mean, if that's great, in most cases, that's not going to happen. But, you know, for using a business glossary, we can match these business terms and then match them down to, you know, implementation names. You know, so we have, you know, customer, you know, something customer, but over here they call it an account, and in the department they call something else, and this system is called, you know, XYZ and so forth. And so business glossary, you know, is a very important concept and that can help, you know, where you can document that. Because now, you know, that enables governance. You know, when you govern your information assets, if you don't know where they are, you know, then you can't really govern them. And... Right. You know, they brought up data growth with the Web, and I think that the Web can really help us walk across terminologies very easily. Right. I think that's powerful. Okay, and I'm the moderator. Hey. Hold on. I think it's great that we have this really fast-engaging conversation. I love this. But I want to point out that I think the glossary thing is great, and we're starting to see a lot of the modeling and architecture tool vendors really getting a good understanding of that, as well as modelers understanding that an ERD for a day-based design or build or package project is not the same as a business glossary. But I think we tried that in the past. Right. And so I think that's really great. So I'm seeing progress in our production. But I'll go back and ask sort of this other question. What are the systems where we don't need data model governance big, or big data model governance, as I should say, in the learning go of today? You know, what I call and what I see a lot of is data modeling via email. So there's no repository. There's no version control, communication control. Every modeler or developer has their own data modeling tool or a database design tool and then sort of email files around. Or something less structured and everything. What are the situations where that would actually be a preference? If the universal consultant answer is, it depends. When are the cases where that depends? It depends. Go ahead. Yeah, it really depends on the environment. I really think that I think that we're working in the agile development group during the stages of development. It's very experienced, really talented developers who were in the stages. But I am enough of a data management purist to say that once you hit level of involvement involved for testing, that I would be less confident. Okay. David? No, I can't answer that because I have to balance practically with the approach which would say, always govern every time. I always say, guys got together in their garage to launch that new business. They didn't sit down and start laying out an enterprise architecture. They did what they needed to do in order to make things run. You're never going to get to that point where everything is always going to be perfect and you have to have some level of control of the chaos that allows you to, if you're going to plant down on everything, then you'll rarely get... You don't have an answer. That's great. Pete? Many times I've had to do data modeling by e-mail and leading a team to develop industry data models that were forced to send model files back and forth. It's not ideal, but you have to work with the constraints of your project. One thing I would emphasize is if I had to send a model off to somebody to make changes to it, e-mail the team and let them know that Joe, remember, they've got the lock on the model file. So we should be seeing out of that model file or at least not making any changes. That's not working. It's tough at times. It is tough, but you have to work around it. Of course, we'd have a data modeling repository where you can do team-based modeling and have locking down at an object level rather than locking the entire model. I would also like to comment on the multiple tools question as well. You want to try to strive for a single modeling tool, but there are some caveats to that. I would say some of the data modeling tools have considerable data modeling capabilities. Sometimes some of the modeling tools are really good at logical, physical modeling, but not so good at conceptual modeling. And then there are two situations where I can model multiple inheritance in a conceptual model through the tool. So I had to do that in an enterprise architecture tool or some other kind of tool. So, yeah. I'd try to strive for a single tool. I'll answer this because I tell the project teams I work, I don't trust myself enough to do it that way. So even when it's just me modeling, I still have to have a repository. I still have to have version control. And I think there's a reason why things like Google Docs and Skype where you have automatic versioning and you can check things out and check them back in. That's just a Word document or a spreadsheet or a PowerPoint that you can do that type of governance on in a distributed, collaborative environment that, you know, my own files even. And I'm the only person updating them and I still need all of those features to protect me from myself. So, you know, my answer to this data modeling by email question is I tell my project teams that are pushing back on that extra few hundred dollars per seat that it costs to have a repository to just acquire the license anyway if they pay itself off, probably in the first 90 days from all the rework that has to be happening and all the comparing and merging of whole files and the misunderstandings and the accidental deletions and all of that stuff, that cost is easily quantifiable and we could write a business case for that in probably 15 minutes just by using, you know, some standard rates and everything. And to make tools for governance, I can't do any of this governance that way of the actual modeling objects without those tools. The model is just too big and complex, even a simple model. And that's definitely the ideal. Right. So, philosophical or David used the word academic ideal. I think it's a very, very practical thing. I mean, we don't ask our developers, even though they love Notepad and Emacs and, you know, all these text setters to do their work, still big fans of version control and having to go on there. And they're agile people. They don't want to use too much process, but they know that we're humans and things get open, emails get opened out of order and people forget to include people and see and people don't have their email or something like that. But I think the first step to solving a data modeling governance program is getting rid of email as an architectural tool. I don't need that. See, I don't have a process-oriented person and I'm not an instructor and that's why I practice data governance probably. It's probably... Yeah, okay. Nature and structure combined. Yeah. So, my question to the panel and to the audience is one of governance, of data governance, is monitoring when things don't comply. You know, in our analogy about a building, you know, an architect or an engineer not only does a design, but they have to go out and review the things as they're being built, not after they're built, but as they're being built on a regular basis to ensure that the intent of the design is being followed and where it isn't, they have to document it as well as approve where it deviates and there are really valid reasons why changes from the design process have to happen as things are being built. You know, you even go into some physical characteristic of the water tables or materials that have been substituted or any of those things. They have to approve of those and then they have to document their approval and issue new designs that incorporate that and that's a highly iterative process so it's very agile, but it's still a measurement and compliance and enforcement and they can order designs or implementations that have deviated to be corrected in some way. Correction might not match the original design. So we don't usually, most organizations, don't give data to architects that sort of enforcement power. So what should data architects that don't have the power to do that, what part of that process should they do? You know, I would say that, you know, I think we've got an analogy very much of, you know, the architect, you know, the work, you know, as it's going on, it's looking at the finished product. I think, you know, architect definitely needs to be a part of the project team and I think in most projects that I've worked on, that in some cases is not, you know, you know, so they need to be in a project, you should always allocate some time, you know, for your modeler to be involved. And I think, you know, most people, you know, they allocate some time to the modeler. You can't just model something and then just turn it over to the development team and then walk away. It's just a recipe for disaster. And so I think that the data really needs to, you know, if they're not part of the project team, you know, to escalate that with data governance, you know, with the application team management. So, you know, just accept something they should try to change. That's a good point. Now, what else? That we give in our consulting projects is that that kind of engagement has to be, that fundamental change to the system development lifecycle to take into account that level of interacting engagement and essentially validation because it's a change in, you know, within application and function focus and not data focus, right? So, that's change management activity and maybe, you know, it's not the most glamorous activity, but the data modeler or the data architect should insinuate herself into the SDLC. Let you do all that as long as you make it go faster as well. So, you okay with that? You know, you say that. I used to, when I was first, my first career was developing compilers and I was actually working on the optimizer for the compilers and say, you know, the customer would always come back and say, can you make this run faster? And I say, yeah, it can make it run really fast. Do you want it to run correctly also? That's a good point because one of our Q&A comments was, what about our governance process based on the risk of economic risk to having bad data? Is there any risk of having bad data, I think, right? That's right. I think, I think, I think one of the things I think is the one that had the severe financial issues. They did not see the financial and economic challenges that were still in the face were trying to orient it until it was too late. They just, we do this faster and we do this with, we'll be fine. They did not, their fundamental challenge was really data-oriented, despite our best efforts to show them that they had no good data as a result of data was lousy. The quality of data was lousy and that was costing them a million dollars. They did not understand the link. You know, one of them, one of the things that came to mind, up in the county, but they hired, you know, a business consultant to come into business process re-engineering. They had an analytics process. It takes so long for everything to get done and we're having problems trying to close at the end of the quarter. So they brought this business consultant in and this person realized that they don't have a process problem. They have a data problem. The process was not, I'll get some data, you know, from this bit from the base and then I have to, you know, make some spreadsheet. I need to make some changes in the spreadsheet and I need to send it over to somebody else. And so, you know, the process problems are really at the core of the data problem. The core of the data problem is a process problem. They're not near all their processes, but by getting their data house in order, that simplified their business processes. So you see a lot of, you know, the effort, the 80% of the effort is spent on fixing problems as opposed to delivering a value chain or whatever buzzword I'm supposed to use there if they do it in their job, right? But back to your question about whether you have the right tools for what we're attempting to do. Sometimes the best data and governance we still have really significant data quality issues. We can have the best data models in the business and we still have lousy data. As data practice points out. What we find, you know, like, I'll go back to what I just said, which is if not more of the time where there's a data quality issue, it's the process fault. It's the fault of the process. And that, you know, whether it's not governed or whether it's, you know, nobody's checked to make sure that, you know, that extract actually happened today before. It loaded it, you know, for the 16th data flow into the data warehouse because nobody noticed that the other thing didn't work. You know, we see this all the time. The fact that it's really easy to dump data into Excel and then use that on a PowerPoint and then somebody else draws some conclusion from that where, you know, you're reliant on the oversight of the chain of troll of that data. So, you know, whatever the model is, I mean, you are, to any level of governance, that's cool. That's, you know, that's set up policies and processes and socialization and engagement and buy-in from the people that, you know, it's not the data modelers that you need to get buy-in from everybody else. That's part of the point of the cultural change that we were talking about about five minutes ago. The SDLC has the data modeling much later in the process than they really should be. The data architects really need to be at the very beginning of the engagement project of the whole SDLC process as it changed because so long people didn't love their data. So, we have a, that's a great connection that, from again, that all business projects should have a portion of their budget tied to data management as part of their business practices. So, I like the principle of business throughout that because I do think of what we call IT projects, we should really be calling business projects unless they are, you know, pure infrastructure things and they should still be doing the business. That should be the motivation and the reason. But generally, most of our IT projects are actually business projects. I think a lot of people in IT don't realize that. They see them as code projects or database projects or something like that. But I think it's a double-edged sword is that if we have a budget tied to data management, that also implies a whole bunch of an accountability. So, what if we have three data modelers and 130 business projects going on at the same time, budgeted for them in the business projects, but we can't recruit all them. So, my question, we only have a few minutes because I want to make sure we have some wrap-up time, is the complaint that we weren't funded for enough positions, but I'm seeing the pendulum swing. Is data model governance also impacted by the fact that I know a lot of companies are having a hard time finding real, experienced data management professionals? In the mafia area, there's a real call for senior-level data management professionals. I can't answer that. Okay. Anybody else? I think that's all that's coming in. Me, too. All in favor? Well, I think that's part of the problem. So, I think that's part of the problem is most of the senior people I know in data management that have real hands-on experience and a good data domain have almost all moved into the consulting business. So, when I say there's kind of a shortage, I mean, you know, people who are willing to take on full-time regular employee work or what I refer to as a real job, they are not in time. There are consultants and everything, people like all of us right now in this webinar, but I think, you know, that I called 2013 Year of Data, pendulum swinging back to data because of big data and open data and semantics and all this heavy emphasis on data. I think there is a shortage of experienced people, and that's why I'm seeing job ads that call for people with 15 years of experience. I used to net data. So, good data governance if all we've got are people who've never done data modeling before. Thank you. You have to go ahead. The whole project is being called on to do it. In most environments, they're not building things. They're enhancing existing things. What are some of that data modeling? Yeah, but it's not, you know, it's not a difference. It's not building something from ground level. It's like a friend who's an architect who works for the architect of the capital. I mean, building that thing from scratch, they're just like painting. Painting capital. But it still requires architectural oversight to make sure, you know, if we plan with a certain type of capital or whatever, what kind of a problem is that going to have. So, you still have to have, you know, some of the modelers involved. And so, somebody's trying to, you know, understand, you know, what do we currently, you need to have somebody who can explain what are the assets that we have currently and then how to expand them, reuse them, and build on them. Many times, you're not building something, you know, you don't have a Greenfield development project, but you still have to understand data, understand the model, and be able to apply it. And that brings us up a good point that we are still, and I do see this building data in March, and I'll say data warehouses from scratch. A lot. Good. So, a query. Yeah. Go ahead. Keep going. Okay. I know that, you know, to address the shortage, I think, you know, we have to, again, you know, keep raising the importance of data until people are focused on, you know, application development, and, you know, it's, you know, sometimes they don't see the value, you know, in the management and the data modeling. And so we need to keep raising the importance of data and then, you know, to, you know, encouraging people with a really solid analytical skill set, you know, to encourage them to move into that, into that goal, and then, you know, of course, provide the training for that. I love those things. Just a last three minutes. Oh, go ahead. One second. I was going to say that the tendency to have a lot of data modeling done by outside development seems to limit the capabilities of building robust data models for people who may not have been in schools in data modeling the way they were in generations past. And then, you know, anyway. So, I definitely agree with that. Yeah. So, we're down to our last three minutes or so, a couple of minutes. I wanted to ask each of our panelists if they have any closing, very short takeaway, blurbs, taglines, anything about data model governance for the listeners. So, let's start with Pete. Okay. Again, data models are critical that's in and out of themselves, and they need to be managed and governed, you know, appropriate, and at the minimum, every organization needs to have a data modeling standards document. And the data model can be treated as the data model as an information asset because it has your, you know, your data model. All right. Data governance. David. The perspective is that you've got to drive your governance in relation to being able to satisfy the needs of your audience. If you can't make that link, then it's very difficult to establish the value proposition for doing any type of governance. And people need to practice saying that value proposition as well. Practicing with their kids and their pets and everything. Now, to the last minute, we're going to do the webinar and turn off the recording and everything, but everyone's invited to stick around for the next 15 minutes or so where we can kind of do some less formal talking about these things. And continuing the conversation though, I wanted to thank Shannon again for pulling us together and Tony Shaw of Dataversity for making sure all this happens as well as CA Technologies for sponsoring it. And their product is Erwin Data Modeler. So you should definitely go check it out since we're talking about data model governance. Shannon, did you have any closing comments? We reiterate those sentiments. Again, you know, big thanks to CA for sponsoring because we just enabled us to provide these webinars for free. And to our panelists, see, guys, this is a great conversation, very energetic, very active, and thanks to everyone for attending. The recording is now officially off.