 Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of DataVersity. We'd like to thank you for joining this DataVersity webinar modeling data governance sponsored by IDERA. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them 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 DataVersity. As always, we will send a follow-up email within two business days containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now let me introduce to our speaker for today, Kim Brashaver. Kim is the Senior Product Manager for ER Studio Business Architect at IDERA. Kim has over 20 years of experience as a business analyst, software developer, product manager, and IT executive. Kim also enjoys working as a translator between the business and the technical teams in an organization. Now with that, I will turn it over to Kim to get us started. Hello and welcome. Hi. Thank you again for having us. I'm excited to talk about this topic today. And we'll be covering why you should be doing business process models in order to outline your data governance program. So I like to always start my sections with quotes. So one of the ones I picked for today is War is 90% Information by Napoleon Bonaparte. And without data, you're just another person with an opinion. So what is data governance? Data governance is the fine art of defining your data, modeling your data, ensuring the quality of your data, tracking your data, knowing who is accessing your data, protecting your data, and meeting your regulatory guidelines. And here I've thrown up a few of the standard regulatory guidelines that a lot of people are looking at in regards to data. Of course, there's security-oriented regulatory standards. There are, you know, other standards that your organization might be held accountable to. But it's very important to be looking at what those standards are asking you to do in regards to your data governance process. So data is not information. Information is not knowledge. Knowledge is not understanding. And understanding is not wisdom. And if we have data, let's look at the data. If all we have are opinions, let's go with mine. So these are kind of some fun chuckles along the way. So how business process modeling can help? When you start talking between the business side and the technical side, there's a lot of jargon that takes place. And the business side has a lot of focus on one side of the world. And the technical side has a lot of other different objectives and priorities that they're trying to reach. And when you are speaking in your native tongue, then you tend to get a lot of different words thrown back and forth. And some of those words may not be as understandable to some of the people that you're trying to talk to. So having a good picture in place where both sides can understand what they're doing is really helpful. So I'm going to play a little bit first before we get into the nitty-gritty details. So let's imagine a dog grooming studio. In this case, my story is fluffy paws. The dog grooming studio is the perfect place to bring your special fur babies. We know how important your dog is to you, and we want to ensure that they are treated like the prince and princess that they are. We offer bass, nail trimming, haircuts, de-shedding, and flee treatments. So when I tell you that story, it brings up an image in your mind. Whether you have a dog or you don't have a dog and you've been to a dog groomer before or you haven't, you have a picture that comes to mind. So your picture could be something like this or maybe this or maybe this. But ultimately, we all have different pictures we've dreamed up in our heads, and when you can actually display the picture, then it helps to get everybody on board and speaking the same language and dealing with the same thing. So pictures aren't just worth a thousand words. They enhance the story. They communicate a vision. They can be language and jargon agnostic. They clarify the points that you're trying to make. So why may it use pictures instead of words when you're describing a business? If you were trying to gather requirements, the client might say, I need an application that will help me run my dog grooming studio. And if you're just using your words, then it's like, okay, so the application needs to schedule appointments, check-in check-out dogs, charge the customer. And you as a good developer could be thinking in regards to appointments, well, how is this appointment scheduled? What information is needed for the appointment? What kinds of services are offered? What information do we need to capture on the dog? What information do we need to capture on the owner? And do we want to retain information for recurring customers that might come back? Additionally, when you're thinking about the check-in and check-out process, you could be thinking about questions of how do I check-in or check-out the dogs? How do I build the customer? Are there special coupons? Do we want to give paper receipts or emails? Do we want to contact the customer later? Do we want to track information and understand the business analytics? And you have a lot of different questions that all come to be on that simple statement that just says, I need my application to do three things. And a whole conversation can start to take place just on those words. And your customer's responses may vary. They may give you no information when you ask those questions. You're the expert. You're supposed to figure this out. They may give you very vague information. They simply respond to your questions, but they give you no additional information, just yes or no answers. They may give you too much information. Technical manuals or 100-page business requirements that go into painful detail about everything you need to know and a whole lot of information that you don't that's not really important to the conversation. So pictures allow you to easily communicate and interact with your not-so-technical boss, your coworkers, your clients, your customers. And that's the gist of this conversation that I'm jumping into. So for example, if we were putting together a really basic business process for grooming, we know we want to schedule the employment. We know we want to check in the dog. We know we want to groom the dog and we know we want to check out the dog. And from that, we can start to build out some more in-depth processes. So in this case, we're going to break down scheduling appointment. We can start to talk about what type of dog is it, what type of services, what information are we going to collect about the dog, what information are we going to collect about the owners, and then maybe start to schedule the appointment. And if you lay it out here, you've got your tables already defined. You've got your fields already defined. You can start to talk about additional tables that you might need. And you can start to have this conversation, even with somebody who's a dog groomer. They can look at this business process and understand these are the elements that I need to run my business. And on the data side, you can look at these and say these are the elements that I need to build in order to build this application. And so business process diagrams are really powerful and can be really great at getting those conversations started and talking to people and having them talk through the processes without a lot of paragraphs of manuals or a lot of dead stairs. So business process models, pictures can save the day. And sometimes they just make us smile. And you know, if you're not a dog person, I hope you would still love this cute little smiley corgi. So without big data analytics, companies are blind, deaf, and wandering out onto the web like a deer on the freeway, according to Jeffrey Moore. Data that sits unused is no different from data that was never collected in the first place, which is another profound statement of when you're looking at your data and you're trying to understand it and you're trying to get people to come on board with what you're trying to accomplish, obviously you want to be able to use as much of that data as you have. So what does this have to do with data governance? So the reminder after my doggy distraction is that data governance involves defining your data, modeling your data, ensuring the quality of your data, tracking your data, know who's accessing your data, protecting it, and meeting your regulation guidelines. So in these next steps I will go in and I will break down each of these little bullets separately. I will then show you a business process diagram that is meant to help facilitate the conversation between people, and then I will show additional examples after that of, you know, breaking down a piece of that conversation, so that you can start to think about how you might want to build your own business process diagrams to get conversations in your organization going regarding all of the different elements of data governance. So when you're defining your data, the things that you might be thinking about are, how do you define those data elements? Are your data definitions consistent across the organization? What is the lexicon and jargon that you're choosing to use? And how is that data mapped to other systems? So here's a really high level business process. I kept all of these, with the exception of one, at an extremely high level just because I didn't want you to spend a lot of time looking at the details, but instead just understanding the concept. So in this case, we could break down all of the different tasks that are needed in order to look at your data definition process. And these are a lot of the same questions that I asked before, but as you see, you're able to drop down, you know, okay, so when I create and communicate data standards, data standards are going to fall out of that process. And when I set up a committee to create the data dictionary, I know that I need to find some stewards or some people to be part of that committee, and then I need to have a result that drops out of it that's called the data dictionary. So of course, you can add other artifacts that drop down during the process. You can deep dive into any of these particular elements and to be able to really understand and have this conversation. But if you go to a business user and you show them a picture like this and say, this is the conversation we're going to have today, they can really understand the flow of the conversation and the elements that are trying to be covered without trying to write some sort of several-step outline or document or requirements to be able to dig in deeper on these details. So this is a data mapping example. And again, very high level. So I've sat and said, okay, I've got a web system. I've got a retail system. My two tables may be completely different names in different places, but I want to start to show how that information is going to get mapped between one side and the other. And of course, as a DBA, you're going to get into far more complex meta-details about all of this information. But when you're talking to the business side and you're showing these business pictures, these kinds of things can be really, really helpful and they can really think about it. So your web guys and your retail guys go, you know, we are capturing the same information. Or maybe we're not. Maybe there's a reason why order and purchase are completely different and why they're different in one system than the other. And maybe they need to be handled separately or maybe they can be combined together or maybe there's some best practices. But this can start the conversation so that they know I've got all of these systems that need to be able to map together and come together. So the next element is modeling your data. So what does your data look like? How many fields and tables are you trying to capture? Which of your data is informational? Which is used purely by the system? What meta-data do you want to capture? Can you consolidate redundant data? You know, which of your data is sensitive and protected? So again, I've gone through this process and of course if there's Q&A at the end I can drive back to any of these to look at greater detail. But in this case I've said, okay, am I starting from scratch or am I not starting from scratch? If I am starting from scratch then I need to meet with the team, develop a conceptual model, create the data model and you can see my artifact of the data model hanging out there. You can also, from that point, once the data model is created you can review the fields and tables in it. You can identify your informational data, your system data, your meta-data, your personally identifiable information which is extremely important now with GDPR coming online here in three days and all of the implications that that's going to mean and being able to consolidate all of your redundant data. And when you talk through this process and you deliver this process at the business side everybody can get online and say, okay, so whenever I've got new data that needs to be modeled we're going to go through this process and this is the process that we follow. And of course if there are any elements missing or need to be changed in order you can quickly and easily do that with a business process model. So in this case I've just outlined what you might want to do if you're like bucketing. So you say, okay, these are my tables that contain personally identifiable information. This group has informational data but it's not personally identifiable information and then I've got some data that's my system data and be able to start really talking about that, thinking it through talking to your business users and having them understand, you know, what information is going to be subject to regulations and guidelines and what information isn't. So the next aspect is ensuring the quality of your data. So how do you measure the quality of your data and what is the current condition of that data? Are there any places where data may be unreliable? How accurate does your data need to be? How do you identify that there's an issue with your data? How do you fix the data that may be inaccurate? And how do you create parameters that are consistent and repeatable? So here I've mapped out a potential data quality process. So in this case we say, okay, so how do we plan to measure it and how are we collecting the data, storing the data, cleansing the data, processing the data? What are the elements that you say we need to go into detail and we need to discuss those further when we're talking about them? For data profiling, what is the current state of our data? And it may be, you know, that a DBA is involved in being able to really look at that and understand that. What might our data, where might our data be unreliable? Again, you may have your DBAs looking at it and determining, you know, these are the places where we need to improve some quality. So the next one is how accurate does our data need to be? And then how do we identify data issues? And so in this case I've dropped down on artifact for a data action committee because I think it is helpful to have a group of people within your organization that can make decisions on the quality of your data and help you to really understand, you know, what actions do we need to take? Is this something that we need to go back and make it more accurate? Do we need to make it more reliable? Or is this an aspect of data that maybe doesn't need to be as reliable as others? And then I've got how do we plan to fix the inaccurate data? How do we create parameters that are consistent and repeatable? And so an artifact that might fall out of that would be data quality parameters. And how do we handle data errors? And again, an element on how those data errors might happen could fall out of that. And based on this, you can go into that conversation with your business users. You know that you're going to be discussing all these topics. It's a quick, easy way to be able to do an agenda and an outline. And everybody knows at the end of the day there's assignments that are going to be made. There are groups that are going to need to come together. There are parameters that need to be defined. There are, you know, deliverables that are going to fall out of that meeting. And so this is a really quick and easy way for people to be able to know and see the responsibilities that they might have. So in this case, I've decided to go with the fixing the incorrect data. And I've gone through and said, okay, so we might identify our inaccurate data. Then we need to decide what's the cause of it. Is the data poorly defined in the first place? Is it incomplete? Is it just out of date? Or is it completely wrong to begin with? And then if you've identified those known issues for the incorrect data, you could put together a quality committee that decides, okay, so based on these factors that have come in, what's the most important to address? How severe is it? What is the priority on getting those things done and having those kinds of conversations within the committee? Then of course, at intervals that you define, you'll fix the data and then you'll determine how those issues can be prevented in the future. Again, this is a great conversation to be able to have with your business users where they can really quickly and easily understand the elements that are in play and the important issues in order to make sure that the data is correct and accurate and of high quality. So in tracking your data, so questions that might come up would be, where does your data go? And when does the data come into your system? Where does the data leave your system? How can the data be used? What does the data create? And what does it consume? And what rules does your data follow? So in the data tracking process, you might look at, again, where does it go? Where does it come from? Where does it leave? In this case, I really kind of did just a straight conversational, okay, these are the questions that we need to address within our business team and say, you know, where are all these places that data is going to come and go from and how am I going to keep track of it and really important elements in tracking that data and making sure you understand the lineage and you know where it comes in and where it gets changed and where it might go back out of the system, which is important to track. So here we've got a process diagram on order tracking and this case you might have an order entry system that then checks inventory, that confirms your order, that prepares your customer bill and asks if that inventory is available. If so, it'll fulfill the order. If not, it replaces it on back order and it'll ship the order. In this case, I'm able to really quickly see, okay, so I have to have a table for available inventory. I have to have one for customer order info when I'm looking at this. I've got four different applications that are all tracking between my inventory systems, my order entry system, my billing system, and my shipping system, and all of these are going to be changing and altering, especially my customer order info as the status goes on. So looking at that kind of information and really being able to get in and track that data and understand it's path through the whole product. So the next element is knowing who's accessing your data. So who can access your data? Who can influence your data? Do they have full access or can they just access some of the data? Do they have read access or can they update the data? And how is your data stored? So again, we'll look at who can access it, who can influence it, do they have the full access and these diamonds are represented as decision points so that there's a conversation that needs to be had that says, okay, so based on the way that I make a decision path, how does the behavior change? And in this case, I may have my DBA, my system admin, my network admins, my solutions architects, and they all have different responses to all these questions and I need to know how does that access change and what information needs to be tracked. So in this case, I've gone through and I've identified a few different ways that you might be able to say, okay, so I've got one person that has access to my financial data and I need to lock that down for just that person to have access. And maybe I've got military and government data and I've got somebody else that's responsible for tracking that. My personal health data, my private individual data, and then the rest of the data might be available and open to the entire data team and being able to start to really have those conversations. The other thing that having this kind of a diagram helps you to understand is when I've got an issue that comes up in regards to financial data, then I know who I can go back to to talk to about the data and I also can lock down that only Quacky McDuck gets to see that financial data and having those business conversations to make sure that everybody's on board and agrees that certain people have access so that when you lock it down there's not a lot of people who start to complain. They're like, why don't I have access to this information? I had access to this information yesterday and now I don't. And so if you can lay out one of these things with your business team and they understand, you know, you don't get access to this anymore because only this person or this team or this group can have access. And this is an example of maybe a data archiving process. So you might say, okay, so I've got three different data stores. One's my inventory tracking. One's my online orders. One's my data warehouse. And after a certain amount of time that information gets placed in other places. So after 90 days my orders and inventory may go to the data warehouse but I have to archive the order. And then after six months I archive the inventory and being able to have these conversations of after how much time does my data transfer to one place or another. Another element is protecting your data. So how is your data protected? Is your data encrypted or is it masked? And what do you do in the case of a data breach? And this is really going to become very important, especially with GDPR coming because with GDPR they're saying that you need to be able to notify within 72 hours that a breach has occurred on your system. And I think that definitely there are lots of people who are scrambling to meet this requirement because it may be several weeks before they notice that someone has gotten in and had access. And being able to put these kinds of processes in place in advance helps you be able to really quickly detect an issue that's come up and understand everybody on the team understand how you're supposed to respond so that it can be addressed quickly. So here again, you might be talking about well how do we protect our data? Do we protect it via backups, mirroring, snapshots, disaster recovery? That's a big element while it's not data breach, it's an understanding of what am I going to do with my data and how am I going to store it off and having those conversations with your teams to understand so that everybody knows in case you get hit by a bus, everybody knows exactly where the data is being protected and how it's being protected and how to recover it if something were to happen. The other aspect is understanding what data needs to be encrypted or masked. Is it personal data, logins, financial info, systems and what will we do in the case of a breach? So this is from one of my documents that I've done in regards to GDPR and you've got process documents that need to be followed. You've got regulations that are impacting your processes. You have to check the current procedures of data protection. Are you in compliance? If so, you would report to management. If not, you need to inform the owners and update and publish the procedures. You may have data owners that are involved or data protection officers. And if you tried to explain this in words, it could become a really quick jumbled mess. But when you can clearly put it in a process diagram, where you've got arrows that are connecting to various different places, then you can really kind of start to have this conversation in a way that flows a lot better and that's a lot more helpful for both the business and the data side to understand. And in this case, this is a really high level, quick data breach steps document. So the instance gets reported. You gather the preliminary details. You confiscate or shut down the hardware. You investigate the threats. You determine if there was threat. I mean any theft. If so, you notify the management team. If not, you might file a report. And so being able to put those pieces together and be able to really quickly say, okay, this is what happens. If you've noticed a breach, then you need to follow these processes. And that way it's repeated every single time. And it's very clear exactly what you need to do. So the last aspect of data governance that I wanted to cover in this conversation is meeting your regulatory guidelines and understanding what guidelines you have to meet. How is your data impacted by those guidelines? And what do the guidelines require you to do? So here I've dropped out, again, if you notice some little artifacts where you have to determine which regulations you're going to follow. And that may be a number of regulatory guidelines that come together. You need to alert your organization on what you're going to do in order to become compliant so that if anybody asks that needs to know that information then everybody knows and everybody's online with it. You need to determine which of your data is impacted because with every regulation there's lots of data that's not impacted and there's lots of data that is. And being able to really understand what that impacted data is and have that conversation with your team. Determining policies that need adjustment. Sometimes these regulations will come in. There's a lot of people right now that are scrambling trying to understand what does it mean if somebody is asking to be removed from existence and how does that affect all of my different data and how does that affect policies down the road that are saying normally if somebody wants to just be left off the list I do this but if they want to be ignored completely like where do my other systems get messed up in that process. Defining a compliance committee is really important so that anytime new data issues come up there's a compliance committee to be able to have that conversation and determine okay so based on the fact that we're following HIPAA compliance what does that mean for my data or I'm following PCI compliance what does that mean for my data. Determining the organizational impact. In some companies they are completely prepared for this already they've been dealing with SOCS or PCI or HIPAA for some time and they're already good to go. In other organizations bringing in a regulation will completely upset the organization and you may have to decide okay I'm going to do baby steps and I'm going to address these elements at this point and these other elements at another point. You would then go through once you decided when you're going to implement those steps you'd implement the updates and you would audit your data and policies. So I promised you a really nice complicated process. This is the process that we have for one of our GDPR models. Obviously I don't expect you to be able to read all these tiny little blue and red words but you can certainly build a process diagram that has a lot of complexity to it that has a lot of notes in it that say okay these are the things that we need to be talking about and all the elements we need to be considering in regards to each of the different items that need to be addressed and need to be talked about. So in conclusion it's important to define your data governor processes so everyone is on the same page. A good data governance will help you demonstrate compliance for those pesky regulations and business process models pictures can make collaboration a lot easier. And I purposely kept this conversation a little bit shorter because I thought that the questions that you guys might have would drive a lot more of the conversation in regards to the issues you guys are having in modeling your data governance. So at this point I'm willing to open the conversation up and I'll be happy to go back to any of the slides that I referenced. Kim, thank you so much for another great presentation. We've got questions coming in. If you have questions, submit them in the Q&A section in the bottom right-hand corner and just answer the most commonly asked question. Just a reminder, I will be sending a follow-up email on the end of Thursday for this webinar with links to the slides, the recording, and anything else requested throughout. So diving right in here, Kim, could you describe your governance structure a little for decision making? Yeah. So trying to think of which slide might showcase that best. Let me go back to my schedule appointment one. So each time that, like I said, you've got these diamonds in your business process models that are a decision point. And when you're modeling out these processes, when you put those decision points in, then it's a point where everybody that is in a meeting or in a meeting knows we need to make a decision about this. And in this case, I guess it's not that big a deal. It's just trying to determine what the breeds are and the services. But as you're going through, it's like, okay, so we know that the rectangles are the tasks that need to be accomplished, the activities, the conversations that need to be taken place. But when you're really starting to drive into those questions, you can start to put in your business process models that I've got a decision. And maybe I know on one half of the question which direction I'm going to go in. And maybe I don't for the other. And so I could draw a line down, do a big question mark and say, okay, I know that if I want to do this type of service, I'm going to go this direction. But if I have another service, I may have to go off another direction. And I don't know what that direction is. And so you can start to have those conversations with your users. I've had cases where I've been talking to, for example, the sales team about their contact process. And they give me this list of the listed processes that they already have. And everybody is following them and they know that's the way they're supposed to do it. And when I drew it out into a business process model, it was very clear that there were decision points that weren't documented. And it meant that if a sales person was on a call and they got to that point in the process, they wouldn't know what to do with it. And because it was written out in words, it wasn't clear where the process flow went. And so we were able to go and say, oh, well, in the case of maybe it's all right, so I just got off the call with a customer, let me jot down this information that I collected. Well, what if I didn't collect any information? And they're like, well, I don't know. We hadn't really thought about that. And I'm like, okay, so does that mean that they go back and set up another call? Does that mean what happens if they got a voicemail? What's the process in that case? And they're like, oh, I hadn't really thought about that. And I hadn't really made a decision about that. And by drawing out your business processes in this flow, it makes it really easy to quickly catch those points where it's like, wait, here was a decision, but you only told me one half of the decision. Does that help to explain it? If not, please ask another question. Thank you. So moving on to the next question, we'll see if the original questioner has additional questions. Have you had experience creating a detailed conceptual data model as a guideline for the enterprise? If so, how was it received and used? Yeah. So the idea of business architect product does both the business process models and the conceptual models. And I have worked with people on projects where they do draw out the full conceptual model. It has all of the business entities and the business elements and everything else in it. And we got down to the full entity conversation. We broke them up into chunks of functionality. I don't have an example of this presentation where we covered that. I don't think I even have a conceptual model in here. I guess I could kind of talk from 51 where you start to kind of group them out and you can create your big old bubbles, your subject areas and talk them through and start to create those and say, okay, so these are my tables that I plan. These are the entities that I plan. This is what I intend to call them. Sometimes what's in the data is not the same as what's in the application. But being able to really have those conversations and draw them out and let them come out. I'm sorry that I don't have an example right here, but certainly you can start to really find them down and with our product you can take those conceptual models and take the data elements that you've created and dump them directly into our data modeling product, your studio data architect. So you put forth a very interesting approach to having a conversation with your business customer. Have you gone deeper using IDEF1 or OV-5V type of data modeling? I have not. Those terms are not something that I'm aware of. I could probably do a really quick Google search on it, but it doesn't mean that we don't cover it. I'm not familiar with those terms. Hopefully I even pronounced them correctly. I do apologize. I am not on mission. I'm not all-knowing. Certainly if you'd like to tweet that to me, I can certainly go and research it and I can get back to you with an answer after the fact. My Twitter is brushsaber underscore I dare. If you want to tweet it to me, I'll go look it up and I'll find out for you. What modeling notations, for example, does ER studio support? Can you convert or link a BPMN model to a UML model? Can the model be linked to and from metadata repositories and development tools? We have another product that's called software architect that does UML modeling. It's not tied directly into business architect, which does the business process models, but certainly you can make the transition. Sadly you're going to have to redraw it. We do allow imports in from Visio from the business process model. So if you wanted to create a UML model and convert it over to a business process model in Visio and then dump it into business architect, we could certainly start from that direction. But I don't really think of I'm trying to think of how I would go from the UML model and the use cases, I guess, it just translates. That's an interesting question. I may see about a way to be able to do that more in the future, where we take the tasks from the UML notation and put them into tasks in business process modeling and then take all the actors from the UML and drop them in as stewards. We don't currently do that, but that is interesting. There was a second half to that question beyond I just started thinking about the UML half. What is the other second part of that, Shannon? Yes. Can the model be linked to and from metadata repositories and development tools? Yes. So we do business architect does allow, if you have enterprise team addition, we have a team server product that is a repository that holds both the business architect models as well as the data architect models. You can link all of those elements together to terms or to each other. You can definitely relate them that way. Like I said, whenever you create these, go back to this page, whenever you create your data objects in business architect, you can import those over to data architect as well and be able to use it that way. Now we do collect some properties and some information, but we don't have nearly the metadata that the data architect tool has available. Data architect goes into some extreme level of detail in regards to the metadata. And the questioner on the acronyms before explains that IDF-0 and IDF-1 were defined by the United States Air Force and those are compound acronyms for ICAM definition for function modeling. So we are learning things. Thank you. I haven't really dug as much. I spent a lot of my time, obviously spent a lot of my time in business process world. I spent a lot of my time in compliance world. That's why I'm able to rattle off a lot of compliance stuff off the top of my head. But I haven't been dealing with as many of the military compliance elements at this point in time. So again, I would encourage you to send me a Twitter message and I'll be happy to circulate it around to all the other people on how we relate. So Kim, what tool are you using for data lineage? So on one sense, it depends on how you define data lineage. So in this case, in the case of this presentation, it was really focusing on business process models and where you can use the process models to understand how the data is going to flow through the product. But again, the data architect tool is the tool that has pretty extreme data lineage modeling capabilities in it. And that's one of my counterparts that's responsible for that product. So you would be able to go much into greater detail about that. But we do have much more in detail data lineage mapping that goes on in data architect. Can you confirm if data architect works with the business architect? These two products don't work with each other? They do. We hope to have them work even more on an instant basis. But right now, you can take any of the data elements and move them from business architect into data architect. You can also take any of the data elements that are in data architect and import them into business architect. And additionally, like I said, there's the team server element that allows you to link these items together a lot better. We do anticipate down the road making that even more seamless, make it more real-time updates. At the moment, it's an import and export process. But certainly, that's a request that's come in from a lot of people to be able to have them work more seamlessly. So what do you find is the best way to get full buy-in and understanding of the necessity and benefits of data governance to senior leadership? I mean, we get this question a lot, Kim. It's something that I know a lot of our community struggles with. Yeah, I think that the business team looks at things obviously a lot different than the data team. And that's why in talking to you guys right now, you're mostly data focused. And so you look at all this and you go, well, yeah, that's a no brainer. Those are the kinds of questions that I know I should be asking. And those are the kinds of things that needs to come out of it. But in talking to the business users and the executive team, they really like to look at things at a much higher level. And so that's where these business processes can come in and be really helpful. Because you can take it up and take it out of the details and start to get them to really focus in on the questions that you need to have answered. Additionally, I find that working with the business teams, they deal a lot in one of two directions. One being ROI. How is this going to change the bottom line figures in what I'm trying to get to? The other one being in pain points. And understanding, okay, if we don't do this, then these problems are going to occur. So when you look at, let me go back to the slide that has all of the elements on it. So your business teams probably aren't going to care that much about defining your data, especially not at the executive level. At the individual level, if they're responsible for certain things, then they would think it's really important to define this is now the product needs to work and this is the data I need to collect from it. But at the higher level, they're probably not going to care too much about how you define it. They're going to just say make it work. Modeling your data, again, this is going to be something that's going to be more at a lower level decision maker instead of the high level executive team. But when you get into ensuring the quality of your data, that is a conversation that you can easily have with your executive team and your business users. Because if you aren't getting a lot of us when we step into these technical roles, we are adopting technology from somebody else that's written it, or we've been hired in and we don't have any control over it, or a company is merged together with us and the data is just crazy and people are like, oh, just make it work. And you're like, okay, but I can make it work, but that doesn't mean that the quality is there. And so I think that you definitely can have the executive conversations on when is my data considered inaccurate or when is my data just plain wrong? And how do we define what we're going to fix when? Because whenever you're working with any kind of project, you have to be able to justify, okay, I need to be changing this now and not this later. And those of us who do get into the technical details and we love the data, we are, we're bothered by the fact that our data is not of the highest quality. And we're constantly fighting and we found a little bit like chicken little because we keep coming up with all of these places where the data is wrong or there's bugs in the product that are causing problems and making data inconsistent or it's stored one place and not another. I mean, even from the basic of I was working in JIRA the other day and all of a sudden the second resolution field came and popped up and I'm like, wait, wait, there's only one resolution to an issue. Why do I have two of these and that's going to get out of whack really quick and we need to fix that and repair that. And so quality of your data can definitely impact your bottom line. It can impact your customers. People can get pretty upset when your data quality is poor. So that's a pretty easy conversation to have with your business users. Tracking your data, maybe they don't care as much about on the executive side, certainly the business side they do. They want to know how many hands does the data go through. Knowing who's accessing your data. Again, your executive team is going to be like, well, I don't know. You guys just take care of it and that's why we have a security team. So the executive teams aren't going to care as much about the protecting your data. Certainly in the case of data breach, they're going to care because of the high press that data breaches get because of the implications that GDPR is going to have surrounding data breach because of the financial aspects of data. Actually, I'll take back the accessing your data because of the security elements that go along with who's accessing your data. That's really important as well to executives and there's a lot who are trying to answer that question. They're like, I keep throwing money at this problem but it doesn't go away. So there's a lot of money in knowing who's accessing your data, protecting your data, and then meeting those regulatory guidelines as those come out and making sure that the data is there. So three of these elements are going to be really hard to have the business conversation and especially at the executive level, four of these are going to be really easy to address. So I think that you kind of have to pick your battles and maybe you can blend in some of that that says, oh, well, you know, my data quality is poor because my data is not accurately defined and so you may be able to kind of squeeze in some of these other data governance elements in the conversations that the business is interested in. Well, Kim, that's all the questions we have for right now. Let me just see if we've got any others coming in. Give everyone just a quick moment. And again, just a reminder, I will be sending a follow-up email by end of day Thursday for this webinar with links to the slides and links to the recording. Everyone's quiet today. I think the sun may be out everywhere, Kim. Well, I did give people a little extra time. Normally, I only give about 15, 20 minutes at the end. So I thought that there might be a lot more questions on this. So I gave people some extra time with it. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. And I'll just give you some extra time with it today. Well, Naye, it's been great, Kim, and thank you so much for another fantastic presentation and thank you for all this information. And thanks to our attendees for attending and for being engaged with the questions that we did have. I hope everyone will give you awesome a few minutes back, which enables you to be on time for your next meeting, which I sure know that some people will appreciate. So thank you, Kim. Thank you, Kim. Thank you, everybody. Have a great day. All right. Thank you.