 My name is Shannon Kemp, and I am the executive editor for Data Diversity. We would like to thank you for joining today's Data Diversity webinar. Big John is in data modeling. Of course, data modeling is hard, but maybe. This series is moderated by the esteemed Karen Lopez. Just a couple of points to get us started. Here's a large number of people that attend these sessions. You will be muted during the webinar. For questions, we'll be collecting them via the Q&A section. Or if you like to tweet, we encourage you to share highlights or questions via Twitter using hashtag BCDModeling. Big challenges in data modeling. Joining us today are two great panelists, Thomas LaRocque, a.k.a. Sequel Rockstar and Jolene Jo. Thomas is a seasoned IT professional with over a decade of technical and management experience. Serving as a technical evangelist for Confio Software, Thomas has progressed through several roles in his career, including program or analyst and DBA. Thomas holds an MS degree in mathematics from Washington State University as a member of the Usability Professionals Association. Thomas currently serves on the Board of Directors for the Professional Association for Sequel Server PAS, and is a Sequel Server MCM as well as MVP. Thomas can also be found blogging at ThomasLaRocque.com and is the author of DBA Survivor Become a Rockstar DBA. Jolene is the senior database analyst at the Florida Department of Transportation Office of Information Services. She started out as a programmer, basic, Fortran, Pascal Troll, C.O.B.O.L., and several others, scripts to packages, loads and unloads. She's been a database administrator for several companies, and Jolene says she will model for food, and we're very excited as Jolene has been an attendee in many of our webinars and is the first attendee that we've invited to join our panel as we've just enjoyed her chat so much. And with that, I will turn the session over to Karen to get us started. Hello and welcome. Hi, Jolene. How are you? Where are you from? It's from Portland. Oh, Portland. It's Portland. What else? And your marvelous is always. And I want to thank Dave first for hosting this event. We couldn't talk about you, and I want to thank all the attendees. You know that I consider all of you, all panelists as well. And in that, what I mean is, if you look to the WebEx screen, you are free to chat amongst each other, and we try to keep an eye on the great conversations that happen there. If you have a question for the panel or a comment, you can put that into the Q&A section over on the right-hand side near the bottom, and we will try to take those. But again, we try to match all that. And as Shannon said, I'm trying to monitor the stuff that's going on on Twitter, and to see that, I'll have to use the hashtag B-C-D-Muddling. And there's a lot of multitasking, but generally I can handle that. And as a reminder, there are no slides for this. This isn't a presentation. This is a discussion. So that means that what we need to do is listen closely, pay attention to chats, and you don't have to look at a bunch of PowerPoint bullets. So before we get started, though, because we've introduced ourselves, now I want to know who you are, and that means I'm going to go ahead and open up a poll. So C and B vote. If you don't know who you are, or you remember to vote on what you really don't know what your job title is and not necessarily even what your current project role is, I think you are. And when your boss says that, it sounds bad, doesn't it? And let's see. People are still voting along. You've got about 20 more seconds to figure out what your job is and what the heck it is you do around here. Well, maybe. Let's see. WebEx is going to be with two different numbers. There's a lot of chat issue there. So it looks like almost all of you got a chance to tell who you are. You can still see what we have here is about some of you data modelers and architects. That makes sense. Almost half of you. Some of you are business, and 13 percent of you are business analysts or other analysts. About a little 10 percent are DBAs, devs, or other technical people. 4 percent are architects. 6 percent are just others. And 18 percent of you... So another question is, how long have you been actively data modeling? And by data modeling, I mean creating or maintaining data models or let's just be heavily involved in the processes that result in the production of a data model. Sandwich is music for when these are defined. A little countdown thing. You used to do data modeling, but no longer do you do data modeling. Just give how long they... That's a good answer. It's a good approach to figure out how long you've been doing it. Maybe you're in the ones that said, I stopped counting. That's for that. For counting years? Yes. Actually, myself stopped counting at 20. Okay, so let's see. I can share with you the results. So about 27 percent of you, about a quarter of you, zero to two years. 10 percent, three to five years. A little over 10 percent for six to 10. 20 percent of you, 11 to 15. And 14 percent I stopped counting, which I'm just going to pretend is a nice way of saying very experienced, not old people. And 20 percent of you aren't sure, or maybe haven't. Interesting. That's an interesting distribution. If you think about it at first, you look at it three to five years ago, maybe people weren't into data modeling, but now I'm thinking people have years of experience. It's almost like a tager. They figure, I already know it all. They need to attend a webinar to learn more. That's a good point about that. I know we've asked these two questions for a few webinars now, so it'd be interesting. Maybe I should try to back through and figure out, just keep collecting the data to see if maybe there's a correlation between years of experience and the topic, or see if there's any trends. That would be interesting. Good point. So do you have any of those results surprise you? Yeah, the zero years. I'm with Thomas. We talked about this a couple of years ago that suddenly sparked an interest in this when it's apparently been flagging over time. Interesting question. I'd love to hear all your thoughts on that. In the chat. Maybe I want to clear the year of 2012, the year of data, as we started hearing about big data, data breaches, data security, the advent of new database technologies, and if that also means there's been an uptick of people needing to be doing data modeling. Which is surprising too, because it seems like the focus has been more on programmers than on the reading of the data that makes the program work. We've talked about that on some of the other webinars in that I think, though, that the pendulum is swinging back because of the advent of more focus on data. It is less of a focus on software. I just think we got software heavy, and I think the pendulum is coming back. One of the reasons that is is that we've kind of messed up our data. And there's also been some high-profile data issues, whether it's healthcare.gov, and we have the president of the United States talking about data issues and those sort of things. That doesn't always, you know, one of the main reasons of lots of services moving to online has caused more demand for people to try to sort out the data. Thank you for joining us on this. So thank you for the poll. We do have another one coming up later, but now I just want to sort of skip to some of the things. So today's topic was about, you know, of course modeling is hard, but maybe maybe we're making it too hard. So I wanted to talk about how modelers and architects and people who participate in the data modeling and architecture process are using tools and skills and experiences and other resources to meet business requirements and are doing it in the most effective and efficient way. So I invite you to put your questions into the chat as well as into the chat. But I started with a premise that, of course, data modeling is hard, but my question is to start out with is data modeling actually difficult? What do you think, Jolene? I don't think it's especially difficult and I think the difficulty is in figuring out what you have to model and how to put all those pieces together. At least that's my experience in starting out as a modeler, I guess, is that you have to get all the pieces and it's so difficult to drag all the pieces out of people who have them in their heads. One of the sort of mantras that people talk about is it's not the data models, it's the data modeling that's hard. And I think that's true for a lot of requirement solicitation, like being able to get business to participate and decide what their data priorities are or what the rules around data should be and getting that type of support. And to degree, I think that businesses, you know, for example, the pendulum thing, have wanted data fast and have focused a lot on getting the right data faster. I think there's always been an assumption that we're always going to get the right data. So Tom, you're a DBA, you want performance and who cares how good the data is, right? As long as I want it, it is for my phone to not ring. So that's really... I want to be left alone to sleep at night. That's what I want as a DBA. So is there a question still, do you think data modeling is difficult? Yes. Yes. So being a data model, I think data modeling is difficult, right? You can pick up a book. I can have an understanding of how you build an actual model, relational or whatnot. That really isn't difficult. You require their skill, right? There's lots of practice to get very good at it. What the difficult part is, is that academic world, which has no real relationship to the real world, and the real world is this mess. And you see people, they build a system and they put this model into practice and then you find, I don't know, a bank is going to send you a file with this in a particular format, so you're just going to accept that. And what's tough with this are buckets. People, okay, I'd really like this to be, I don't know, bar 100, but now it's got to be bar charm max. Because these other upstream and downstream people don't want to play with it. It's nice to work with me. Real difficult parts come in more often than not. And one more point. I think that's one of the things, and one of my sort of follow-up questions for this is, you know, a lot of, like you said, books and one day courses on how to teach someone to be a data modeler. Joe, what are some of those? Thomas, you're right. You can learn academics of it in a very short period of time, one or two days, and most of that is learning how to use a specific tool to do it. Or when, one day you can figure out, or you can be taught, the function of Erwin and actually use it. But to learn that into this, to listen to a user and say, oh, this is what you're talking about. Again, all the pieces of the puzzle. You're still trying to, I guess you've stuck trying to tame their brainwaves. And that's very hard and correct. The data model is very easy. Maybe the data modeling, in the information you need, is how, Thomas being a DBA, we work very closely, in our group, the DBAs and the DBAs work extremely closely so that we don't have those performance issues. A big thing, I have a blog post camp on dataversity about the separation, where's the line between DBAs and DBAs. But that really helps. And in a lot of cases, in a lot of cases though, the data architects, the data modelers are completely separate from the builders and implementers. They build logical models and they never really directly see the results of their modeling. And they throw those over the wall to the technical teams and the technical teams say, what the hell is this? Someone needs to build a database. Let's go build a database. And me and all the data modelers have gone off to another project. And I've found a very dysfunctional process. And I think that's one thing that makes data modeling hard is not having that sort of end-in process, what I call model-driven development for those things. The other thing is is that I think that most of the courses and books that I've seen, they teach data modeling notation, which is something you know, and they teach data modeling tools, but they don't go a lot into, and they teach normalization. So that's sort of the triangle of teaching data modeling. But they don't have a lot of extensive labs or hands-on experience or showing people the complete and you go from conceptual to logical to physical and you go put data in something and there's no theories about it. I think that's really rare. Would you agree? Yeah. I can't... We have a unique team. We understand this. But I'm wondering if we can go back to ourselves. I'm wondering if our separateness is self-inflicted. A lot of times when I come up with a project, the first thing I try to repair is the fact that it's so separated. And there's a lot of resistance, especially given that the early data modelers have quite a bit of IT experience, which means they have a type of seniority. And maybe the bullpins where we keep our developers and throw pieces at them. You know, it's not a place where the DAs like to hang out or when I have a desk or a pod. And I've seen a lot of resistance that way. So it's kind of the color of data architecture versus all those things. Well, we've heard this by Nature Blinders on and that's good. That's what makes them good. They see the here and the right now. But it's modelers and DBAs. Our responsibility is at a higher level. We can't just focus on what we have on our desk in front of us right now. We understand what you need, but we have to make it fit into the larger picture. That's a great point. And that's actually a good segue into some of the one to talk about, which is people. So Jerry Weinberg, he's a great writer in all kinds of systems and technical and effectiveness things. He says that every problem, every technical problem is actually a people problem. There are technical problems. And it's kind of a technical thing, but I get where he's coming from. Where he talks about people having different points of view styles is sometimes the dysfunctional part. And I know, Tom, you've learned a lot about different points of view and effectiveness of people and collaboration. What do you think about sort of working with people that makes our job so hard? One more point on the subject. Well, it's just a general general. I don't think that's a big surprise. That kind of thing between two people is a difficult thing to do. I also think that you have these motivating factors. What drives the business? What drives, say, a DBA? So the DBA, my focus will be on recovery. If I get recovered your data, I might as well just leave town. That's my number one thing I've got to do. Everything really is secondary. Fiat odds with what the business wants. Not what they need, but what they want. And when I heard Jolene talk about maybe we've done this before, we kind of have because a lot of people really don't want somebody in the room who is really aligned with theirs. So if I'm sitting there reminding you about disasters, it's not, you know, my goal is kind of what you really want. Then I'm just deciding to have two separate meetings, right? Why have the people in the same room? And it's a difficult thing for people together around and say, you know the person I need in the room most is the person most likely to disagree with me. So I would like to understand what their point of view is. If we come to an agreement, then what, you know, should be good for just about everybody else. So the contrary point of view is often the one you want to speak out first, but it's naturally the one that people tend to avoid. Yeah, I'm not going to be told no. Yeah. Yeah. And I think that also, it's a good point, Tom, where several users and they really hate watching IT folks argue with each other, right? And IT people in a team start arguing with each other about the quality of a surrogate key or whether something should be in Varchar or Varchar or whether we should be using SQL or DB2 or Hadoop. Business users don't really have a lot of contribution to that. They feel like it's a big waste of time. And so they start meeting with the technical people separately so they can use their time effectively. But then they're giving IT completely conflicting priorities. So the DBAs and devs. Yes, we need sub-second response time to go massive query and they don't have all the DA people. And the answer is better, dang well, be right, 100% of the time and I need to have my data. I don't have real-time data doing this. And they tell people, yeah, we want the data to be secure, but we want to be able to land without having to worry about a password because passwords are a pain in the butt. And then they have everyone off to try to go do their work. And yet those are kind of conflicting. They're not so much conflicting as they all involve trade-offs and it's hard to do those trade-offs separately. So that brings me to the thing that makes it hard is that we can have some reward systems for management. Okay, so it doesn't work for a government organization. Are there, what performance-related relative to data that might be different than a developer or a DBA is? My criteria is nearly solely subjective. Yeah. Based mostly on how you play with others than the work product. That's an important thing, right? Of course, yes. But the work product and whether or not the database actually works. Can you get data in? Can you get data out? And like Tom says, can you actually save it when you've got to? That part of my job is really not even part of the criteria. And there really is no incentive and there is no bonus. And we do appear reviews, but mostly that's around a table. We're talking to each other. That's true. I mean, there are options for data architects that measured things like data quality or data integrity as well as integration and reuse, you know, but there are options, you know, a developer saying, well, if we have to do that, it'll slow the system down or if we have to do that, it's going to take us six more months instead of the two weeks that I said it was going to take to do something. And so I don't know how a business user would be able to sort out all those things, which is maybe they, you know, fall into just, are you a good team player? But the users don't rate me. Well, yeah, not directly. Maybe not in your organization. So in organizations I've worked at, the business users who are on the projects, the appropriate and those types of peer reviews. We had a revenue. We had a 360 evaluation. And I opened her in so many different ways. Exactly where I used it. And yes, that was a very interesting thing and I really appreciated it. That's where I work now, not so much. And I think if each one of us were, we would have the same thing again. It's not just technology, but it's the people thing. We speak entirely different languages. Business programmers, DA's and D-Bats, we speak entirely different languages and sometimes we need an enderpreter. That's a really good point. And I think that's another thing that's our own on-falls. Like I'm holding us all accountable for that. Many business users get an out because they get to speak their language. But I find that, you know, one of the things in the IIT business is relatively new profession and we are getting very experienced. And I think that we lux and vendors drive our terminology much more than other professions do. It's very difficult to have a productive conversation with other people on our teams, I find, even. The entity means something completely different in the entity framework in the Microsoft world than it does in the data modeling world, than it does in anything else. Right. And we have to manage to battle all of those because actually modeling is a combination of a bunch of things. It's not just one. We're not just looking at code and trying to make it work. It's, you know, being part referee and part business analysts and part logician and so many other things is all it wants. But because of ourselves, especially well, nobody really knows we're doing any of this. That's a really great point. So IT in general, I think, does a lousy job at marketing to the business. I think data architects and sellers are even worse at it. I talked to one of my talks about how, you know, a developer has a certain attitude to problems talking to business users about all the successes they had over the last week. And in fact, even sort of the Agile Scrum stand-up meeting is kind of about that. It's not a bragging thing, but it is saying I got this accomplished and I'm going to do this tomorrow and I'm going to get it accomplished. And that our sort of traditional waterfall method approach that data architects love, you know, just assumes that we're all doing a great job. We can't really, you know, recognize outstanding accomplishments instead of the regular ones. We only talk about those. Do you see that cultural difference? It's okay. It's not very often. Sometimes you do get a business who, all of a sudden, Donna and their application is out there and being used and lovely, we'll come back to you and say we could not have done this without you because you were such a nitpicky little twit that you actually kept us from shooting ourselves in the foot on a number of occasions and you were real pain while you were doing it. But we couldn't have done it without you. I certainly have had that happen a bunch of times. Oh, that's great. That's really great. I know when an end user talks to me about those things, I'm like, so please go talk to 100 or more people. I'm talking about people differences and I know you've also hired people and hiring practices and things like that. So how do you think about hiring people for their skills versus their teams versus their tool skills versus their detailed knowledge of a product? What would make something like data modeling more difficult than it needs to be? The experience shows me that more than not a skill data modeling is treated like a real valued resource. So if you need an architect, okay, I need an architect. That's somebody who can do data modeling. People ever say to themselves, well, I need to go find a data modeler for this. You just don't have a concept with that. I have a concept that is somebody can write a code or somebody that can administer a database or a web server. Those are the knowns that people's tiny brains can conceive. I understand what that is. Modeling is such an abstraction. It's like, you need to hire a professor and think of it that way. So what they end up doing is getting somebody to file like a coder or something like that and they say, okay, I don't have a way to go build this database. Can't you handle that? You do the coding. And people end up kind of falling backwards into data modeling. Same way that most of us fall backwards into being a database administrator. So if you're getting hired as a modeler, like would there be 10 questions that you could give for a data modeler? Probably not. Maybe for an architect. A project manager. But, hey, look, I need an expert in Erwin and nothing else. I can do that. Yeah. I think data modeling is one of these things that's just kind of expected that people have these skills. Under that, these are some tools and they are some of the faults they give us. So people sit in front of these tools. They create these models and they think it's got to be good enough and that's when they're getting deployed ultimately. That's probably been more true is that a lot of the roles I get for work have to do with someone's got a data problem and they know the data person. They're not sure that they can create a model or they don't even understand what the value is or they've heard a lot of myths and misunderstandings about them. They have to take a year to do or something like that. So that's a really good point. I think a model and a project and in our group, we're both. The DA are both. Yeah. We're going to use those terms interchangeably by the way, even though I know a lot of organizations accept this duty. If you need to know where some data is, if you need to know where specific pieces of data are, you don't need to know the DBA. You go to the hall and you find one of us and say, hey, do you find something that does this or says this? And I think that too, we don't do a good job in bringing up during evaluation time. You know how many people in the time we saved? They didn't have to get a look for this. We knew where it was. We gave them every piece of information they could ever want about this piece of this stuff. Because it came before. It wasn't just data modeling. It was finding stuff out and writing it down in a different manner in a place. Correct. You can get to it. And Thomas Wright, that seems to be a, well, of course you're going to do that. Well, not of course. Because they're going to get a spreadsheet on their project drives, right? Correct. Exactly. Keep it in their head. Excellent. Excellent discussions. Sort of, we've talked a little bit about tools and training a little bit. So you have a background of programmer and DBA and some technical stuff, and then data modeler. How do you make that transition there? I do puzzles every day. And programming is a puzzle. And I was trying to figure out I moved to a new job and was given an assignment. I realized where anything was and I didn't know what the database looked like. So how could I possibly get data out of it? So I moved to the Data Dictionary and then started to draw. Oh, that's how this fits together. My boss at that time saw that. He said, oh, well, you don't need to document this one, too. So that's totally different than a data modeler. And after that, training, did you read books? Did you read books? I went to some data conferences. I read a lot of stuff online. You can learn real fast the nomenclature. The vast majority of data modelers came through that, what I call the apprentice thing. You know, that's how we've done scans for very traditionally in the traditional world. If someone just discovers that they have an interest in it, you decide more skilled people, but now we have the opportunity to teach us right and wrong, right? Right. Well, not so right and wrong, but they can teach us well or poorly. You can do this, but it's going to hurt you. Yeah, exactly. I thought from DBAs a lot. But that's kind of one of the things that I think makes data modeling hard for people. And one of the questions we have in the QA is how someone makes this segue from programming or other technical skills into data modeling. And there's, I mean, this is a classic career. It's not really a career move, a career transition, going from an IT role to a career. And lots of people do that. And, you know, I always think it's a lot of self-study. It's training. It's the work alongside people who know what they're doing. To me, that's always my number one recommended way of doing it. But that's hard to do if you work in a company that doesn't have data modelers, data architects, or doesn't have it as a formal role. You know, they leave it up to other people. And I think that is one of the things that we do as a profession that makes it hard is there's not a lot of training out there. I don't know of people. I do it. There's a lot of great people who do it. But I'm just saying you can't, you know, go to your local, you can't just go anywhere in town someplace usually. Usually it involves travel or bringing someone in to do all that. And I think that being able to have someone review your models and point out, you know, what you probably should have considered this, or you might consider doing this another way, or that flat out isn't even implementable. That's always a favorite one of mine. It seems hard, but we make it harder by not recognizing it if it takes hands-on experience and training to learn. Thank you. Thank you, Tom. After you. After you. After you. Awareness. There just seems to be a lot of awareness. And I think we're moving further away from it as things get easier and easier to implement out of the box. I think we're going to have to post a while back, right? Data modeling is dead along with data modeling. We're going through this trend in the industry where you needed to have this architect. You knew you needed to have data professionals come in and help build something and they designed a logical model and talked to the DVT to help implement the physical model. You knew you needed all that if you were some type of big shop, right? Nowadays, you get smaller shops. Two people come together. They have an idea. They grab software off the shelf. They're off their running. A computer thing laid down the road. Somebody comes back. They look at it and they go, whoa, who built this thing? This thing didn't build the scale. That's for sure. Then with the cloud, we even have further abstractions, right? But now with the cloud, what you're finding is I think there's an idea that we need to focus now on the fact that you wanted it right from the start because there's going to be a performance and a cost penalty for you. Don't design it from the beginning. So I think it's coming back into a vogue, right? Maybe it's a fashion these days, but if you don't have the awareness, if you don't have the awareness and people don't put a value on it and they just don't care about it and then it's difficult to get things done. That's a great point about so we've gone through this phase of, you know, just free. We went from, you know, being very expensive and we were worried about, you know, tiny little data type lengths for making sure that our records were narrow and that we didn't collect too many. And then we kind of went to where it's practically free and now we're going to cloud resources and it's not that you pay for every one and zero, every bit and bite that you're sending up there or that you're taking out and that's sitting up there. And I'm starting to see more requests for sort of sizing data appropriately, not undersizing it but sizing it appropriately. And that generally takes some data architecture skills. You have to know the nature of the data. You have to know what makes for good links for it and what data type it is so that you understand that cost. Is that the thing you're talking about? That's an excellent point. Everything old is new again. Yes. It is. I think the difference that I say about the cloud is, you know, we've had that before in the mainframe world. The difference is now anyone can send some data, a couple gigabytes of data up into the cloud just with their corporate credit card not realizing what, you know, that the rates look real long and affordable until you put a whole bunch of data out there and keep bringing it back and forth across the wire. It can get large really fast. And it brings up, you know, don't worry about the security of data in the cloud and I worry more about people not so much what I'm talking about is using security in the cloud but just any old user or IT person that has no business going outside the company. I mean, those kind of things scare me as well. And that's why part of my role as a data architect is to assess security, the sensitivity, the GII, the health data. You know, to say, hey, this piece of data can't go up into the cloud because it's protected. Right? We have the same discussions here. And one of the things, one of the services that DA provides is maintaining all of those designations for every piece of data that we can get out of a little problem. So some of the things that I had never thought of that was health data could be considered. So things like what your meal preference is on the slide. Right. You know, it's something that, you know, most people just think, okay, yeah. But it's actually protected. So you have to worry about even something as what, you know, as simple as that. And, you know, I can put the data model say this is covered under sensitive health data and now we need to protect it appropriately. So that's interesting. But I think that because in my experience, programmers don't think about those things. Business users, right? Right. Absolutely. And I think it works with the programmers about why that's crazy. Because I'm the one that takes that and says, okay, programmers, like so for instance, this data has to be encrypted. If someone likes encrypting data, they think it doesn't need to be encrypted because that's a performance hit. So it has all these other trade-offs with programming it. You know, it has to be encrypted and decrypted. It has to be protected in all kinds of other ways. The backups get extra protection. There's all kinds of a ripple effect for that. It's not health data. Well, it doesn't really matter what you think. See, I find that part fascinating. When you look at those conversations, do you have the business or the data owners backing you up on that? Yes. Mostly because so much of this stuff, you know, has some pretty interesting reasons why I think we're in the years of data is that there's some pretty embarrassing consequences to it. There are fines and things. Data breaches are being reported so widely. You know, a lot of business users don't want to be showing up on the front page of the New York Times that they disclosed health data. It doesn't matter that eventually it gets reported that it was low-fat meal choice or something like that, even though that's still a violation of their privacy. It doesn't matter that anyone will know about their solution or about their data. Their data was exposed, right? And it depends on how much authority I have as an architect on the project to be able to say, no, it's sensitive data. We must treat it this way. We go to the business users and get it ruled that it doesn't need to be protected. And they do that at times, and they realize what a time that might be. So we talk about hiring practices and people and making it harder. We talk about apprenticing and learning and education. And when we talked about you went to some DAMA meetings and everything, one of the things that I find is that it's made data modeling easier for me over the years. And it's paid off big times. It's this community in the data profession and going to things like my local DAMA meetings, the data difference, differences like paths, like other things. Being a community of people outside your own organization, how did that help make data modeling easier? The old story of you are not alone, child. There are other suffering, same trials and travails. Yeah, you can help yourself. That's the best part of it. Here's a little bit of yourself. That's a good point. And talk about you. Yeah, I think it's a good point to set it up. Certainly, even though I'm on the board director's floor past that you've mentioned, it's connect, share, and learn, right? That's a good point to focus on connect, share, and learn. And I found that out years ago that value in understanding how to be alone is especially a SQL Server DVA. You find you're the only one in the shop because it's easy to deploy and implement an instance of SQL Server. Or anybody can click next, next, next, next, next, and boom, I have a database. So then you have troubles. You have troubles of that. You have trouble communicating with business users. You have troubles but you feel alone. And once you know that you're alone, that kind of changes things a little bit. Knowing that I can email you or I can email Shannon and say, I need help. Where can I go? That is huge. Burn off my shoulders. Yeah, I think so too. And I think building that network of people, I mean, certainly over the years, I've reached out to all kinds of people asking, you know, I've got this kind of weird situation and, you know, sometimes it's a specific data modeling problem, which is, you know, I run these online forums for data-modulated stuff, although that communication mechanism is really going off as the discussions have moved mostly to social media or to vendor-specific forums. You know, the reason was it was helping each other, sometimes different in arguing, helping each other understand how to do a better job and sharing that with each other. And one of the things that I'm kind of saddened by is because the discussions have now spread everywhere, it's a lot harder to find an answer and to get a group of people to say, well, you need to think about this and then someone else jumping in saying, oh, no, you need to consider this and don't forget that your tool also does that. I think that's made our job harder, is that now in order to get help with a complex cross-platform data-modulated problem is we either have to go to an in-person meeting again, a conference, which is a wonderful way of doing that. I just can't do that every day. Or you can go to different boards, discussion lists, and Twitter and try to get help with it. And that's why we're making our job harder. I think one of the other things is is that what we used to do on all these forums is we'd share scripts like macros or scripts that were used to make it easier and faster to use our tools. And I think that's sort of a problem. I mean, one of my things is a lot of our modelers is the best data modeler, not lazy and then they don't do work, but as in we want to spend our time doing the real valuable work and let the computers do the parts that are easy for them to do. And we've had full questions in the Q&A about the role of tools. It's not about the tools. It's about the modeling. And I definitely agree with that. But in response to that, I think that that model is so complex. I mean, a typical model I might work on has tens of thousands of pieces of information on it. I can't do that in a spreadsheet. I can't do that in Visio. I mean, a real enterprise-grade modeling tool to make that work. Joe, you mentioned a tool. You guys are using Irwin. Have you used Irwin or something? We're on Irwin 9.2 fixed in a go to 9.5. We also have a legacy system, Gen. Anybody know of Gen? The case. Our initial interest was coded through Gen. Is that Gen or something like that? I think they call it Vantage Gen now. Okay, I don't know. But the reason I bring that up is that I'm wondering do you think you can do data modeling with just a drawing tool? No. It's too complex and it's too integrated. I really appreciate both of them, and the Gen is a CA product as well. I appreciate that both of them allow you to have. You can see everything you need to see in all the little octopus arms that come in and go in and out. That's amazing. You can't do the drawing. I think that that's also one of the things that people start out doing data modeling, but they probably don't want to pay. They use a drawing tool, and they realize it just gets harder and harder to do the work as you put more stuff in it. It's not about modeling. It's about drawing a model one time through. It does a wonderful job of that, by the way. That's like 1% of the work we need to do. It's interesting that one of the ways we make data modeling hard is by using the wrong tools. It's kind of a catch-22 for organizations that want to start data modeling because they end up not delivering value that they want to deliver from it because they're using the wrong tools. I think that's a good one as well. One of the things that Tom brought up earlier about the role of modeling is the fact that in the decades ago when I started, we built data models and we designed databases from scratch. Right now, that's such a tiny part of what I do anymore. The models I do are models around package solutions or integration models of getting data from one package into another from a spreadsheet into XML. It really is about modeling data as it sits in many different physical platforms. I think that people associate data modeling with just building a brand-new database. Do you guys have creative databases from scratch? We do, but as I said, now our databases are, we build them from scratch, but everything is so integrated that you basically, you have your database and your database is already there. All you're doing is adding a piece or two to it. Okay. So your database is built upon. And that also is more common in government organizations just because there aren't nearly as many commercial packages as there are many for other industries as well. But do you use your canonical models like for sharing information between different systems? Absolutely, yes. Yeah. And how does the value of data modeling still deliver? We also have a question in the Q&A. Do you think big data tools and data warehouse appliances are devodeling in architecture? Well, you know, with SQL databases, you don't really need a schema, do you? That's great. But then, they still need to know the data, though, right? Of course not. That's what I think. Let's look at the data modeler and more of a data steward or a master data manager, even a master data manager. Yeah, that's important too. That's why I tend to use the term data architect. I think that's the word I use to describe. I just help people figure out their data and know when it's good data and know when it's acceptable quality and that their level is a quality and help get data moved around properly. What is the big one for us? We move it around a lot, but we do the integration, the BI and the depth. We accept that. So I was just going to go through, oh, I'm going to ask you some questions while I also open our poll. And then, what are you going to do with your organization's big data modeling? If you have enough to do your email, you can jump back over to the WebEx. You should add in. You should add in, though, all of the above. I'm not going to make it multiple choice, but I figure people would pick all of them. I don't know where this or knowledge. I'll say skills. Yeah, it's really, really hard to create and maintain an enterprise data model. And we have success at different times. But part of what Stymies does is that we have folks out in the district doing their own IT thing and building their own databases. So we may see it. We may have it documented as sensitive, but we have no idea what they're doing with it out there. Yeah, that's a scary part, right? The whole end-to-end of the data lifecycle of knowing what's happening and everything. Something you want us to know. And that is the hard part. And I keep pushing in an effective data program, whatever you want to call it, data governance, stewardship, whatever, is that data effects need to know more about how the data is being implemented and used because a lot of the errors I've seen had to do with we build a beautiful data model and a beautiful database, and then the data sets were wrong because they made the wrong assumptions about the data, and therefore, but the database got blamed, or the data model got blamed, but it was more of not understanding that, you know, company and division are actually two separate things. So here are the results I'm showing here. Let me spread this out to my members. The big winner was no answer. And after that, the big rock was IT management support and not business support. So that was, it's only 17% to 12%, so not a huge difference. It's only a vote difference of five different votes. But I think those kind of things are reflected in the other options here. Tools definitely you don't think they're probably skills and staffing. And I think that much what I'm seeing out in the field as well is that the hardest time I have on the projects I work on is IT management not really buying into it. And I wonder if it's because we're not doing a good enough job expressing our value, which makes our jobs harder because we can't get the resources we need. But I think in our group, I think we do have adequate resources. Everybody can always use more, but I think we have adequate resources. What we don't have are the managers, the backbone to kind us. We make a full amount of money for state employees. Don't say that out loud. We do. I mean, for a former employee, we do. And they, for all they pay us, they don't listen to us. I think that's actually one of the reasons today is that this is one of the reasons why consultants exist, so that employees can bring in consultants to say what they mean to have said. I think that's sort of a familiarity bridge contempt at times, but that is why a lot of people talk about they don't feel like they have supportive management. And I wonder, it'd be interesting to do a survey of IT managers to see if they felt about that too. I wonder if it's just a perspective thing or not. Oh, of course, a whiny baby. Exactly. So talking about the difference here, if I had asked this to primarily DBAs, what do you think the answers would have been similar? Any other questions? Yeah. When it comes to, when it comes to the modeling? Oh. Yeah. Yeah. Yeah. Yeah. The question was, what's the biggest robot? So, if you asked this to DBAs, you probably have 100% no answer. Maybe 99%, because most of them wouldn't have any concept. Maybe we have to reword this to say what's the biggest challenge for database administration? Sure. Sure. Good question. I'll hand it to him, because here's the thing. What we work with is essentially a black box. It's just magic, right? And a lot of people on the business side, whether it's an email, a Word document, or a data warehouse that's colored blue, it's all magic. It's all done through and unit by Friday. Right? So it's really hard to, it's really hard for people to understand the value of that, like, it's hard for me to, in my field, to come across somebody who says, I don't know what the value is, I have a really good DBA. Usually, the value is that I can just put that out, I can get anybody to be the DBA. And I know that's the case, because I see people who are using this as a DBA, they fall into it, they're pushing it sometimes. Because of the discount, it's like, yeah, whatever, we kind of need that. But people who get the value, they see the value, they're the ones, you know, well, they know what it takes, they know the skills, but those people are just so few and far between these days. Yeah. So maybe the biggest roadblock, okay. Maybe I put down the skills. Maybe it's a manager in charge of the service team who doesn't know what a DBA or a data moller does. They know what a server guy does. So he's the exact guy. He's the guy who knows what a switch is, and more importantly, the person that can mark the data or do the correct HA of limitation and data architecture for the data as well. And it's because of what he knows. Yeah. What about the guy who knows where the data is? Because the guy who opens the switch doesn't know where that data lives. Nor does he care. Correct. He doesn't care. He doesn't care. So we've actually come to the top of the hour already but we're going to stay on for a few more minutes after we return the recording off and then you can hear what we really think. I wanted to thank all of you. Pat, audience, you have some great questions in the chat. Good discussion. I tried to answer a lot of the Q&A. We might get to some of those next. Jolene, as a first-time pilot, you were wonderful. Tom, as a returning one, you were good enough. Actually, okay, great job. Jolene, what's next for you? Not just like what you're doing right after this, but what's going on in your life or your projects next? In our team, we finally convinced Management that we did, in fact, need an enterprise data architect. And we recently, one of our team, one of the DA team was recently hired as an enterprise data architect. And I hired her. She's working really hard at the presentation for Mr. Data Management and Data Governance Initiative. Which we do on the slide. But we can only do so much. Excellent. So, Tom, what are you coming up next? Speaking of business or something like that. I was just going to say, I have to take a shower still today. I said not just right after this. I thought you said, what are you doing right after this? Oh, my mistake. Yes, I do have an event coming up today. SQL Connecticut in North Haven. So, thank you guys in the Northeast, and you wanted to come meet me and talk to me and remind me of how much care and it's usually wrong and these things. That'd be great. So that, two weeks ago, I got head out to, so I'll be in Santa Clara, I think, Santa Clara today. One of those. There's SQL Saturday event. Excellent. I have a few SQL Saturdays coming up. Plus, I wanted to remind everyone that the Enterprise Data World Conference is coming up at the end of April. It's going to be in a good location. I'm doing a workshop and some other things there. Plus, going to do some live from the show floor type things that Anna and I are working on. And you can go to DataVersity.org to find out more about Enterprise Data World. It's my favorite conference of all time. I've been going for more than 15 years. So, Shannon, I want to hand it back over to you. We're late, but I think that's okay. Great. I just love it. What you guys have been, Tom and Julie, you guys have been just great today. It's been an energetic conversation. And, of course, thanks to all attendees who hang in there. And just thanks to all the attendees who hang in there and just are engaged with this panel. We just appreciate it. So, I will stop the recording for you, Karen. And thanks for the shout-out to EDW. Hope everyone will see you in Austin, Texas at the end of April. Thank you.