 Hello, my name is Shannon Kemp and I'm the Executive Editor of Data Diversity. We would like to thank you for joining today's Data Diversity webinar, Big Challenges in Data Modeling, State of the Union of Data Modeling, and this series is moderated by the esteemed Karen Lopez. 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 section, or if you like to tweet, we encourage you to share highlights or questions via Twitter using hashtag BCD Modeling, Big Challenges in Data Modeling. As always, we will send a follow-up email within two business days containing links to the recording of this session and additional information requested throughout the webinar. Joining us today are two great panelists, Sue Goinsen and Anne Raismith, C. Sue, I am housing it there. Anne Raismith, Ph.D., is an information management professional and consultant with broad experience across industries. She is a certified data management professional, CDMP, and is a frequent speaker and author on data management topics, especially data governance and enterprise data management program development. She is the primary author of several sections of the Data Management Body of Knowledge, and she writes regular column in the Data Administration newsletter, TDAN.com. She has a love affair with data for almost 18 years, now starting with being handed a stuffy disk with a list of builders and told, this is yours now. The love affair has led down multiple data paths, and she has worked for and with many of the largest organizations in South Africa. Sue is currently president of DAMA Southern Africa and the most recently elected president of DAMA International. Things that she believes have been amazing achievements of which she is most proud include becoming the first CDMP in Africa, starting up one of the first ever data governance programs in South Africa and being asked to appear on Karen's panel. And with that, I will turn it over to Karen to get us started. Hello and welcome. Hey, Shannon, how's your day going today? Other than being a little tongue-tied, go ahead. Excellent. Thank you. Thanks, Shannon, and thanks to Dataversity for sponsoring our monthly webinars on big challenges in data modeling. We've been putting together this year's sort of editorial calendar coming up. We have a whole bunch of exciting topics, but I'm always looking for input on people you'd like to hear chat about on one of our panels or events and topics you'd like to hear about. So feel free to put those in the chat or the Q&A so that we can take those forward. I also wanted to thank my lovely panelists, Sue and Ann Marie, and as well as all of you out there who have logged into this or may be listening to it after the fact, I consider you our third panelist, our other panelist. So unlike other webinars and broadcasts, we actually encourage you guys to chat with each other in the chat feature over on that sidebar on the right. So we try to keep an eye on that while we're multitasking and talking about these things. But if you have a formal question for the group or for Shannon, a logistic thing, please put those in the Q&A section because it's easier for us to find those and answer them for them. A final note is there are three slides. This isn't a lecture or a tutorial on something. The slides we have are what you're seeing right there. So you can sit back and listen, grab your favorite beverage, whatever that is, and do some chatting and interact with us. Oh, I forgot to ask Shannon. Shannon, do we have polls today? We have some notes, certainly. Okay. If you can build those. I did send you an email, I think. So if you can build those. And if we don't get to them, that's fine, too. Let's talk about what the topic is today. So today we're going to talk about Stay the Union. Well, why Stay the Union? Well, because in the U.S., this is Stay the Union's speech time, where Shannon talks to people about where he might see the United States and where we're going for. And so I thought this would be a great time to have a Stay the Union for data modeling. So a lot of, like my panelists who have a lot of experience and like a lot of you out there, a lot of us have been doing this for a long time. We've seen things that have changed over time, things that have stayed the same. But I think maybe I'd start with just a little, I'd give a brief overview of where we've come from. And one of the things we're at as a profession is putting together sort of a published history of everything that's happened. I think maybe that would be a great task for people to have. Maybe that's something we can do at the upcoming Enterprise Data World is get some people together during one of the evenings and try to collaborate and crowdsource a brief history of data modeling and data management. I think that would be great. But I'll start with maybe where my career was is I started data modeling back in the 80s when I was in school. And we had the ERDs and everything, but what we did were data flow diagrams. We created data dictionaries. We created file layouts specifically for FAT files or VSAM files or ISAM files. And then on that same time through the advent of relational databases came along. And I was fortunate to be studying database technologies at a time when Ted Codd had published his papers and vendors were beginning to build out relational features either as a link on top of their pre-relational DBMSs or brand new ones. And there was a lot of contention on there about how relational is a relational database. So that was an interesting time. But the data modeling I did then was part of using those green templates, mostly in green bar paper. I really dated myself here. But Sue and Anne-Ree, what's your name from in data modeling? When did you get into those things? Karen. Mm-hmm. I had a similar experience with you. I had a modeling career in grad school when I was introduced to modeling data flow diagramming format for a grad school course. And right after graduation, I went to an insurance company where one of the people in the organization for whom I was fortunate enough to be told the word was insist on that I learn relational data modeling. So I was a profession and she was a data world as an attendee. And she was one of the perfect people. So we're seeing capabilities for the history of data modeling because she's been doing it since the beginning. Yeah, so we should make this happen. We should so make this happen, I think. I think it would be a wonderful idea. I'm sitting here actually writing talk to Sue about Karen's idea where I did it. And from there, we built one of those cruciatingly detailed to use John Zachman's phrase and her program models. It's a segment and paper and the original case tools to build what was normally normalized on my God, normal form, conceptual data model and all the metadata associated with it. That's how long ago it was, back in the 1980s. And what I wanted to do right in a lot of things I would never do again. Yeah, I'm missing myself because the planes are still coming over. So I'm the real baby here because it was the 6th of February 1996, probably at about 9 a.m. in the morning, that my new boss handed me the Stiffy disk and said, yeah, you need to look off to these people. This is your problem. So I subsequently put the Stiffy disk in the PC that was on the desk and I looked at it and I went back to him and I said, this needs a database. He says, well, go buy one. Here's my credit card. So that is how I felt about it. And I really did. I went out there and the only database I knew of was Access. So I brought it back to the office, copied all of these things out of the Lotus 123 and pasted it into Access. That's how much I knew what I was doing. There were about two weeks, I guess, of really typing in pieces of information every time I got a new builder and it suddenly occurred to me that I was being a bit silly and then I started looking at the data and going, but that looks like that and that looks like that. And I think by the end of the year, I had six developers working for me and we'd moved from Access into SQL Server 6.5. So I started data modeling. It was no training, nothing. I just didn't have a choice because I couldn't live with typing in about 100 columns across an Access table. You know, that is the most common way. When I do my presentations at EDDO, I usually ask people, how did you get started and all this and those things. And I mean, maybe 90% of people in the room got EDDO. I fell into data modeling, which I always think is hilarious. Or they were pushed into it and, you know, they were finding a better way. Today, I'm not sure that's how that happens and that's what we're going to talk about in just a little bit. This is something that I started with green templates and green bar paper. And we did have a model tool accelerator, which I think was primarily data flow diagramming tool. And this is all seen as new, new, new, right? Because at that time, we would have had DOS based machines. Gosh, I feel like I'm granting people how I walked uphill both ways in the snow to school. But this year, just as I was getting data, you know, the modeling tools, the case tools were coming out. There was IEWF and IEW, which became ADW. And there were things like Bachman data modeling tools and everyone, and S Designer, which became, I think, Power Designer. And then there was Silver Run and Oracle tools. What's left out here that people worked with? Back then. I'm not sure. It's a prize architect. And prize architect. And system architect. And yes, of course, ER Studio now. Yes. I mean, so the newer tools that came out, like the Oracle Designer, ER Studio, Erwin came out with just a little nobody tool, and then ER Studio came out. Also another one. Erwin was built in New Jersey, not far from where I live. Yes, I remember that. And also at the same time, when these tools came out, then the big question became, what notation should they use? So there was notation. And then the United States government, mostly the Air Force, got together and came up with IDF 1x and all the IDF 0s and all the other notations. And about the same time, we had what is sometimes called Martin notation, sometimes called Informational Engineering notations. But basically, there's depth in the crow's feet and all of those things. Also interesting, at the same time, when the national things were coming out, so the organizations that eventually became DAMA, came out. I think DAMA recently celebrated a birthday. Is it 40 years, you guys? I can't remember. Yes, 40 years. 40 years as an organization. Yes, as an organization, I think. And then there's our own chapter. Our own chapter, ERMAC, is even older than that. So I think we're 45-plus years. So going on all those things. And then we kind of passed forward in just a few years ago. DAMA came out with the data management, the guide to the data management body of knowledge and also worked with ICCP to come up with the certification. And I think that's kind of covered sort of the tools, the approaches, the notations, all those things. Which thing major that I left out? I think. The frustration factor. So that's also a whole other webinar that I love. It's my favorite topic. One of those things about sort of the conflicting points of view and how we reward people differently to be architects and designers versus builders. A whole other topic that's still one of my favorite ones, though. But yes, the frustration of figuring out where formal data modeling methods fit within other tools. So I'm going to go ahead and segue to where we are. Okay. So I can't remember in Method 1. I remember, oh, the methodologies. I so should have mentioned that because I worked for big methodology companies as well. So that was the other thing that came along with the case tools was the methodology wars. So to the point where what are the methodologies I was asked to implement for a client had something like 400 deliverables for each producer. It was internal deliverable. It was internal deliverable. And so there was that whole, and a lot of them were tagged as information engineering methodologies. Talking about that, because most of us have tried to ban the word methodology because it got so much hype and there weren't that many people that worked by following a methodology without following their brains. So all of that stuff. So here we are now. So out of all those tools that I mentioned, a lot of them still exist somewhere in some form. I know that Silver Run was put into open source. At one point I know that Power Designer is still going strong. Irwin ER Studio. I know technically I think I have an ADW still exist somewhere in the CA world of tools. Oracle has a SQL developer tool that Oracle Designer is no longer supported. There's lots of the current tools. Vizio, I forgot to mention Vizio, is probably the second most popular data modeling tool right after the number one data modeling tool which tends to be either Excel or PowerPoint. So that's something to hear. Yeah, and I have a blog post about that. I'll try to look that up and share that in the comments. It'll definitely go out into the post notes about what makes for a good data modeling tool. And the other thing I missed in all this is sort of the advent of repository model marks, collaboration modeling. To me that was a big change in the modeling world where we came from. So where we're at though is that what I found from the field is that one of the biggest frustrations, one of the biggest challenges that people have is trying to make this formal data modeling methods work within the constantly changing workflow and methods that are happening in the software engineering world. So of course the next player there is Agile Scrum, other newer things, plus other very specific things like Code First and all of those. And I've talked about those on other webinars too. So where are we going to see this? Sue, where do you think we are now with the way of thinking about how we develop models fit within the new and the changing role of software engineering methods? I don't feel like I've done a whole 360. You know, actually I really did it. It was extremely agile. I kind of stuck stuff together, made sense of it, spoke to the developers and got them to understand what I was doing and we went ahead. I don't think I even understood the methodology of build your conceptual one, then go to your logical, then do this and then do that. So I learned that post having done the whole agile mechanism. And I do feel that sometimes we've gone all the way back to the beginning. I have to say I'm not quite sure that I agree with it because I now sit at the end of having done a bit of agile data modeling with one of the developers and today I spent the whole day trying to make sense of millions and millions of rows of data that I feel that I made a mistake on because I designed the data model. But I did it agilely because I had to do it quickly and I didn't take into account things like how many records there would be, the fact that the developers would go behind my back and make changes that I didn't know about. You've met those guys, have you? What's different about all the other architects on our projects? Do they suffer from the same thing? I have heard so. You know what? I mean, I see that there's a gentleman and he's from the South Africa as well and I actually met him and spent some time chatting to him and I have had him say very similar things to me as well that we seem to all suffer from the same problem but we don't quite know how to resolve it. One of the things is like the architects I work with are either enterprise architects, which means they're responsible for a whole bunch of models sometimes done in enterprise architecture tools and they usually have more cloud or authority and sometimes data architects report up through them because data architecture is a subset of the enterprise architecture. They suffer from this whole sort of impedance match of what the architect and what development technicians want to put into place. I'm wondering, they're just maybe I'm doing the data architecture as well that I feel like there's much more resistance from those that are quite fair to be heard in them, compensated and measured to do things that break our architecture. We have them on performance and getting things done fast and we don't measure them on data quality, data integrity, or flexibility for far future versions, usages of the data. That's breaking so much from this. Is it us, should we be looking at ourselves or is it a combination of things, Anne-Marie? I think it's a combination of those things, Karen. I think that one of the things I've seen in the assessment you do for enterprise data management is that I include an organization of an enterprise data architecture group. In that kind of recommendations is that most organizations don't implement their enterprise architecture team to include data architecture properly. They do implement their technical effects, their infrastructure architects, etc. But to do that, they don't break a data architecture. They don't do the imposition of the use of data governance, the organization of master and reference data into an architectural approach. They tend to do things fast. And then there's an enterprise data strategy that looks at data as a corporate asset and provides this value to enterprise architecture. It's a management strategy to be effective. And for your enterprise architecture, I think I can't even tell it all. You're doing great. Tongue-twistedness. I think you get a challenge on both areas. Everything is different, but I need this continually to make it sound like I'm on a little soapbox because I say it all the time. Not only not, but I can tell you I've either been on panels or attended panels for the last five years, and we're still having the same discussion. Yes. I know it's going to be a little bit disruptive, but we've got our polls, so I want to go ahead and do the poll really quickly. So the first poll I'm going to give you is, who are you guys, you participants? Can people see the polls? They should be. Yes. I'm going to give about 10 more seconds. Get voting. We have more people than this. Okay. We're closing in 15 seconds. I can never tell. I forgot to look at an attendee this time. I'll give you the results. So basically, we have about 50% of you guys are architects, 8% business analysts, other analysts, 4% DBAs, devs, other techs, 3% of you are architects, 5% other, and 20% of you who have no idea what you are or are busy finding someone on Twitter. So there's one. How long have you been actively data modeling? Now, by actively data modeling, it means either consuming or working with, and I assume that if you're here, you're actively working with it, even if you're looking them. So we'll go ahead and open that poll. I'll give you some music here. Some sort of weight music. Exactly. I'm assuming that E is going to be the big one. On my bio slides, I always say I've been doing this for 20-plus years because I've mostly stopped counting. My bio slides is the same thing, 20-plus years. Yeah. Back to saying 10-plus, I think. It's like the more interest I get, the more I have to skew the data results. I'm still waiting. So when I get to 20 years, can I also do the same thing? Definitely. Yeah. I'm still waiting. Yeah. Very common. Very common, right? Yeah. So let's see. Yeah. You know, a dozen people or so, they've been doing data modeling for zero to two years, and 10 to about the same amount doing three to five years, and 13% doing six to 10. That makes it sound like we're doing prison terms, doesn't it? Yeah. 32% of you are doing 10 to 15 years, and almost 30% saying I stopped counting. Yeah. So this is both a plus and a minus, I think, sometimes on my project team. So because I'm so experienced, a lot of people on my team assume that I'm really stuck in the old ways, because most of us are, or that you're doing projects, I'm coming in to help fix a data model and a database design. And so a lot of people there, their experience with data modeling is very light, and very light as far as depth and breadth of their experience. So now we can go back to some of our questions. So where we are now. So the other thing I wanted to talk about in this State of the Union where I see things is while I've deemed 2013 as the year of data, and now I'm going to still call 2014 the year of data, because data is just so prevalent in the news with big data, with big websites not being happy, with data integration projects making world news, with data just being a big deal. I know I was impacted by the U.S. one last week, and it's been very annoying as I reveal my credit cards. But I think with the question now to my panelists, let's go back to Sue. So most of the data modeling tools these days work either with IE notation or IDF-1X notation, but they really haven't been updated in a long time. Are they still meeting our needs? So not the tools, but the notations we're using, like ERD, like IE, IDF-1X. What do you think? I'm not sure that they are. I think they have been, but I think there's this real change to agile and this real change of the way we think about data. And I really believe that we might need to revisit these notations and actually take a good look at them and say, okay, does this really work? Is it giving us what we want? Is it actually meeting our needs? And I would probably bet on it. I would actually put some money on it, but it's actually not the case. And that we should be really revisiting this kind of thing. Do you have any examples of things you'd like to see it notations and support that they don't support now? I know I'm not on the spot here. I know. I think for me it's about understanding the relationships between data and the context of data. So we have this little notion where we've got three little lines pointing that way and one line pointing the other way and all of these things. And traditional data modelers, and there are a lot of them around, they understand that, they get it immediately. But what I do see is a lot of, is that there aren't so many traditional data modelers as there are people who are, as you said earlier, falling into it and are doing it because there's nobody else around to do it and they've got a bit of a passion for getting the data right. And they have absolutely no idea what they're doing and they can look at a book and it then goes, hmm, so what's a crow's feet notation? And unfortunately, unless you've seen Alex's little dance about crow's feet, you always really know. So I'd like to see, if I say I'd like to see it in a more English language way, I think where it's more visual, more visual than the crow's feet or more visual than the other things. Again, you're right, you did put me on the spot, that's mean. No, no, that's good. Yeah. And I see a comment there from Ben talking about, this is an above 40 crowd. And I think that's also very true because what it means is we are all more traditional. The younger generation who are coming into data modeling are kind of challenging the tribe and trusted and some of their challenges are actually valid. Necessarily are lacking to use them what the model and the business and the developer want to represent that's lacking. Time and again, a less experienced modeler didn't understand what an experienced modeler was trying to convey, abilities, ending up going from Philips, Emix to Dallas, and then finally to Austin. Yeah, that's always going to be an issue. I've opened up a poll on this thing about audience feels about this. And I think that one of the ones we use right now is actually at least in the major tools is a combination of Philips 1X didn't have the crow's feet normally. It was an IE notation or a Martin notation. But the 1X was the one that had all the attributes like a table. It looked like a reverse engineered table and all that stuff. I think though that because a lot of modeling tool vendors you definitely want to meet standards that you can get government contracts when the governments have that as a standard or organizations do. And that standard as far as I know isn't actively maintained anymore. I think it's an active group of people modeling it. And I'm finding there are features that I want to see in the notation. So things like the most common one with IE F1X is it doesn't support ARCs, which means actually exclusive relationship like this entity is related to only one of these other entities at the same time and IE F1X has another way of doing that with subtyping, but I think it's not really the right way of conveying that information. And I know there are people who've been doing a lot of work to try to come up with new notations. I know even Harry Ellis who was responsible for architecting a lot of the original Barker notation and people have worked on extending things and there are some new notations that are sometime put around. But I'm wondering, you know, we can't really do a profession that this sort of way of conveying data about our data has not changed in 25 years, that there aren't new ways of thinking about how we want to explain data and the underlying metadata for them. So it works. So one of the questions in the forum is what about UML? So UML is a modeling approach to methodology and notation and unfortunately not a great deal of success conveying to business users. I have better success with UML notations with more technical people. I originally designed four technical people but David Hayes has done a lot of work of making UML notation work with how to make programs work better in the business side. But I've solved many of the problems that I have of wanting to have a notation that meets both audiences and maybe that's the issue. I'm not sure. Any other comments on this about that? What I'm seeing amongst the chats going on here is that it seems that most people use a bit of a combination of bits and pieces to get their points across. But what I don't see is one comment I thought was pretty good. I'm just looking back up at there from Tom. Okay. I think that's Bill C. Something like that. I'm talking about the model is a picture of data and we create them to talk better to our clients, both business and IT. The web has definitely advanced us to a more graphic level of expectations. We'll pass this now. We want to see more use and acceptance by the business if we made the model more graphical and photoshop-like. And I think that was probably something I was trying to get at, is that I really would like to see more actualization of the data rather than the old sort of like, here's a table, here's a line going here, here's a line going there. And you're right. It does miss some of the mutually exclusive relationships although this thing can be related to this and this but it can't be related to that. And even if you relate it to that and that, by the third one it shouldn't be related. Right. Another common request that I see and also that I've talked with Harry about is this, there's a concept of one domain but sometimes the mainness is just over time. Right. You know, I think quality and optionality and the relationships and the constraints that they end up generating are where our current notations are going to be able to say, you know, I don't want to be a customer in my business but at the time they can submit many but maybe only ever one active one. I mean right now in data modeling where do you put those more complex business models? You either, you know, have to just document them as in text. I'd like to be able to put that right into the model. So I want to be able to more engage in support and capture not as a text field, not as a drawing thing. I want to capture more stuff that are far more understood by the tool and I know they all, our tools have user different properties and attachments and different ways of extending the models. I get that. But I want to come up with a standard. I want the profession to come up with a standard in theory that all tools could support this and so that we could have a standard way of portraying that information. So my, I want, we've kind of stopped building and improving our notations and I see that as an issue. And I also want the sort of making it more visual and having more flexibility and realizations is important. And I know a lot of vendors doing a lot of work on that and I think that's a hard thing to do and I just want to keep seeing progress on that. 240, I wanted to move on to, I wanted to bring everybody at the attendees that you can ask formal questions in the Q&A. I've been trying to answer most of those and I am trying to keep track of them but you guys are doing a great job on chat. That's so much that I can barely keep track of it. But where do we want to be now? So my biggest thing over the last couple of years and it's come up on several of these webinars so I don't want to rehash all that stuff is where is this in 2014 of data and we've got all these non-relational data things to model. Meaning these are equally big data, whatever you want to call those things. What are we going to do in the modeling world to support that? Ann Marie? Now that's a great question for a panelist to answer with this comment, I wonder. Because we have several camps right now and we have the NoSQL camp that says do you want to build anything? Just do it. Definitions of what, quote, NoSQL means if you read different things by different members of the NoSQL Thought Leader community you'll get different versions of what that community means. So I'm not sure that data modeling could work now with the NoSQL Community perspective. You've already given several on how data modeling could help to put in some process some of the more careful ways agile behaves. I'd love to see data modeling done without spending 17 years contemplating the different parts of a data model in an agile world. I think we really find a lot of use for data modeling in an agile development. If you could work with the agile community to do that, not you, we. I think all the areas are, and I think it's a great way for Dama to get this plug for Dama to get in the forefront of being a Thought Leader in the data community by leading efforts to discuss these things. Do I have a choice? Of course you do. I absolutely do agree with you and I think this is a task that Dama should drive. We have chapters all over the world and we have some really great, some really eager, some really passionate people. And I think as Dama International we should really be driving getting people together in these kind of environments just to talk about it and to start identifying what are the things we should change, what are the things that are really good and still working, and what are the things that are just so hard that they're never going to work. I mean, I see Frida has a question about how are you depicting big data? She says, blogs with unformatted data in our tools. You know, and Dama really is. I mean, how are we depicting big data? And I think a lot of us are kind of just putting a little circle there or a little square there and going, okay, well, that's big data. Again, do we have a handle on it? Do we know the context of it? Do we know the context of our data? Because that for me is always very important in data modeling. So I really feel that this is a good topic for Dama International to take on as a... and I think Karen, you might be a good leader in that. You're always volunteering people. One of the things that makes me a president. I know. I'm very presidential. So one of the things about all of this is that I think one of the things in the data modeling community, and our big challenge, is that we're so overpitched and understaffed it keeps us from having the time to go learn... I mean, my to-do list, my to-learn list about all the other technologies that can help try to figure out where is data modeling going to fit on this? I know on one of the webinars I had last year on this whole modeling with NoSQL and big data, we have another one coming up this year as well, is, you know, everyone agreed, and it wasn't just data modelers on my panel, that there's some data modeling that needs to happen. It just needs to happen in a different way, maybe in a different time, and it may not be the same data modeling that we use now. It's just, who's going to solve that problem? It needs to be the data management profession participating in that, and the right type of people. The people who aren't, you know, are trying to try doing something differently, is to come in. There's a real problem. On the projects I'm on, there's a real problem that we have this big, big divide between traditional 1980s data modelers and people who are trying to get stuff done and solving new problems. And there's this whole sort of thing going on in our profession about big data is just a thread, and it's just something, it's nothing new. It's just the main frame. Well, if it was just the main frame, we'd be pointing data modeling tools at it and doing it that way. It is different. So, in another webinar, I think one of the biggest pain points and challenges with data modeling right now is all the things I need to model. I'm not just modeling databases. We're not just building new databases all the time. Most of my clients, it's all packages. And the modeling we're doing is this canonical model in the middle, or we're handling the packages that don't have a documented model, trying to sort of reverse engineer and reverse gas a logical data model and maybe a conceptual data model, then building something so that we can interface the data either through services or through direct integration or integration packages or through service buses and all those things. But the other things that are coming are support cloud databases because they're not quite the same as traditional relational databases, even the relational databases in the cloud like SQL Azure and all of those. They're slightly different. And some of my tools support that and some don't. Where do you guys think that the model space, the vendors, are they prepared for dealing with these new things? Well, I think maybe some of them. Ann Marie, what do you think? A couple of them? Most of them are not. I think most of them are still trying to fix the current ones. Never mind the new stuff where we're saying, listen, we need to model our data in a different way. We need to not be necessarily so inexorable and insist that it's done this way or we need to do some more graphical stuff so that when we show it to a user who has no idea what a database looks like, he or she doesn't run away screaming because there's that little square blocks with lines again. I don't think everyone's ready for it. I do, however, think that there's one or two organizations, vendors out there who are getting close towards this coming edge of let's try and do something different and satisfy the challenges that we have. Oh, okay. I think we're concerned that there are more than one or two vendors who are not far-sighted. I think most of them are stuck in the single releases behind priori might not be the right word but very protective that might be the better word, a program that would monitor the highway and know you can't share data from one or two months unless you let us do it for you and you have to buy everything our way. Yes, I think you're right. And I use, I don't have one specific tool that I use and say, okay, this is the tool of my choice. I will use that one or everything else. So I've tried quite a lot of them and sometimes I go, I wish they would all just be one, then maybe all the nice things I like in A and the nice things I like in B could all go into the C and then I'd get what I want a little bit more. So, you know, I think part of it is they're all trying to be, hey listen, use my tool because it's the best but they're probably not taking into account the people at the end who have to use it, which is us. And I think, I really wish that maybe the vendors would sit together and go, you know what, maybe we should just do one and we'll make it the best we can do rather than let's all have one and try and sell it but it's not really going to work for what you really and truly want. So that is mentioned on tools and price. So one of the issues that's a lot of my teams back who are looking in these new digital worlds where almost everything is free and open source, so Hadoop and all these other, they all have free versions of their TVBMSs is their position where they're going to be paying, you know, 10K a seat for the modeling tool. So one of the things that's kind of happened is our tools got better and more mature and they do all these amazing things and they have these great features that the real cost of ownership for them has gone up because they support so many things because they support enterprise modeling because they have a low blown repository with versioning control and everything like that. The team is used to using free software or open source software both for their development needs and for the implementation needs, you know, for them to understand why one might pay for enterprise design and development software. While there are some open source modeling tools out there, they definitely don't have the maturity that we've seen of 20-plus years of relief cycles for our modeling tools. Would you agree with that? I say that conditionally is because I think that we have the challenge of the why should I buy anything? Yeah. Drawing tools. Because drawing tools is relatively cheap or embedded in other tool suites. Yes. Another issue that I probably face here is that the organizations that I traditionally sort of tend to be supporting are generally the larger organizations and they don't do the let's buy open source or let's use open source. They're far more the let's throw lots of money at something because it can only work if we throw lots of money at it. Like that. But they never throw money my way. So what I see happening is that the big organizations will get some new VP of this or chief from... officer of that and they come along and they say now we're going to do this and we're going to make our data really great and to do that I need this tool and that tool and that software. And they go along and they spend a huge amount of money and they get going for all of 18 months and then suddenly oh, their tenure is up, they're going somewhere else. So that whole stuff gets shelved in the corner. The next guy comes along and does exactly the same but he doesn't want those tools because those tools were previous dudes stuff and I knew new stuff because mine is better. So in the organizations that I do seem to support there's seven different data modeling tools. There are six or seven different MDM tools. There are six or seven different data quality tools and you name it there's a tool for everything out there and the big organizations have them all. They don't talk to each other and then we fall down on the data models anyway. So it's a case of okay we can't read an Irwin model in that product. We can't read a Power Designer one in that product therefore we have to redo it and since we didn't really know what we were doing in the first place and the people who did design that are long gone. Ouch. Yeah. Yeah. There's again the same frustrations. So now to the last few minutes I have another poll for everybody and this one is so we've got to I think our March Webinar is going to be about data modeling dead or alive. It's kind of an update to our last few years is data modeling dead Webinar but I'm trying to use to gauge about sort of the life of data modeling out there is having sort of full-time equivalents of data models and I don't care whether you're an employee or a contractor or a consultant. In your organization are you seeing more full-time equivalents of data models whose primary responsibility is data modeling and data architecture. Are you seeing more of them or fewer of them in your shops? And I'd like to have a lot of people voting on this so that I can see how it's going. So even if you've pitched away and you are busy playing Candy Crush or something on Facebook if you could pop up and vote in this poll and look it's already starting to close get to your end and you've got four more and one thing is that wow that's not quite the graph not very many people voted but it looks kind of evenly spread that we have more 13% of you have more 10% have about the same 10% have fewer and an alarming 13% don't really have full-time data modelers at all. I think that I mean the reports from the field that there are fewer and fewer data modelers in organizations. What are you guys seeing? The modeling responsibilities given to other members in the organization and the accidental data modelers. Data modelers. Well the contract that I'm busy working on right now there is one data modeler in the whole organization and that's me. I see that quite a bit. I see that quite a bit. What's really scary is that I actually am not in to do any kind of data modeler. The specific thing that I'm supposed to be doing is actually there's no relation to please build me a data model or please tell me why this table doesn't look like it and what I should be looking at and I would say probably at the moment almost 30% to 40% of my time is doing answering those kind of questions or even if it comes to a piece of paper and quickly drawing a model and I'm the only person in the whole organization and I'm talking over 6,000 people. Yeah. And the Q&A is there's a shortage of them to find our company once them. I have a lot of experiences trying to help clients hire what I consider real professional data modelers or data architects. Not just people who have once reverse engineered a database or once took a class seven years ago but people who have several years of experience of doing that. I think that's a real problem for data. I think it's a real problem. I have people that love their data and I want there to be professional data managers, right? And the fact is is that when we go to events everyone looks very experienced. When we go to EDW I see very experienced people asking people how long they've been data modeling. It's queues into the double digits so we have a real problem here and we always invite people to stay over for about 15 more minutes with the recording turned off where we can talk about some of the things. Because we have more minutes I think I'll start the wrap up. I want to thank my lovely panelists Sue and Ann Marie and I always think when we get to the end of these we should just have more time for this. That's why we started doing the pre and after show. I want to thank Shannon for making all this stuff happening and we all get here and get logged in and the attendees get their support. I want to thank Dataversity for hosting these and I want to remind you that we these happen every month so the fourth Thursday is at the fourth. They happen every month you can go to dataversity.net. The other thing is I want to put a plug in for Enterprise Data World. You guys are both coming to Enterprise Data World, right? Yes, definitely. And it's going to be a lot of fun and it's the 18th year I go to it every year. I think I've only missed a couple of years due to constraints and it's great for learning from very broad leaders and you can go to dataversity.net to see it as well as it's a good sort of sort of way to get to the end of this. I want to thank you for having this sort of sort of way for data modeling by having these same discussions with other people and sharing useful tips. Speaking there as well I'm doing a workshop and I'm running a SIG so here are all the things we're going to do. So I'm going to turn this back over to you. Karen and Sue and Anne-Marie thank you so much for this fantastic discussion. I just love these webinars and I especially love all the attendees who just chat away and really get involved in the discussion that's just what makes this webinar so spectacular. I'm still just tongue-tied today. So anyway I hope everyone has a great day I will turn off the recording we'll get the post-show started and thank you everybody for your time.