 My name is Kim Wines Earl. I was the Chief Data Officer for the State of Tennessee when we put this together and started this program. I'm currently the Director of Data at Radio Systems Corporation. For those of you I haven't talked to yet, who knows what that is? You probably know it as invisible fence, pet safe, curgo, sport dog, premier pet. So my badge picture has my dog Fender on it. Very pet friendly company. Prior to that, like I said, I was Chief Data Officer at State of Tennessee. Prior to that I was Assistant Vice President at a regional insurance company called Pecan Insurance in Central Illinois. Before that I worked decades at Caterpillar again in Central Illinois. Leaving there as the Enterprise Information Management Division Manager. What we're going to share with you today, I have deployed the same framework for data governance. All these companies, global, all these industries, all different sizes. So, Amber? Hello, my name is Amber O'Connell. I'm the Director of Data Governance for the State of Tennessee. I've been doing that for almost four years to the day, like next week or something. Before that I was the State's first Enterprise Data Scientist. I also have my Masters in Statistics. So definitely a data nerd. Super duper loved data. Love being here. If you have any questions as we go through, please ask. I learned last night that we both have some hearing deficiencies. So if you could ask really loud, that'd be super cool too. So the slide about our company, we are a State of Tennessee. So as you might imagine, like other very, very large companies, everyone works in a silo. It's just our silos all have different initiatives, different budgets. The only thing in common really is the citizens and the governor. Tennessee is very dedicated to doing everything to help their citizens. In the data strategy, the data initiatives that they're working on, it's really to get the funds and the services to the citizens as quickly as they can. Believe it or not, it is very, very hard for States to find the right people to give the right money or services to at the right time. So these 38 different agencies here, we've worked with all of them practically, and they are all like a totally different company. There's our governor, Billy, very engaged in what we're working on. So we call it the eight elements of data governance. Like I said, this is a framework I put together about a decade ago and actually in October just published a book on it. The reason I did that is Amber and I, due to COVID, have presented this at about a dozen different webinars in the last year or two. And it seems like it always ends with people saying, how do I learn more? I want to learn more about it. So we have what we call the guidebook and the playbook, which is our own instructions for how to do this. I basically just published it for anyone to use. Just like you've heard in several sessions today, as have I, this isn't something new. This isn't a new job responsibility. In the words of Bob Siner, chances are you're already doing a lot of this informally. What's nice about this framework is it gives you almost a checklist to say, if I'm doing these things, I'm doing data governance. So it lines up what you're already doing. It identifies the gaps if you're not doing everything. And just gets you to that point to where whatever you're working on is auditable, whether it's from your data owner, from your internal audit department, external auditors, regulators. If you are working through this framework, you're always keep yourself at a point of being auditable. So when an auditor shows up, you don't have that little mini project where 20 people are quickly gathering evidence and documentation, data, you're always ready to go. This framework is built for reuse and completeness. So you can start small, start in one department, replicate it, which is what Amber is doing at the state. We started with the Department of Human Services, now replicating across each one of those agencies. And again, it's that completeness check to make sure you're doing it from end to end. And when you say you're doing it, everyone understands what you mean by that. So I've got eight slides here. Each one is going to cover one of the eight boxes. Amber and I are going to switch off and on between who's covering each one. Box number one is organization. Say this in the book. I've heard it a half a dozen times since I've been here this week. If you don't have people behind this and support behind this, it's not going to go anywhere. Or if it does, you're going to end up redoing it. So I pretty much, I'm of the opinion after doing this for several decades now, if you don't have that executive leadership and if you don't have data owners defined like don't start, go find those people before you attempt it. If you work it on your own, when those people do finally come into your life, they're going to change it and you're never going to get those benefits. So just my advice, but that's what this box is all about. Like what is the scope of the data that you are going to put under data governance? Very succinctly define what that is so you don't get it too big and it takes forever. Assign that ownership. Owners, stewards, if you have people that are going to fulfill those data roles. Again, unless you're a very large company, those usually aren't dedicated roles. That's just a smart goal on somebody's annual performance review. Define the business value, the uses for that data, and start building that plan for how you're going to operationalize it. Each one of these slides is kind of built the same. It shows some suggested inputs into that step and it shows some suggested outputs from that particular step and then any tools or templates that you might be interested in using. So in this particular one organization, if you already have a data governance operating model, it's a really good place to have that come in to here as well as if you've got a data strategy already put together. And then those outputs are going to be the roles, the committees, the functions. Who has decision rights for your scope of data that you're going under governance? Who's the producers? Who's the consumers? Because they're going to have a part to play in this. What are those high level business needs? Any action plans that you may put in place could be something like hey, go create your governance committee. And then what is your process for engagement going to be? Tools and templates, org charts are very helpful here. The responsibility chart are RACES. And like I said before, have those SMART goals drafted to some degree for the folks that are going to be in these data roles so they know what you're asking them to do. Alright, so the second element of data governance is all around policies. So good policies are going to be the foundation for any data governance program. I find at least in government you can't do anything without a policy behind it. So the goal of data policy is generally to provide guidance on how we manage data through its entire life cycle. Some inputs to consider for your data policy might be terms and definitions if you have them, data naming standards if you have them, business rules, quality standards if you have them, and information security concerns, you should probably have those. A data policy may also authorize and define your data governance program, your committee, and any specific roles like your data owners and your stewards, you're probably going to want to define what those are and what those responsibilities are in your policy. Generally there are five key focus areas for data policy development. You want to worry about authoring, which is the when, how, and by whom. Data may be created, changed, or deleted. Access, which people or systems are authorized to see and get the data. Usaged, what are the actual authorized uses for the data and how are they mapped back to those authorized users. Maintenance, how the data is maintained in the source system and backed up for recovery. And then retention, how long must the data be kept, in what format, and any defined lead times for recovery. The level of policy definition required will vary depending on the business value of the data and the associated risk identified by the data owner. This basically means that public data, you're not going to have a whole lot of policy around it. You might have a definition, hey, this is public data and anybody can see it. Versus if you've got HIPAA or PCI data, you're going to have a lot of policy around it. This is exactly who can get it and why and when they have to give it back and all of that kind of stuff. A useful template for this phase could be a policy template if your organization has one. One thing, just to tie this, Monday, if you went to Jim Johnson's presentation, he has a really good slide on all the possible data policies. So when you're trying to connect what you're doing with what's already been done, if you're starting a new strategy, really good checklist of which data policies, do I think I should have and which ones might be missing? Did you have a question? Sorry. Policies is an area I'm struggling with since I work for a state transportation agency. Okay. And that's one of your 38. Yes. But the breadth of our data is expansive within that realm. How do you approach or how do you recommend approaching the policies? I mean you're trying to write a policy at the state level to cover 38 agencies and you just like to mention the type of data, the types of data, how it's collected, how it's used and everything else, how do you write use of JAXS and all that. It seems like it has to be relatively generic. And do the agencies that tease off of that and expand? Yeah. I'll answer first. I'll let Amber answer. But yeah. So you're going to have that generic one, policies like the law. This is what we're going to do around data privacy, data retention, data classification, you know, at the state level. But then if you have like human services or health? Yeah. So definitely we have those enterprise policies that are really, really generic. And then we also leave it open to individual departments write their own policies. And so they can follow their own policy template that they have and go down to the granularity that they need. Like our health department, they have different data policies depending on what data source you're talking about. And that works for them and that's fine. As long as it's all documented and it's all points back to your original umbrella enterprise policy. So each of those areas, you might tease into one of those rounds of your policies and have multiple iterations while you have this data and that data and that data and use your access or use or whatever. And so they actually, it really accordions up. It can. It absolutely can. Yeah. So probably a good time for me to circle back around to this guidebook versus this playbook. If you think of the playbook, the playbook is a big three-ring binder. And what you're going to do is every time you work through one of these boxes, you're going to create artifacts or find them. You're going to document them. You're going to link to them. That goes in that playbook. That's your binder. So when you get to these situations where things are starting to accordion out, it doesn't get so complicated because you're documenting it as you go. And you're showing what those relationships are. Any other questions on organization or policies? Okay. So behind every good policy, there's one or more procedures. You know, policies are the law. Procedures are the how-tos behind it and who plays those parts. So probably going to use a template that you already have at your companies or entities to build these. Inputs into it are going to be those policies either at the enterprise level or specific to your data policies or your particular set of data you're working on. And then outputs are going to be those procedures, the rules, who works on them, the standard worker instructions behind it. Some examples that we've done in the past, a simple Visio process swim lane chart showing who does what when and what order. Again, the race comes through with this one as well. The fourth element of data governance is all around implementing standards and definitions. Definitions and standards are the guidelines that are going to inform how we design data solutions, interpret information, evaluate performance, and ensure quality for our data from source to consumer. So the goals of this phase are that definitions and standards are documented for all required fields, all critical fields of your data set, and that official sources of data are identified. What are official sources? Different people have different definitions, but probably in your department there are 17 different sources of address in your organization. Which one do you trust most? Which one is verified? Which one do you refer back to? That's your official source of where the address data element lives. And then definitions literally describe the meaning of a data element in a way that's readily understood by consumers. So no IT jargon or business jargon, no cheeseburger definitions. Oh, a cheeseburger is a burger with cheese. If you get readily understood, I'm a human, I can read this and understand what this means. Standards are the documented specifications for those specific data elements or sub-elements. Standards can be derived from data models, data schemas, naming rules, and business rules. Standards may include valid values and acceptable ranges, like a phone number has to be nine digits or acceptable ranges. Age is usually between zero and 100. Specific formatting rules, if you've got a date, has to be in this exact format. Minimum data quality levels, you should always have, you know, 93% of the time you should have a zip code filled in. Any required fields, make sure that you understand which ones those are, those official sources of data that I talked about, and then of course any formulas for creating derived data. You might have an annual federal report that you have to do every year. You want to make sure you're using that exact same formula each year that you report back to the federal government. Standards and definitions should be housed in a data dictionary. This work is typically performed by a data steward and then reviewed by that data owner. Useful templates might be a business glossary, a data dictionary, a metadata repository, and data models. There are tons of tools out there to help you with this step. It's still a really, really big step. Box five is architecture. This box is split down the middle. So you've got your technology architecture. So your data flow diagrams, your data models, your reference architecture diagrams, all of that you want to capture, document, link to here. If you don't have those things, you know, it becomes a task item list in your playbook for someone to go create those because you're going to need those to be able to treat this data as an asset long after you're gone for others to understand it and be able to work with it. The other half of this box is the business architecture. So what are those business process flows where this data is flowing through? So where does it originate? Who touches it? Who does what to it? And, you know, so drawing those process maps or those value stream maps on the business side. Some potential inputs into this. Again, you're going to know who's responsible for what. So roles responsibilities come into this box as well. Who are the not-productors? Who are the producers and the consumers of the data? That'll help with your business process modeling. High-level, again, that high-level business need. Why do we even have this data? What purpose is it serving here at the state of Tennessee? Standard methodologies and tools. So anything from box four might come in here. If you've got coding standards or naming standards, naming conventions, they should be applied here. Data modeling standards or guidelines could also be inputs. So like I said, your outputs could be data models, data flow diagrams. This might be a good point in time to identify your key or critical data fields. If you think about creating a data catalog, so back in box four, hey, we're going to create a business glossary. Oh, well, our ERP system has, you know, 5,500 data elements. Are we going to sit down and do that for all of that? No, this is where you would identify what are those key or critical data elements that we want to be focusing on for this pass. Potential tools and templates, again, process swim lane maps are really nice for business process modeling, data model templates, data flow diagrams, reference architecture diagram templates would be helpful here. The sixth element of data governance is data administration and controls. That is that tie back into enterprise security. So this phase defines who can and can't have access to what data for what reasons, can create data, how often where the data is backed up, how the data should be classified for confidentiality, what the retention period is, how the data is deleted or deactivated, when and how the data might be encrypted or masked, what the disaster recovery plan is, and specifics around any other internal or external controls. You notice a lot of what I just said, I said earlier in policies because usually your enterprise security defines exactly what's in your policies and vice versa as well. So the goals of this phase generally include developing a risk management strategy. Again, this is going to vary depending on what type of data you're talking about. If you've got public data, you have almost no risk. You probably don't even need a risk management strategy. If you've got HIPAA data or CGIS data, you've got a lot of risk. So you're going to want a significantly more lengthy risk management strategy. You're going to make sure you're aligning your data back to the controls you identified, and then you're developing procedures for managing that entire life cycle of the data. So during this phase, the data owner and steward are going to determine what governance processes are required to ensure that the data meets the business requirements and those security policies. This is that idea that governance is not the red tape. Governance is how you open the door. Because let's be honest, if we left it up to enterprise security, they would put all of our data in a very locked box and they would never let anybody access it ever. Because then there'd be no risk, right? But in real life, the data needs to be valued. We want to use it. And so how do we make those access paths? How do we carve away into that locked box that is following procedures and is following the rules, but still allows us access to use the data the way we need to? Seven, metrics and reporting. This is not the metrics and reporting you do with the data. This is your data quality metrics. So if you're going to put data under governance, is that important? You probably want to measure its fit for use level. So this box is all about understanding what's important to keep this data certified, clean to use for whatever the purpose is. So you don't want to have 35 metrics against it. You want a handful of them and hopefully over time some of those start dropping away. For example, maybe you have a file and it's got zip codes on it. And right now, 20% of the zip codes are invalid or missing. Over time, you probably want to fix that. So maybe that metric goes away and something else takes its place or just simply goes away. So coming into this particular box is going to be everything we've already talked about. The policies, procedure, standards and any established controls or controls that you create. And then that output is going to be hopefully some automated means to measure that data quality, continuously profile that data and then alert people if it reaches a, hey, I'm not fit for use type level. So there is a good probably two dozen ways that you can measure your data quality levels. This particular framework, we have one, we call it a TAC. Even though it's spelled wrong, it's A-T-A-C-C. These are the five that I use, I start with every place I go because these are fairly easy to work through. Not overly complicated and are usually the big hitters. You're going to run into this in almost every data set and they're there in the lower right. Is my data accurate? Is it timely? Meaning it's in the right time frame. I don't have to jump through hoops and massage it into the right time frame I need and do I get it when I need it each day or week or month? Is it accessible to me or do I always have to ask somebody else or do I have to, again, jump through hoops to try to even get to it? And is it complete and is it consistent with other data that should be or that's important to me? So our templates and tools for this would be some type of a format for your data quality metrics definition whether that's some kind of a chart, a gauge, a report, however you're going to do that. You're going to want to document what your corrective action is. So let's say my zip codes go from 20% bad to not 25. There needs to be some kind of trigger going to pull for action to be taken to correct that. So each one of the metrics, again, another reason why you don't want to have too many, each metric is going to have to have that remediation plan behind it. Those control charts to see where your data quality levels are and possibly potentially data audit template because that's one thing when we hit the next box, which is audit, first thing audit's going to look at is where you are with your data quality level. All right, so the final box, final element of data governance is audits. And I think this is the one that kind of separates our framework from maybe some others that you've seen because we really think it's important that your data governance framework is self-audible as well as fully prepared for any external audits. I can't remember if it was yesterday or today, but some guys, he's like, yeah, I talk to internal audit all the time. They're kind of my best friend. I need to work with them and I need to have a really good working relationship with them. And that's kind of what we are. We really, we help their jobs better and we make sure that everything's doing the right things the right way. So the process behind the A elements, everything that we've just talked about is fully documented and everything in one place. I like to think about everything in a big three ring binder. So all of your organization, all of your people, your policies, your processes, your definitions, your architecture diagrams, everything you have in a giant three ring binder for every single data source that it lives on your desk. Okay, it doesn't. It's not a physical file. It's on your desktop or it's on your SharePoint or wherever you put your documentation, but it's all kind of in one place so that when you need it, when audit asks, hey, who has access to your data? You can flip to that page and hand them that page or where's your data going? What's your data flow diagram look like? You can easily find it and it's easily findable. So the purpose of an internal audit is to set up that regularly scheduled audit so that you know that data governance processes are being used, data policies are being enforced and that data quality metrics are being used towards impactful action. Because to Kim's point, if you're measuring something but you're not doing anything about it, then why are you bothering to measure it? Just throw it out. So the goals of this phase include working, actually working through a self audit, documenting any gaps that you may have found in your governance process, reporting back the results to your governance people and then setting up that self audit schedule. Typically the data owner determines what needs to be audited and what that schedule should be. I recommend to them once a year, it's probably a good schedule to start with. If you find you have too many things to deal with, okay, maybe six months or actually I don't need to audit this data very often, maybe two years is more appropriate. And then the data owner themselves is responsible for performing the audit and reporting back those results. This sounds really weird, but it works. And it works because I find that it really kind of removes the curtain from having data owners have more knowledge and more ownership about the data and the processes that they're responsible for. Because it can be really off-putting when you assign a data owner and say, okay, now you're in charge of this and you give them a list of responsibilities and they're gonna go, wait, what are we talking about? I don't use this. This is so-and-so's job. Isn't that IT's problem? And so when you train them and you tell them what's going on and then they actually walk through that audit process, they have a better understanding of what their data is used for, what their stewards are doing with it, how people get access to it, and maybe why they need to authorize or approve different steps in that governance process. So useful templates and tools might be a maturity assessment of template. This is something I recommend they go through when they go through their audit. Hey, you guys, a more mature data organization than you were a year ago. We use the federal template. It's really colorful and great. Totally recommend. All the data governance document, that big three-ring binder that we talked about, evidence storage for, you know, audit purposes, where are you putting all that stuff, and then that actual self-audit checklist, which we do provide to people. All right, so now you all know about the eight elements of data governance. A couple pictures here, the playbook. That's the playbook that we wrote for State of Tennessee. It's about, I don't know, 40 pages, 60 pages long maybe. That describes why you're, you know, behind each one of these eight. Why are you doing it? Who should be doing it? What the end result is? Any tips and hints? Any templates? And then the playbook, not only captures your end results and turns into that three-ring binder, but it also has a dozen or so questions for each one of these eight boxes, these eight elements. So if you're like, I don't know where to start. You know, the playbook's gonna say, okay, you're in box one, you're working on organization. Who's the data owner? Oh, I don't have one. Okay, well that spins up your task list of things to do. So there's a dozen or so questions behind each one of these boxes. And if your program does nothing but addresses playbook like you are, in fact, doing data governance, and everyone will have a good understanding of how you're doing it. So like I said, we piloted this for the state of Tennessee for Department of Human Services. We took a very small scope. It was basically one data set. But we have examples here of the project plan that we used, status report that we used with the executive sponsor and the data owner to show progress. This particular data set that we put under governance, you'll see it on the next slide, but I don't know, I think we spent like 80 hours. And Amber and I had hired a consultant to come in and do it. It didn't work out. So like, we did it as part-time jobs ourselves, which was good because it solidified and validated that this process works. So we worked seven weeks. These are the, you know, examples of the tasks that we did. We basically, some of the boxes you can work at the same time. You want to do owner first. Make sure you got that nailed down as well as your scope. But some of the other discovery stuff, like, gosh, what architectural diagrams or documentation do we already have? All of that can work in parallel. This is how we reported status. We've got the eight elements there. We would talk about what tasks we completed, which ones are coming up next. They wanted to know how much time we spent, so we kept track of our hours. If we had any issues that we wanted to call out, and then if we had anything to showcase, so what we would do when we had enough artifacts or work to showcase, we'd have a 15-minute meeting and we'd play it back to all of the owners and stewards in the organization, because once we got this first data set under governance, everybody else in the Department of Human Services that we trained, they were going to replicate it on their own. So they basically got to witness a data set live going under data governance, so they had a better understanding of what it would mean for them to do it themselves. Professor? Yeah, so this is the actual completed example that we had for DHS, and so we have a template that basically you just put all the inputs of all the eight boxes that we talked about, so it's got, okay, what's your scope? Who's in the organization? Who's the actual owners? What are all your policies? What are all your procedures? Everything's just kind of documented in this one document that's really easy for people to get to. And it doesn't have to be here. Like you can say, oh, okay, it lists out all my policies, but it doesn't actually have the policy in it. It just points to where the policy lives. And this is just more, more policies, more procedures. Yeah, look at all those policies. Lots of policies. So you can see, I think this one had like 22 or 23 policies on it just for the Department of DHS, and yeah, that sounds like a lot, but that's probably how many you need. You might need more, you might need less, just kind of depending. But one thing that came out of this, you know, as we went on our discovery mission to find all these policies, I mean, some of them are old. So again, that goes on the task list. Outside of that seven-week effort, guys, this policy is from 2014. Is it still valid? Like somebody needs a look at this. So it helps you, helps you build the work list as well. Key takeaways. So this is, we also ran this as a pilot for our P20 system. If anybody knows what that is for a government, it's a state longitudinal, educational student database, data something. Anyhow, it's where the states track all the information about students in the educational systems. So our first four key takeaways, our lessons learned is from that, and the last one is from what we did with Department of Human Services. But the first one that they found was, again, make sure you have the right people involved. They went through and like, okay, yeah, we're going to identify all of our data owners and stewards, because this data set is a culmination out of six different departments. But what they found out was as they started having to do stuff and make decisions, they weren't the right people. So people were leaving, owners were leaving, new owners were coming in. But it was very important to have that sponsorship, have those people in place and trained so they know what it is their role's going to be. The second one is that I'm only one person. I'm a team of one. I'm the director of data governance for the entire state of Tennessee. Therefore, I'm the only person that does data governance 100% of the time. Everybody else that I work with has a different day job that's not data governance. And so it's understanding that and respecting their work to do limited capacity worth of data governance. So generally what I found is that I chunked up the work for them. You can't just hand them a giant business glossary with 50 terms and throw it over the fence and say, okay, define all these terms and get back to me. Let me know if you have any questions. You're literally never going to get that document back ever. What you might do is pick out five and say, okay, define these five. Get back to me in a week. That might work better. In my experience, it did. And so chunking up weekly assignments of what you wanted them to do was better because that way you either got back the assignment that you asked for or you didn't. And then you could follow up more quickly and be like, hey, do you need help? Do I need to talk to your boss? Do I need to reallocate? What is happening? Are you not the right person? Why am I not getting the response back that I expected? Third one, it kind of goes back to the first one. Have that executive buy-in. If you cannot get smart goals or however you assign work to folks, if you can't get it on their radar, it's not going to move. At least that's been our experience. So it's very, very nice when you've got folks at high levels that are saying, this is important to us. And in order for us to move the needle forward on being able to use our data to get to insights and make decisions quicker and for the state of Tennessee to get the right services and offerings to the right people at the right time, this is what we need to do as a precursor to be able to get to that. So you need to have, in our case, I mean, the governor would mention it, but we had probably 20 commissioners that were highly engaged with what we were doing. So look for that when you're doing it. Yeah, in my experience, if you don't have executive buy-in, stop. You're going to circle forever. You're not going to get anything done, find a different job. I don't know. But in my experience, you really need that executive buy-in. And then the last one, this was like Kim said, the first three we learned kind of on our first pilot and then in the second pilot, we trained all the people that we identified. So it wasn't just, okay, you're a set of data owners and you're a set of data stewards. We actually brought in all of our owners and trained them on what that meant, trained them on how to do that audit that I talked about. The same thing with the stewards. We brought in all the stewards and various, I mean, we couldn't do everybody at one time, but we brought in all the stewards and trained them. Okay, you guys are going to be responsible for setting up standards and defining these terms and helping us work with IT. How do you get access to that kind of stuff? Where are your processes? So training it was really, really a good thing. That's it. What questions do you have? Yes, sir. Hi. Thanks for the presentation. Yes. So when you take away one, you sort of like a three-year-old that we're trying to communicate with, where a data owner is steward and data custodian. So rules and responsibility-wise, what is the difference between the steward and the custodian? Yeah, so between the owner and the steward? Steward. Steward and custodian? Yes. Okay, so the question is, what's the difference between the data steward and the data custodian? It depends on how you want to define it. For the state of Tennessee, the stewards are really typically the business folks that are in the know. Business people have their finger on the keyboard. They're using this data. They're the gurus. People come to them, ask them questions about this data. The custodians, for state of Tennessee, a lot of times that was like the IT folks behind it that maybe go in and understand the business logic because it's not written down anywhere but in code. That could be a custodian. Or it could actually be still a business person, but it's somebody that unfortunately might be on a manual task to do data cleanup until we can get the quality level to the level that we want. You have a different? No, that's exactly right. Some organizations call them technical data stewards instead of custodians if they like that better. And then who is the data owner? Isn't he or she also from the business? Go ahead. Yeah, yeah. So normally owners are going to be executives. They're the ones that have authority about what happens with the data. Whereas stewards are more hands-on. They're the ones maybe during reporting or the ones that are actually doing something with the data, day to day basis. Whereas the owners really have that authority over what happens to the data. Should it leave our organization? Should we update it, that kind of thing? And back. Is the label that you created for the state, is that public? Is what? Is it public? It is. We didn't put it on here. I've got the template out there on a website that's in the back of the book. But yeah, I come up here and I'll show you it. Wordified it. TN.gov, it's on there somewhere. The name of the book is the data governance guidebook and playbook. It come out in August. And it's basically, it is the guidebook and the playbook put together. Any questions? Is there one over here? No? Go ahead, sir. As the state CEO, how was, what was your interaction with the CIO? How did you, what was the relationship between the data office and the technology office? Yeah, so I reported to the deputy CIO who reported to the CIO. So I was not, I was twice removed from being able to get to the state cabinet. But had I stayed there longer, that was my goal, was to be able to have a voice in the cabinet sessions to share what we're working on, why we're doing it, why it's important, because that's where you gain that executive buy-in. So your CIO sat on the cabinet? No, but they had, she had an audience with them. Okay, through their administrator? Yeah. Administration or whatever. Finance and administration, yep. Other questions? Okay, well I appreciate you all coming. Yeah, thank you.