 Let's start it here. Hello and welcome. My name is Shannon Kemp and I'm the executive editor for Data Diversity. We would like to thank you for joining today's Data Diversity webinar. Big challenges in data modeling, staying relevant and valued as the data modeler. An interview with Alec Sharp. 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 would 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 the session and additional information requested throughout the webinar. Today, we have a single interviewee, the infamous Alec Sharp. Alec has managed his consulting and education business, Clare Tech Systems Consulting Limited for close to 30 years. Serving clients from Ireland to India and Washington to Wellington, Alec's expertise includes facilitation, business analytics, this process improvement, and, of course, data management. In addition to his consulting practice, he conducts top-rated workshops and conference presentations on these topics globally. Alec is the Officer of Workflow Modeling, Second Edition. Alec's Tech House 2008, which is widely used as a consulting guide and university text and is a bestseller in the field. And, of course, let me introduce our esteemed moderator, Karen Lopez. Karen is a senior project manager and architect of InfoAdvisors. She has 20-plus years of experience in project and data management on large, multi-project programs. Karen specializes in the practical application of data management principles. She is a frequent speaker, blogger, and analyst on data quality, data governance, logical and physical data modeling, data compliance, development methodologies, and social issues in computing. Karen is an active user on social media and has been named one of the top three technology influencers by IBM Canada and one of the top 17 women in information management magazine. She is a Microsoft SQL Server MVP specializing in data modeling and database design. She's an advisor to the Daima International Board and a member of the advisory board of Zachman International. We meet both Karen and Alec in person at this year's Enterprise Data World 2014 conference in Exo in Austin, Texas. And you can check out an interview we did with Karen on dataversity.net about her upcoming presentation at the event. And with that, I will turn it over to Karen to get us started. Hello, and welcome. You're awesome as usual. Thank you. And that was a lot of stuff today. And I hope it's Alec. I'm so happy to have Alec with us today. And if you haven't seen him present, you have to add that to your data bucket list for certain. He does such a great job of keeping people logically and physically involved in the subject matter. And very much so. And I would just point out that he does Canada proud as a gal event around the world talking data process and other kinds of interesting stuff. And sometimes Alec and I get to be at the same event at the same time. So as some of you were hearing in the early parts of this, Alec and I travel a lot. And so we're really in Canada at the same time. So this is another anomaly. We should both buy a lottery ticket. Except what other lottery tickets pay Alec? Like $40,000? Something like that? I guess $80,000. A little bit more. So as Shannon said, we don't have a panel today. What we're going to do is have just a discussion with Alec and hopefully a little snarkiness, a little bit of fun, a little bit of laughs, some serious stuff. And that means there aren't any slides. So don't bother asking why the slides aren't moving or whether or not you can download them. What you see there is what you get at this. But that means that you can focus on the chat that's going on in the WebEx. And in that chat, you can ask questions and talk to all the other people logged into the meeting which I really find is a value for our events that we have. As far as you can ask formal questions in the Q&A panel that you should see just below that. And I'll try to make sure that we get to those as well. What you can do is you can also tweet your insights or share some of the insights with the hashtag BCD Modeling for big challenges in data modeling. I also try to keep an eye on that too. So we're all sort of multitasking here. Today's theme about adding more value and being relevant is something that I speak and do workshops on. And certainly Alec does. Even if he might not use those terms in his presentations, I know every time I've heard him speak, that really is his focus. We're not covering, neither one of us covers, you know, here's just the theory behind data modeling or any of the other modeling or process flows or any of those things. But I hear a lot of stories when I go out and speak or when people ask me questions or even what we see in the chat of data toddlers focusing on, you know, that they don't feel like their teams value them or that their management values them or that not all of them do. So that's what I'd like to talk about today. And another thing I want to point out is we've been hearing these stories for my entire career and remember my career has that 20 plus years because I stopped counting at 20. Yeah, I'm kind of close to that too. I'm just stopping at 20 plus. I'm not really thinking of backing it out to 10 anyway. So just so I sound more relevant, right? Because we know old people can't do modern development, right? Is that true? Or is old just a mindset? What's old is new again. I'm amazed these days at how full circle things are going. Anyway, can you carry on? I have a question living in there. There is, but the one thing I wanted to say, since I'm talking about old people, I've been doing this stuff for a long time. What sort of things are you working on now? Like what steps, not necessarily products or anything, but what concepts and things are you working now that you haven't worked on in the past? Well, in my helping business, I'm always working on something that I haven't worked on in the past. So I'm going to be starting a job coaching at my major genetic research organization. I recently did some process and data work for a traditional print newspaper that's making a major shift into the digital platform world. So there's always something new going on, but as I said a minute ago, I feel in some ways like the skills that I've been holding for 20 or 30 years are more valued than ever these days. And I think we've gone through, if you look back over the last 15 or 20 years, there's been any number of developments that have apparently made the modelers obsolete. I remember once a client told me, gee, Alex, we won't be needing your help with data modeling anymore. And I said, why is that? And they said, well, because we're going client server. I remember that. A few years later, well, it doesn't matter anymore because it's the eating of everything. This was in the late 90s. And then it was packages. We don't have to worry about that because the people of Waldorf have already done the data model. And then it was all sorts of red and agile. Gee, there's no time for data modeling. And inevitably, organizations get in trouble because they haven't dealt with the fundamentals. And some old dogs like me get called in to help with things. And it almost always begins with data modeling. And as I always say, I don't tell them we're doing data modeling because then they light their hair on fire and run screaming from the room. But that's absolutely what we just have to go back to. What are the concepts? When do we call them? How do we agree? How do we disagree? And I have both at the genetics organization and at the newspaper, just spending 30 minutes doing a simple model of content. Is there a UI opener? So Elsa, oh my gosh, we've opened up so many questions here. So let's start with, since we're talking about relevance and value, why do people run away when they're either we run on a data model or I think we need a data model? Why do you think that happens? For the same reason I run away when somebody tells me I have a six sigma black belt. And that's the most depressing introduction in the world. And I think it's because just like people who've overdone it with something like six sigma, some data people, they get a very narrow focus and focus so much on data without putting it in context. How does our data model, and by the way, I'll just note that increasingly, as I don't call it a data model, but how does what we do support the discovery of user stories in an agile environment? How does it contribute to developing better requirements? Why is it essential to understanding business processes? So one of the most important things that we could do is figure out how to use our skills in these other domains. So I've been very surprised in these years at how each agile teams are adopting some of the techniques I teach because I'm putting them in context. I'm showing how this can cut out a lot of re-factoring as it's known, or how it can cut out iterations in the cycle. I don't really like to use the word silos, but I think what works for me is getting out of the data silo, and that makes my data modeling techniques more valuable than ever. Can I throw in one more? Sure. Empathy. We have empathy. It's so easy to get focused on data and forget that not everybody else understands what we're talking about or shares our enthusiasm. I make the same point with business process audiences. Number one rule is don't ever forget that everybody else actually understands what a business process is. 90% of people think it's the same as a procedure. And when we talk about data modeling, they understand that we're initially talking about a completely business-oriented or should be talking about a completely business-oriented technical view of the domain we're in. Yeah, so that's me. I mean that's what I talk about. One of the workshops I got coming up at EDW in Austin is it's about developing enterprise data models for drive development projects, meaning contribute to them. And my number one factor there is this is not, okay, first you stop everything and then you go to six months to a year to three years of doing an enterprise data model. And only then do you let developers do it. One of the hardest things, so I work on almost all my projects lately are Agile and Scrum. Right. And most projects are troubled projects, which means someone has brought me in just like you said to say, my gosh, we started trying to get some data value out of our development and it's not there. Can you help us? And they're always like, yeah, and we don't want a data model. I'm like, it's okay. I'm going to do a data model because that's my tool and technique. I can do it really fast. I can be agile at it. I know the tools. It doesn't take me long. And I can deliver all kinds of value after having written it down. In this situation, it works well for me. It might not work well for people who've never done a data model and never used a modeling tool, but agile, right? Use the right tools. Use the right level of documentation. And they're like, well, we don't do any documentation. We're agile. I'm saying, yeah, you do write things down in the code. Write it down in the code. Now we can drift off into agile or fragile assumptions. The agile manifesto say no documentation. Everybody misinterprets it. It says we value documentation, but we value code, working code, or work software more. But there's no value to documentation. Let me back up a bit. I couldn't agree more. We have to be able to do something in a more time frame. And my current time frame is 90 minutes. If I can deliver something useful within a 90-minute session, then doing something wrong. Exciting a printer, right? Exciting a printer. You get an extra 30 minutes, right? Yeah, something like that. Or if your WebEx isn't working. I do have WebEx operating, which is why I'm signed in. But I can't see any chat or anything like that. Oh, it's probably, there's a little globe. Probably there's a little globe app that you need to open up. It says I have to log into my account, but I have no idea what my username or password is. So it would be your email address, but there shouldn't be a password. But anyway, I can help you screen for questions and everything. Okay, I thought I'd mention that. I can monitor on Twitter. Yes. The ability to do something without turning it into a boil the ocean without worrying about perfection. My official company motto is G-E-F-N. Which is for good enough for now. Yes. We use done for now. I used to ban the word done because nothing's ever done in the business world. Let's do lots of stuff. So you use done for now. It's not for now. Let's do this for now. When I was working in Belfast and I shared my good enough for now, and somebody said, oh, around here we use U-B-A. So I was thinking, well, gee, it's nothing. U-B-A. And that was ugly but adequate. Sounds like a good philosophy for life. That's right. And anyway, a few post-its and a few definitions go a long way. Yeah. Yeah. So I think like looking back over my career and how we started doing the whole information engineering and it was very, it was more iterative than how it was taught. It was still a lot of big upfront modeling and it was to build, to start documenting architectures from a very strategic point of view for a company, which is why it was that way. But most of the work I do lately isn't strategic stuff. I do have some strategic stuff. But because I've been stuck in these troubled projects, which means people don't really realize they're in trouble until they're trying to actually build something. Because I've been just floating along building model models and building code and they haven't tried to actually figure out what their data requirements are yet. And that's why they can't get the answers out of the data they did find or created or captured and their answers are wrong. One of the things that I like to do is that when I look back, though, the way I work and the tools I use and the type of elements of quality have really changed over the years. And if I went back to the 1990s me, she would probably be horrified at these small bundles of work that I produced and couldn't instantly map them back to a giant enterprise model. But as I come at it from me, that's not what my current project needs. Like my current project, like one of the projects I worked on had a $1 million a month penalty for every month there was delay. I was going to pull off and start doing a master data quality initiative and start aligning their business, their BAAs, what were those called? You know, back to some strategic plan. That's not where we were. We were fighting a fire at a million dollars a month, you know, with the other value at some time when we've got the fire under control. I think, you know, that's not a balance. I'm doing, yes, I'm still supposed to not use the word but. But I'm still doing a lot of strategic projects too, like the newspaper. That was, I mean, not to bet the business kind of initiative, or something I've been working on in higher education is really strategic. And you still have to get people talking the same language. There's always, whether it's something very tactical, I haven't done anything with a million dollars a month penalty without any attention. But whether it's something very tactical or something strategic, I'm still, there's no substitute for doing a little concept modeling and getting people talking the same language. Absolutely. Like the first step in the yearbook projects is to do that. You're absolutely right. If I look at the time I would spend, 20 years ago, 20 years ago me, at the time I would spend analyzing over the data model. He has shocked me now. And in lots of cases, in lots of cases the work I do, people are quite happy not to even have me put my findings in a tool. Like I don't necessarily have to put my process models into some BPMN compliant tool or my data models into a tool. They're perfectly happy with photographs of the post-its and flip charts to photos into a PowerPoint deck so they're easily transportable. And that's good enough. I think we've had that discussion once on Twitter. And I think from our point of view, that works. Where do I find that works is, again, in that strategic, more enterprise, more business-oriented reason you're modeling. Like when people ask me questions about, you know, does the data model do this or do we need a data model? I mean the first thing I have to ask them is, what are you trying to accomplish? Because, you know, when I'm on a troubled project that's trying to build an actual functioning service or set of software, I need to build data models that can now really generate DDL and do that. So if I just did the whiteboard or the napkin or the PowerPoint data models, which I've worked with data modelers on these troubled projects, that produce a data model, use a data modeling tool, produce it, embed models in a Word document, and hand that over to their DBAs. And all of a sudden their DBAs think they aren't adding a lot of value. It's ironic, right? So it really, I think one of the things that frustrates a lot of people is we keep talking in terms of the data model. And I don't really think, you know, any more that there's one even process model or business model or conceptual model, those all kind of have just no one billing architecture diagram. I mean you build specific diagrams in the architecture, the physical architecture world for different reasons. Right. And I think that's where, you know, our recent experience would diverge. So I'm not in cases where I'm expected to actually, you know, put something together that can transform into DDL. I guess I am more often working at the more strategic end. Or honestly, most of my work is in large-scale process change. Yeah. Just getting people talking the same language is a big deal. And I suppose those things are valuable, right? Definitely. And going back to, you know, how do we add value to data modelers? I think it's taking more of a marketing-based approach and going out and looking for situations where our skills will add value. And, you know, one thing that I would recommend to people, it's actually what I would recommend to people is that they read your blog from January on seven tips for staying relevant and valued as a data modeler. Thank you. Just thought I had to mention that because according to Shannon's introduction, you are esteemed whereas I am infamous. That's excellent. There was a few things from that blog that I had starred. You know, number seven, build a data modeling process that allows you to produce releases quickly. I mean, modern world speed is of the essence. So, as I've said, if you can't figure out how to do something useful, you know, an initial concept model, you know, a short period of time, 90 minutes to three hours, then you've really got to work on that. And you also said get experience data modeling for integration projects and learn how to correctly reverse engineer application databases. So, let me just dive in on that. Sure. So, this is a lot of value that I've been able to add. But, or Collins had told me I've added terrific value through reverse engineering. I've been building golden physical structures, abstracting it back out to the logical model, and then up to a business-friendly concept model and then bringing that back to the business. And not necessarily calling it a data model, as I've said repeatedly, just saying, well, here is how your current application sees the world. And the usual reaction is shocking off or sort of understanding of, oh, that's why we hate it. So, after one of my data modeling workshops, I always tell the participants, the most valuable thing they do in this workshop is reverse engineer a conceptual data model out of the gations or systems they're working with. You've had the same experience. We've been to a company, and nobody has a business-oriented view of the production systems. Yep. Which is pretty amazing when you think about new requirements, et cetera. How do you really assess whether that application is up to the challenge? So, there's one piece of advice, and let me just dive in with another, and that is how to use your skills in the world of packaged applications. Right. Right. Because I have done a lot of work over the years helping companies understand why they hate the package they selected. And it's virtually 100% of the time. It isn't the UI. It's not even the logic. It's a data model mismatch. The way they see the world is not the same way the package sees the world. Yeah. I guess we could also mention outreach. Like, tonight I'm doing a presentation for the IIBA here in Vancouver on concept modeling. Those are business analysts, right? The business analysts, exactly. Yep. I mean, that's who really can use these techniques, so we've really to do some outreach and show them in a practical way just how useful this technique is. And an example that I'm going to be looking at in this presentation was for higher education when just a few minutes of concept modeling in the management arena helped articulate a concept model or a data model for them. And it was a major concept in there that just was not present in the application they're looking at. And that's the kind of thing that people figure out in the game instead of early in the game and would really help out in that arena. So, like... Oh, go ahead. I was going to say that the package saw courses and classes as a two-level hierarchy and the university saw it as a three-level hierarchy. It was this middle layer that was the intent to offer a course to meet certain capacity at some point in the future. And that concept just wasn't even in the package. And these are the kind of things where we can really highlight these gaps in one view far more effectively than just big requirements. To asking people and getting 20 different answers. Yes, the analyst is a stenographer. Yes, oh yeah, we've had that one. So what I'd like to do is take some of the questions that I have in the Q&A. So one of the questions is, isn't it good enough for now dangerous if you never get back to making it right? For example, siloed, redundant, or any of the other 10 biggest mistakes? Nope, not at all. Because good and... No, good enough for now is how you get people engaged and how they start to see the value of this perspective. So I guess I could agree if you never did make it any better. But the point is, good enough for now is like a client set of stairs. You do it one step at a time. It'd be nice to leap to the top all at once, but we can't do that. So I think it's far greater danger in trying to get things perfect too soon rather than doing something useful in the immediate timeframe. Yeah, I really agree with that. And finding that balance is hard. You need experience. That's why most... I mean, that's the ongoing question for all architects and all designers. How do you know when it's good enough for now? That's the hard thing. Through experience and with mentoring with other people, I work with too many architects, especially data architects, who are just trying to reach perfection and they're losing their entire team because their entire team is moving on. Exactly. They're climbing the stairs. Yeah, they're climbing stairs. And one of the great things about how you get the opportunities of doing things is that it has a disciplined approach to good enough for now, is that you can put things in a parking lot and they can practice and then there's someone responsible for making sure we don't forget them and you can report on this thing was taken out of scope or we agreed to go forward with this defect or use cases to educate. And that's something we need to learn from the agile process is that, yeah, it's a trade-off, but oh my gosh, it's such a wonderful trade-off. Yeah, and when you get involved in a truly agile initiative, you realize, oh, this isn't like, you know, a lot of companies adopt fragile as opposed to agile. It's just a nightmare for quick and dirty. When you're in a truly agile environment, there's not a lot of discipline and rigor. And that's what I wanted to talk to in the idea that good enough for now doesn't mean being flaky. I teach people constantly in my workshops that if you have a framework and techniques and you follow them with a degree of discipline and rigor, you can get a lot done in a short period of time. It's overdoing it, but it's not flaky of the other extreme. Exactly. So the next question is, so we've had a couple of these in chat and one here about how do you reverse engineer a COTS product, meaning a package? With great difficulty. Yes, and that's something that's going on in the chat. So of course, you can reverse engineer the database by pointing tools to it and getting pretty pictures of it, which as some people point out in the chat can be problematic because packages are usually highly generalized designs because they're trying to solve a data problem in the world in that space, as well as also designed by many different people over several years with not clear architectural focus. So there's usually a lot of duplication and nasty data design approaches. It's hard, right? So in the sort of mid-90s, it was common for these large ERP packages to come with not just reverse engineered data model, but sort of a logical data model of the package. And I think those have kind of gone away. I don't run into those anymore. I haven't seen that. And sometimes it really is archaeology. I coined the phrase systems archaeology 20 years ago to coin it. I'm sure other people have said the same thing. But I have had cases where it was really simple because the vendor had a native SQL server implementation that was no urgent generalization. And it was pretty easy to pull that back out to something I could present to the business. In other cases, you really have to do a lot of inference. It means it's getting a test version of the application and testing behaviors and from that, inferring the data model. And it's way more time consuming. But it's really essential. I think that it is. So you can tell the business that's where there's a gap. This is where there's overlap. I mean, I've had cases here in Canada where we had to point out that there was functionality in this large sort of HR system that actually was illegal in Canada due to the different employment laws. And you kind of want to point that out. And they had a rule of we're not changing the package at all. That was a rule. And then I'm like, well, you might want to change these few things because they're actually, and I know just a tiny amount about labor laws here, but it wasn't the obvious things that I know for sure aren't legal. And so, you know, it was examples like random drug testing and some hourly management things and some benefit things. And it's kind of like, gee, I think maybe I had a budget some time for at least not a jail. Your number one goal is to keep your CAO out of jail is a good goal for an architect. In the process world, I'd like to point out that what you're trying to do is keep the company off of the Consumer Affairs Show on TV. Which we have some good ones. You have the archaeology term. Oh, go ahead. Oh, that's an interesting experience as lately where companies did end up in a very negative light on the Consumer Affairs Show. And it was a business process issue. Yeah, yeah. Usually, right? Because usually the processes aren't completely automated, so they involve that horrible human factor. Right? And it's all, you know, if we... I know it's, I guess, off the topic here, but my framework for looking at business processes is don't just look at the process design and workflow. Look at the human elements like policies, motivation and measurements, human resources, and that's where things break. That's another topic. Yeah. Well, I once sent my bank, my former bank, two different process models for doing something with my credit card. And I showed them how they had this most 16-step process that my other bank only had one step for me to do. And I sent that when I complained about they were having some issues legally with what they were asking me to do. And then I pointed out how often... I did get a nice letter back saying, when's ever sent us a process model? And I'm like, you need more of this. I volunteered once on a customer service call that had been escalated a couple of levels. I had volunteered to come down and map out the company's process. And they... I think that I was serious, so they actually solved my problem. We'd hop on a plane for that one. So we were talking about the world of COTS, you know, like reverse engineering. Let me just briefly relay a story. I've written about this one before, just to show how data modeling can fit into that environment. I had a company many years ago that was about to implement SAP. The business people, the plant management people called me up and asked if I could come out and do that thing I do, which is music for the years of a consultant. And that turned out to be data modeling. And they wanted it. It was the last time I'd been out doing that. They all felt they understood their business better. And it turned out that because their CEO had told them they had to implement this thing called SAP, they thought it would be a good idea if they all got on the same page. So I went out. We spent two or three days building a conceptual model of their business, plant management, plant maintenance, and so on. And they used that as the framework, the architectural framework for implementing and configuring SAP. And they realized that that was the most valuable two or three days in the entire project, and they became a global reference account for SAP because they had that integrating framework that only a good concept model can provide. So this was the case of going in and reverse engineering the package. This was a case of the business saying, here's how we see everything fitting together. Let's not make any bold headed configuration options that break this. And they didn't. Yeah. I think that's the hard part about these very large packages is, one, they're so expensive and they cover such a wide breadth of functions, business functions that they're not understanding, you know, that there are minor differences that you might be able to live with or these much bigger larger differences that you need to identify early on so that you can find a way of dealing with it. If you're like, I had a client that had a huge physical infrastructure, you know, spread all over a province, and they kind of then handled the SAP concept of a site properly. And they just paid for that for years. And honestly, a little bit of concept modeling early on in the game would have shown how important that was. Yeah. Yeah. And I mean, there's lots of stories about that. So, you know, we as a data profession, we should talk more about sharing these experiences. I mean, I do this a lot at conferences like EDW, like Enterprise Data World. I mean, that's one of my primary reasons to go to conferences like that is so that I can ask questions and stories and everything with people who are living in the same world I am and dealing with the same struggles. And I mean, to me, that's the real value. That's why, you know, I don't think in person people go to a city, you know, go eat conference food for a week. I don't think that's ever going to go away because none of these virtual things are going to replace that, even though I'm saying that right in the middle of my webinar. But I mean, that's the best thing. Why aren't we doing more besides having Enterprise Data World about sharing this stuff? Like, I feel like our community does it the least. Like, we have very few bloggers. We have very few people on tour. Why do you think that it is? You know, I just don't get it. I wish I could answer, but it goes back to that work I brought up earlier, which is outreach. We just, all I can say is, boy, it sure has worked for me. You know, when I built my first data modeling workshop, that was the first course I put together. And as you know, every occasion is a big part of my business. I get four or five continents a year under my belt delivering these workshops. The first one I developed was data modeling back in 1986. And I sat down and I thought about it beforehand and I realized my audience was not data modelers, data architects, DBAs, data administrators, etc. My audience was business analysts. I needed to put together a data modeling course that would help them do a better job. And also, this sounds a little cynical, but that also meant that the potential audience for my workshop was an older magnitude or more larger. So it's worked out really well. And I think my mission in life almost is showing people how this modeling techniques, whether it's requirements modeling or process modeling or data modeling, can really make people's lives easier. But we just got to get out of the... There's some value in things like EDW. I'm really looking forward to this year. I have more at the EDW conference than at any other conference I go to. It does a brilliant job of putting together different threads and disciplines. I'm speaking on data modeling for the IIBA tonight. I've spoken on data modeling at business process conferences. It's just something we need to do. So, for instance, I've been active, again, because I've been more focused on the physical side of modeling or the logical and design side. Let's say that. That's why I go and speak at SQL Server events, or I'm going to speak at TechEd North America coming up. It's because that's a whole new audience that has very little exposure to relevant, valuable data modeling artifacts and why they need to do it. It's hard for me to begin to those because they all run screaming when they hear the word modeling, and they think I'm going to talk about first, second, third, fourth, fifth normal form, which is not really what I talk about at all. I talk about really practical reasons on why people need to love their data. And to me, that's something we should all have in common. I think on that note, well, two things. When I tried something along those lines, even at EDW, Tony asked me if I could, because once I'm to an updated version of presentation called the human side of data modeling. Yes. Really, just a whole bunch of techniques and case studies on how to get people engaged in this thing we call data modeling. The other thing is, even though we're in the age of big data, social, mobile, presentation data, I find I have some success when I don't use the word data because that just raises all kinds of assumptions. Like I said, I don't typically call it data modeling. Often I don't even call it anything. I just do the old Nike methodology. Maybe. And when you do that, you can get people engaged. And when they're engaged and interested in contributing, then you can start to introduce some of our terminology and adding more regular. So that's the saddest thing I've heard in all these webinars. And I so understand where you're coming from. And I feel like, I mean, I have to resort to the same things, like when I show people on a project that I'm just trying to gather these, I mean, even saying the word requirements, people hate because it's a tough thing to do and most builders don't like those things, do that work. And I say, no, no, the good news is, I love doing this. It's frustrating, but I love doing this. So I'll take this job. Use the job of making it work fast. I'll try to hold you accountable for making it work right and we'll work together. And, you know, I don't want to run scripts on a database all day. I don't care how the sands can be feared. I want to trust that you're passionate about those things. Let's be a team. I think, though, that, you know, are we really just paying for the sins of all the data modelers and architects and process modelers and process engineers and all of those things because they couldn't figure out how to be relevant or how to explain the value and that we're having to... Unequivocally. ...highly who we are. It's so fair. Well, I'm not hiding who I am, but I'm judicious with my terminology. And let me put it this way, it's not just in the data world. In the business process world, there are many environments where I just do not use the word process or business process. Because people don't... They just don't see themselves in those terms or more than they've been burned. That's what you said, that we're paying for the sins of somebody else. So I often avoid the term requirements because business analysts have the endless list. I've seen documents with eight or 10,000 individual requirements. Well, I'm going to disassociate myself from that. I'm going to disassociate myself from people who are doing orderly, rigorous, and technical oriented business process work. So I'll avoid those terms just like I avoid data modeling because it's a term. Yeah. And I think... So the other term, so I grew up, I was a methodologist, right? That's the ultimate bad word, right? Especially in the agile, grum world. But that literally is still what I'm doing because what I didn't do was say, here are the 400 paper deliverables you need to make. This is what a methodologist does. It was helping people find right tools, techniques, models, approaches that made sense for what we were trying to accomplish right now. Absolutely. And here a few times, was it ever all 400 deliverables? It was like, Yeah. I mean, everyone needs to do a project charter, maybe not formally, but write down, here's our goal, here's who's going to do it, and here's when we think we're going to have it done. You know, agile people will run from a project charter, but they'll let me write down all the things in a project charter and say, hey, that was good. He wrote that down. Precisely. So again, the terms, we've been burned by people going overboard with requirements or process models or data models or project charters. We still need to do that. And we keep coming, I keep getting into situations where people don't understand that there are these different levels of detail. So we've got contextual models, conceptual models, logical or detailed or specification models, and finally physical models. And there's a lot of fear out there with people who have only ever seen that detailed or even physical level of model. Yes. Yes. When we're really adding value, we're out there at the contextual and conceptual levels. That's why I did a presentation, I think the first one was close to 10 years ago called the Lost Art of Conceptual Modeling, which was my way of pointing out that in our field, people have lost sight of what a conceptual model is. I find the majority of people in the day to field, a conceptual model to them is just a slightly toned-down logical or specification model. In fact, it's really radically different. Yes. We've even made the distinctions over the years. Initially, we called it a conceptual data model, right? And now we call it a conceptual model to try to reinforce that it's something quite different. Then, sort of the information engineering approach of it was just really your boxes and lines with no cardinality, right? I mean, that's certainly how a lot of people taught it, and that was incorrect, but there was that. But all the boxes were still there. Yes. Or maybe there were only 50 of them out of the 300, but it was just some sort of sub-sum of your anthropological model or something like that, right? So we have this really big question in the Q&A is provided a recap of the value of data modeling. So go. The value of data modeling is that it provides a technology-independent view of the business. And again, I'm going to push back on calling it data modeling. It provides a way of seeing the things that Agnes works with, the things that their processes and applications deal with. And that is a very unique and valuable perspective to be able to add. Because most of the time, people haven't seen that. I'll draw a parallel. I did a process architecture for an organization lately, and the high-level, the high-level of the process architecture, absolutely thrilled the C-level executives because they had never seen a picture of what their organization does. They had seen because of how it's organized, but never what it does. A data model can accomplish the same thing. It's a picture of what the things are that the organization deals with and how they fit together. And I think that definition shows your point of view of what you've been doing, because you have to throw in that the data modeling I do on, like other projects, I have to do project-specific, getting to design data modeling as well. And it's a completely different thing than what you just talked about. And I kind of circle back to where we started is that we're our own worst enemies because we don't have a sort of humanly-understood set of terminology and their descriptions. Like the de-body of knowledge from Dama tries to establish that, but most people don't have access to that and don't use those terms. And I think that's the hard thing. So what you said is absolutely true, and I do that type of data modeling. Matter of fact, I'm doing that with a client right now. One of the things that has pushed me, not pushed me, but invited me back to the strategic data modeling and the more business-oriented data modeling, is now that organizations want to get into business and data analytics because they don't have this sort of common understanding of the concepts and the data that they have right now and what they're going to need to get to the analytics they want and the answers they want. They realize that they have this need for not just enterprise-wide data modeling or logical modeling, but as business models that focus on the concepts and then eventually get to the data. And I'm not going to call those conceptual models or logical models. I'm just going to call them models or analytical models, and we're just going to end up drilling down and then comparing them to reverse-engineering physical models and try to get them to get the questions. They need to ask the questions and find the answers and then just see that with spreadsheets, I think. This is why you're pointing to your blog. Can I plug your blog once again? Absolutely. Okay, number three. Okay, I'm sure you'll share the link to it later on. Get experience data modeling for integration projects. I've sometimes involved in a situation where I had to show people that they're trying to integrate data from these disparate environments and each of them has a different view of the world. And until you can demonstrate that, you know, an understandable picture up and say, well, here's how marketing sees the world and here's how accounting sees the world and here's how operation sees the world. And you can't miss that they're all different. There's also something I've done a lot with when companies decide they hate the application they chose. It's really moving forward. Here's how you see the world. Here's how the package sees the world. See the difference? Yep. I mean, I hate that. I really wanted to make sure I mentioned today and that is I've heard people for years say, well, how do I convince management that I need to do this? Or how can I convince business analysts that they should be doing data modeling? And one of the best decisions I ever made was 15 or 25 years ago, I decided to eliminate the word convince for my consulting vocabulary and replace it with demonstrate. It's a real cool idea, but how do we demonstrate the value of doing this? You can bang on people with a big stick trying to convince them of something. It's really a lot less painful and more productive just to demonstrate. It means you're going and doing something real, but it's an idea that has served me well. That's a really good life lesson as well. You can tell people you want to if you show them, they'll come along. I think I've blogged about this somewhere, but I definitely have told this story in my workshops about people, data modelers always come to me as like, how do I convince the developers that they need to use the data model? And that is completely give up on that. No, give the DBAs and the developers what they're asking for. Now, that doesn't mean do it the way they're asking for it. But if a developer or a DBA wants DDL, then they can be valued by them. You have to get them to DDL even if you don't do it. If the developer just wants you to go figure out what the DBAs means by double declining balance in their depreciation requirements, go help them do that. The developer is not going to take the time to go understand that. You go do it. And that's really demonstrating. But the other big thing is I tell people, focus on convincing the business people that's valuable and the business people will ensure, yes, yes, demonstrate, but that's how you convince them. You demonstrate, right? So you're demonstrating to the business users that it's valuable. They will make sure that the developers have the right motivation to make sure that you get the resources you need. And it's not just the developers, but it's IT management. If you remember the time when a business user, you could see the light bulb going off in his head when I started a new project and brought all the models he had just worked on for another project. He goes, we get to reuse those? Yep. It's going to be a lot faster. Yep. While he turns to the lead developers like, why didn't you bring your models? And the developer said, but it's a new project. All the models, all those UML models we did, we're going to use a lot of those. He goes, no, no, new project. You don't want the burden of another project. And he's like, go get the models. So you want your users, your business people to say, where the heck are the models? And that's what I work on. And eventually, it all comes along. Yep. So you might just have space to do something of value and you'll get your reward. And that is really the essence of our conversation now. You're going to be more valued and more relevant by being more valued and more relevant. Right? By acting that out. Yes. And just up out of the weeds and, well, I guess I've made my point already. Yep. Let's go there again. Yeah. So do you have any other interesting questions lurking out there? Well, yeah, because we're getting close to the end. So what's coming next for you? I know you're working on, but are you doing some speaking and you talked about tonight you're doing stuff, but what's coming up in the big picture? Oh, boy. I've got a lot of kinds of things going on. I'm excited that I'll be doing this concept modeling for the business analysis group here in Vancouver. I'm also, I'll be back at Enterprise Data World in April for the humans data modeling. Yes. I'm back. I'm down in Portland for the IIBA business analysis there. This time, I'm talking about going from process model to IT requirements. So it's going to be a big chunk of the value of data modeling in that. I'll be doing my usual business process classes in various places in London and Helsinki. It's been a big tour of Australia and New Zealand. That's coming up again. Wow. Actually, I'm looking at my speaking schedule and most of the events that I'm speaking at are business analysis events. Yeah, good. They're going to be talking about data modeling and process modeling. Excellent. Doing my outreach thing. That's good. I want us all to do more outreach. And I blogged on Data Diversity about data architects and modelers are null in the blogging world, meaning they don't exist to the world. And so there's a good blog post out on Data Diversity about that, so I won't take up time with that. And some of the things that I have coming up, I'm going to be speaking at the Buckeye Daima chapter, which is Columbus, Ohio, just in early April. I know. And I'm also doing a panel at the Business Analytics Conference in San Jose coming up. That's a past conference. It's going to Las Vegas, Sequel Saturday, TechEd, North America. We're going to be talking about Hadoop and business intelligence and all kinds of fun stuff. I'm going to do Sequel Saturday, Houston, which is right before TechEd. I hope I run into a bunch of astronauts there. And for EDWU, which is coming up, if you're a Daima member, you can ask your Daima chapter for a discount code to go register. So that's one of the benefits of being a Daima member. And I have some other Sequel Saturdays and other events coming up. I've applied for a lot more. I have some NASA stuff coming up. I'm so excited. But that's bringing us to the top of the hour. So one of the things we do, Alec, is stay on afterwards that we turn the recording off and we'll stay on after maybe for about 15 minutes and try to get through maybe some more of these questions. Is that all with you? Okay. Can I just give you one quick piece of advice when you go to Columbus, Ohio, remember the Ohio State University. Well, as a Boilermaker, I might allow that. And if you get an Ohio State University t-shirt, you can wear it anywhere in the world and people will come up and talk to you. Excellent. I don't know if that's all. I know this from experience. Okay. Excellent. So, Shannon, do you have some amazing things? I'm going to leave Karen and Alec. Of course, this was a great conversation. Thank you so much. And thanks to all the attendees, as always for being so active and engaged in the conversation. I will turn the recording off here. And just as a reminder, I will get links out to the recording of this session, a copy of the chat that's been going on. And thanks to Alec and Karen for the many mentions of Karen's blog and to Edie Debbie. I'll make sure you have a link. So, here's the recording is shutting off, Karen.