 Oh, I love it when that happens. It's almost as if I planned it, which I can't take credit for. But hello and welcome. My name is Shannon Kemp, and I'm the Chief Digital Manager for DataVersity. We'd like to thank you for joining today's DataVersity webinar, Data Architecture Strategies, Constructing Your Data Garden. The latest installment in a monthly series called DataEd Online with Dr. Peter Akin, thought team partnership with Data Blueprint. Just a couple of points to get us started. Due to the large number of people that attend these sessions, he will be muted during the webinar. If you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the upper right corner for that feature. For questions, we'll be collecting them by the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights of questions by Twitter using hashtag dataed. To answer the most commonly asked questions, as always, we will send a follow-up email to all registrants within two business days, containing links to the slides. And yes, we are recording, and we'll likewise send a link to the recording of the session as well as any additional information requested throughout the webinar. Now let me introduce to you our speaker for today. Peter is an internationally recognized data management thought leader. Many of you already know him or have seen him at conferences worldwide. He has more than 30 years experience and has received many awards for his outstanding contributions to the profession. Peter is also the founding director of Data Blueprint. He has written dozens of articles and eight books, the most recent is Monetizing Data Management. Peter is experienced with more than 500 data management practices in 20 countries and consistently named as a top data management expert. Some of the most important and largest organizations in the world have sought out his Data Blueprint expertise. Peter has spent multi-year immersions with groups as diverse as the U.S. Department of Defense, Deutsche Bank, Nokia, Wells Fargo, the Commonwealth of Virginia, and Walmart. He often appears at conferences and is constantly traveling. In fact, he will be at our upcoming enterprise data world here in coming up in April, so check that out. Peter, it looks like you have a guest speaker today. Let me turn it over to you to get when I started and introduce our guest speaker. Hello and welcome. Thanks, Shannon. I have not actually seen your new title, so congratulations for that. We still had you down as Executive Editor. Chief Digital Manager, is that the right one? That is. We did not want to confuse it with CDO, so you know. That's an inside joke for those of you listening. So with me today, I've got Brian Hogan, who's going to talk a little bit towards the end on a specific case study that he's brought up. Brian is a data-fied consultant and he's a certified data manager professional and has lots and lots of experiences you can see. And one of the stories he's going to tell us today is something that we've been working on for quite some time here. So good day, everybody. We'll start out with our sort of standard bit. Data is today's most powerful, underutilized, poorly managed data asset. It is the only asset that you have. It doesn't deplete, it doesn't degrade, it's durable over time, and it's strategic in nature. So when you compare data assets to all other assets, the data assets win. Another way to think of it is many people say data is the new oil. We think that's actually really wrong. And if you add another letter out there, data is the new soil. That's actually a little better way to think of it because you plant good things in it and good stuff will grow. Anyway, collectively what we're all trying to do is to put together better data management capabilities for our organizations, provide solutions that are appropriate to where our customers are on their data journey to build lasting partnerships back between business IT, data community all the way around. The topic for today, as Shannon mentioned, is data architecture strategies constructing your data garden. And what we're going to talk about in particular is looking at the context of how all this works out. Then we're going to dive into why is it important. We'll talk about leverage, and leverage is an engineering concept. So we'll talk a little bit about engineering. Then we're going to give a non-government organization. That's the NGO abbreviation that's to see their case study that Brian's going to present to us. I do like to start out with a particular bit, though, which is just to let folks know that even though Scott does a phenomenal job of pulling all this together and he's so accurate, this is actually a very old one. It says Alice, we have a new corporate policy. And I quote, says the PHB, pointy-haired boss, initiate the description of the criteria for requirements by developing a framework for the application architecture consistent with the planning quarter specified in our strategic initiative. Did you get all that? He asks Alice. Remember Alice is the hard-working smart engineer. And he has to go out and pull Wally. And they say, read this and tell me if she's doing any of it right now because they just don't understand what it is architecture does. Now we'd like to talk about this from an architectural perspective as the fun things that people want to do with data really fall into what we call the golden triangle there. The only thing that's different in this chart I've been using for more than 30 years is that we've changed the labels that are in there as different buzzwords come and go and certainly these won't be the last ones. But that is just the tip of the iceberg in terms of what's happening and that there are these foundational practices that you need to put in place. And these foundational practices also are only as strong as the weakest link of those foundational practices. So in the example that I'm showing here, if we don't put more into data platform and architecture and get it up to the same level that governance quality strategy and operations are at, it won't do any good and it will be a waste of your organizational resources. Now the top part of this is focused on technologies. The bottom part is focused on capabilities and what we find over the years is that it's much more important to develop organizational capabilities than it is to opt for particular technologies. People nevertheless call us up and ask us on a regular basis, yeah I hear all that Peter but I've got to get this stuff done by Friday. Yes, but it will take longer. It will cost you more. It will deliver less and it will present greater risk to the organization. But instead you learn how to do this in a proper fashion. Proper fashion is to look at these foundational practice areas that I showed you before and realize that managing data coherently, that governing your data professionally as an asset, that finding what an optimal or fit for use data purpose is, that looking at whether you're using the right technologies and the right tools to do this are going to be critically important and having the supporting processes all help us to get there. Another topic entirely we'll do one of these later on in the year where we'll talk about how to evaluate your progress around each of these areas in order to do this. And of course data architecture management is the top of the dim box that we have here labeled in all of that. So let's dive in and talk about architecture. Now architecture is kind of simple, although it really isn't. And I don't want to oversimplify and I'm sure we'll get some good questions as we come to the conclusion here in an hour. But architecture is all about things and how those things work. In other words, what is the function of those things and how the things that all work together actually do interact with each other. So the filliness aside from that, if somebody asks you a question about architecture and says, well, why do I need to have it and understand it, say, you know, do you want to understand the things that make up this architecture, whether it's an organization, whether it's a building, whether it's a car. Yes, cars have architectures. And you need to understand how the functions of those things work within there and you understand how they interact. Because if you don't understand all three of those things, it's virtually impossible to make any of it better. So let's look at a definition for architecture management. It's defining the data needs of the enterprise and designing master blueprints to meet those needs around each of those. And in our DIMBOK, we have one of these each chapter, which is the sort of input-process-output diagram here. Again, we're just getting some context. But you can look and see there are primary activities, understand the enterprise information needs, develop and maintain the enterprise data model, analyze and align the other business models, maintain the data technology architecture, the integration architecture, the DWBI architecture, and enterprise taxonomies and namespaces, as well as your metadata on all of this. There's some specific inputs on the left and primary deliverables on the right. And you can see the participants in tools that we use as well. This is a generalized overview that we'd like to present to these people. So let's dive in a little further and talk about what is architecture. We get a couple of definitions. First one is a process and the product of planning and designing, constructing space. Now, they talk about space. We're going to talk about conceptual things as well. But the idea here is that we need to have functional social and aesthetic considerations. We might have the nicest building in the world, but if the entire interior of the building was unlit, it would be a problem for us. And so we would not be able to use it necessarily for things other than sleeping. And their second definition is it's all design activity. People talk about architecting things as an architecting an urban landscape. Those of you that are familiar with the northern Virginia area know that Tyson's Corner has been architected and re-architected many, many times. When I grew up up there, it was just a feed store. Now, of course, it's one of the largest urban centers out there in the world. And finally, architecture today may refer to almost any kind of system design activity. Big D design used in the IT world. More important than that, it's really critical to understand that all organization systems have architectures. One of the things that we get here at Data Blueprint, occasionally, somebody will say, well, can you build me a data architecture? The only time you don't have a data architecture is when you don't have any data. So all systems have architectures. The question becomes, do you understand the architecture that you have? Do you understand the things, the function of those things, and how those things interact? And if you don't, they can't be useful to you. So in order to obtain leverage around your architecture component, you need to document, understand, and make useful the architectural pieces that you have. Here's a couple more definitions around all the symbolic references. Hey, sorry, Sarah, you'd interrupt there. Just a couple of things. You're kind of breaking up a little bit, and there's a bar across the top of the screen that it looks like you've got a couple things open that's blocking the slides. There. Two little... The better? No, there seems to be something overlying the slides, and I still see it now. Absolutely no idea where that would be. Let's try and shift the... It looks like you just have something... No, it looks like you have something open that maybe... No, I'm kind of... Nothing open. Sorry. Sorry, I'm sorry for the interruption. You were just getting going. Yes, warmed up, but hey, I always wanted to be a good chef, so we'll get that. All right, nothing is open now. I'll try that. No, it's still showing. It's still there. Do you have a chat or something open in WebEx? No. All right. Stop sharing. Probably reduce the risk of pollution again, or increase, I should say. Good discretion. We have never had that before. No, you know, it's a new year, and you know new challenges. Yeah, exactly, still there. Oh, fine, you know, before you go through this. Yeah. Protests always work perfectly. All right, we'll get a little closer to the microphone. We've actually got some good microphones going here, so I'm not sure what's going on with that either. Thank you for letting us know. The connection is kind of sounds like you're underwater. It's not completely inaudible, but it's... All right, we'll give it a try. There's no visual now. There's no visual. You'll have to share again. Little things. How about now? Lovely. All right. All right, good. Thank you. So where we were was talking about other definitions of architecture, and really the key to it is when somebody wants to see the architecture of whatever you're talking about, you don't want to show them all the nuts and bolts. You want to show them something that is a symbolic representation of it and that those components should be done using a standardized notation. The standard notation is what allows some heating and air conditioning vendor to come into your organization even though they've never been here before. Look at the blueprint and figure out what's actually going on from a heating and air conditioning perspective. Now I'm hoping that everybody's translating these in their minds into data pieces because when somebody comes into an organization and says, I need to gain access to certain pieces of data, you'd love to be able to pull out a blueprint and do that, but I've got a room full of consultants here and have you guys ever walked into an organization and seen anybody have one of these things? I'm not seeing any hands grow. Of course, if they did, they wouldn't be hiring us, right? The other thing is architectures also then need to be a balance. It's sufficiently detailed to permit both business people and technical people to read the same model and come away with a common understanding. Now those of you that are listening know that Shannon and I are both musicians and we, when we're playing music, have to be singing off the same sheet of paper or it sounds terrible. So when we talk about understanding architectures, what we're talking about is getting something documented as a digital blueprint that illustrates the commonalities and the interconnections of the various components that are there. The idea is to get that shared understanding by the systems as well as by the humans. So let's look at a couple of organizational architectures just to get started on this as well. These are kind of tongue-in-cheek, but they actually make a little bit of sense. So when you think about Amazon, people tend to think of Amazon as a very hierarchical thing. You can either look in the bookstore, the shoe store, or the electronics store, or the kitchen store, whatever it is, and it's organized fairly nicely and people understand the way that works. When you look at Google, it's a little bit different. It's got sort of the team of three at the top, although we know we've changed that structure slightly too, but everybody still thinks of the two founders and Eric, of course, coming in as well to do that. And their Facebook, it's all connected, right? Everything is connected to everything else in one form or another. With Microsoft, I love this when they've got done shooting each other because they trip over each other sometimes. I can tell from personal experience that has happened occasionally with them. Apple, of course, had all revolved around one person and, of course, that was the mantra there. Oracle is simply a matter of we've got engineering on the right-hand side and then the legal team on the left-hand side. If you haven't had that experience or don't get that joke, consider yourself really fortunate. Organizations then manage a number of different types of architecture. It could be from a process architecture, a systems perspective, a business perspective, a security perspective, a technical architecture. Somebody said that should be called a tar architecture. Okay, whatever. We're going to talk about it today from a business perspective, focusing in on the data. Now, the problem is if management doesn't understand what these architecture groups are doing and what business value they're adding, they'll think of it just as a series of technical committees. Now, many of us have worked in the standards world and that is a tankless task. But if management doesn't understand what the value of architecture is, they're going to have a hard time continuing to invest in it on a long-term basis. So it's very important that everybody put out there what it is that these architectures are doing. And Shannon mentioned at the front that we've done a lot of survey work around this and of more than 500 organizations that we've done, only 10% of them actually manage any of these architectures and only a tiny handful actually manage multiple of these architecture simultaneously. What that means is that the vast majority of organizations that are out there don't understand their data, their process, their technologies, other architectures that we have in there, and therefore they can't make use of them. And it means they're kind of problematic. Now, if you're looking for a good differentiator, those numbers are terrific because it means your competition is likely in that 90% category, whereas if your organization can get out in front, it's something that you can obtain a sustained competitive advantage with. Now, I've had many friends over the years that have tried to give me definitions of information architecture, and I hate them all. Let me go back up to the start here again. I want you to imagine yourself on an elevator pitch where you get on the top floor of a building and the boss looks over at you and says, oh, you're an information architect. I always wondered what it was you did. And if you tell the boss, well, I developed the underlying information design principles which construction is based, hard to see the business value in that, okay? If you say I make plans guiding the transformation of strategic organizational information into specific information systems development projects, it might actually be correct, but it's usually not true in most organizations. We don't actually guide the development projects. If you say, well, I provide a framework for providing a structured description of an information asset, including data structured and unstructured or semi-structured content in the relationship of those assets to business processes, business management, and IT systems. Again, a correct definition. You've lost the executive, though, at that point because they're not going to quite be able to follow that. By the way, this book here, Roger and Elaine Evendon's book, Information First, is a wonderful book. I hate to say bad things about it, but through definition here, can you imagine getting on the elevator and saying, oh, yes, boss, information architecture is a foundation discipline described in theory principles, guidelines, standards, conventions, factors for managing information as a resource, producing darnings, charged plans, documents, designs, blueprints, templates, making everybody effective and efficient, and productive and innovative in all types of information uses. Now, if you just went to the bottom part of that, said, oh, I help everybody get more efficient, that's actually probably pretty close, but sorry, that doesn't work there either. Even our DIMBOK definition here, which I think is something good enough to criticize, defining the data needs of the enterprise and designing the master blueprints. To meet those needs, yeah. Okay, so Peter, you don't like those definitions. What definition do you like? The boss sits on the elevator and says, what's going on? And you say, I'm developing a common language for all of our systems and our people to speak with? They get that. Even if it's just the universal translator from Star Trek that they pop up in their heads and go, oh, yeah, I'm a universal translator. So you have to have a common vocabulary because data exists at the most granular level of your organization. And that common vocabulary makes sure that the data assets that are stored, arranged, and managed actually mean the same thing as they go back and forth. So that is my more useful definition of a data architecture, it's making sure that the organization speaks with a common vocabulary. We'll add a couple of bits onto that as well. It's a structure of data-based, not database, but data-based information assets that support the implementation of organizational strategy. Again, the book that Shannon mentioned at the top is going to be coming out, hopefully, at the end of the month here, certainly before Enterprise Data World, and you can read more about how that works out from a strategy perspective. The real key is, of course, that most organizations have data assets that are not supportive of the strategies. So the question becomes, how can organizations more effectively use their information architectures to support the strategic implementation? And it turns out there are some people in the organization that you can go to. We will get to them in a little bit, but let's dive in and look at the rationale for this for just a bit. If I've got an IT project, whatever that IT project happens to be, and I have a database and I have some programs accessing that database, then the architecture of that piece can be pretty well defined by the data that is used in there. That would be the focus of the data. But the question is, if you have multiple projects that are going on, when does the brown database communicate with the orange database and the green database? And it turns out there is a significant amount of overlap between those organizations. It depends how well your organization is engineered to find out what the actual amount is, but it's never a small amount when we look at these systems. And so the architect not only has to focus on program A, B, and C where the brown is, but it's actually focusing across the entire domain. It's broader and focused than either software or database architecture. It's on system-wide use of the data throughout the entire organization. It should be focused on addressing problems that are caused by data interchange or interface problems or incompatibility or poor data problems, whatever else it is that's out there. So data architecture is really important because it's poorly understood. The data architect asset value is not well understood. It's not very well explained in most programs. In fact, if you study it in school at all, it's the exception rather than the rule. And it's only indirectly experienced because even though it costs organizations millions in productivity, and our claim is that it's between 20% and 40% of all IT budgets that are out there, that people don't look around and say, oh, you need to fix your data architecture. They look at the system and say the system needs to be fixed. And certainly the data is a part of the system. But no, we don't actually have the ability to do that. I'll give you an example in a little bit of a poorly thought-out software. Actually, it's right here, an extremely poorly thought-out software person. So here's an example that I took with me from my time in the Defense Department many moons ago, but it's still equally valid now. We were doing a bunch of work trying to figure out which system we should pick for the Department of Defense out of 37 systems that we currently had running. In the DOD at the time, of course the answer was we needed one system, but that meant that there were going to be 36 losers if we picked one of the existing systems and 37 if we decided to go with a brand new one. Now, the problem with something like that is that first of all, I started getting calls from all these places Dr. Aiken, you need to come to New Orleans and spend two weeks with us, meeting all 2,000 people who are going to get fired if you don't pick their system. Nothing's like a little pressure, change out New Orleans and do 1,500 people in Denver, 1,200 people in Columbus, Ohio, et cetera, et cetera. I needed to have something defensible when I was going to make my particular solution on this. Now, it turned out that one of the requirements for this is highlighted by a business rule that I've tossed up on the screen here for you. As an architectural component, a person in the Defense Department could be zero employees, could be one employee, or could be multiple employees. Now, that last thing is not a typical requirement for most organizations. Some organizations have that, but the vast majority of them say a person is an employee, one person is an employee, and that's the way we're going to do it. In the Defense Department, we had about 30% of the Defense Department that worked second jobs. We don't pay our service members and women much at all, and many of them took extra jobs. So you might work part-time for the Army for this particular task, and then have another job with the Army or maybe the Navy to do something else to put money for your kids' college funds in there. We call this process moonlighting, although it would necessarily be moonlighting. It would actually consider it to be a standard practice Now, here's the key. In order to be a moonlighting individual, if Peter took the first job with the Army and then took a second job with the Navy, then the system, if it only allows a person to be one employee, would then implement this with a bit of giving me two separate IDs. So I might be Peter I for the Army and Peter II for the Navy. The challenge comes, of course, from a record-keeping perspective. First of all, how much am I making in totality and how do I do my reporting into places like the IRS? If the system doesn't support the rule that a person can be multiple employees, the alternative is to implement Peter I, Peter II, and then do 30% extra work to cover the rest of the people that were involved in that process. I hope everybody follows that because it's actually kind of an interesting bit. Now, when we understood this rule and we looked at the various packages that we had to choose from, we were able to easily discard any system whose architecture required a person to be one and only one person. If we had multiple persons, right, if we had other systems in there, it was simply not going to be workable. The Department of Defense said that we don't want to process by hand 30% of our tasks that we have to do on that. There's another rule on this as well, which we added here. I've got that up as business rule number three, and it shows the relationship between employee and position. Now, that is something we call job sharing. The rule here was that one employee, excuse me, one position can be occupied by zero employees, but one position can also be occupied by one employee or one can be occupied by multiple employees. Somebody could work up to lunch. Somebody else could work lunch till the closing type of shift. If we had multiple shift work and things like that, then it became even more important to make sure that rule was supported. Now, both of these rules show that there is an architecture that better supported the Department of Defense's needs than other systems that required manual workarounds or artificially constructed keys in order to do this. So we always tell everybody we speak with on this to make sure that when somebody is buying a piece of software to go, and it's considered a best practice today, go to the vendor and say, look, vendor, we need to see what this software looks like. What is the data architecture of the software that you're putting in place? Because if it doesn't support our business practices, we're going to either customize the software or we're going to have to change our business practices and how do we even make that decision if we don't have any information on either of those deciding which one to do? So that's a very strong, important reason for understanding your architecture. Your organization will be evolving over time, and as you evolve over time, you will very definitely need to understand how this architecture can better or worse support your existing practices. We'll give you another quick example on this. Here's a query that we pulled off of one of our organizations we were working with and it's a fairly dense query, and the organization didn't understand its BI architecture. But by coming up with an optimized query, we could actually simplify that particular architecture. And in this organization, that query might have run millions of times during the day. And when you do that, of course, what you're discovering is that that really ends up with deaths by a thousand cuts where things are happening over and over in an organization. But at a million times, it can end up costing lots of money. So the lack of a coherent data architecture is a absolutely crazy hidden expense. And the real question is to come back and say, were your systems explicitly designed to be integrated or otherwise worked together? If they're not, the chances that they'll just happen to are very, very slim. They can't be useful as long as that structure is unknown. And I've got another book on that called Monetizing that Shannon mentioned at the top of the hour, but we already said that organizations spend between 20% and 40% of their IT budget doing data migration, data conversion, and moving data and improving it all the way around. So to get business value from an architecture, the goal must be to achieve that shared understanding. If there aren't any disagreements at all, you probably have not agreement, but insufficient communication is there. Data sharing and exchange is largely an automated process. It's dependent on successful engineering. We've got to have a sound understanding of the foundations that we're going to put in place. And we'll do some more webinars on these data modeling techniques a little bit later on this year. But the characteristics for doing architecture development are going to change depending on what analytical problem you're trying to solve. That the purpose for incorporating... excuse me, let me change that. But the motivation for this should be included as well. And this is another piece of architecture that Claude Finkelstein taught me many, many years ago. Most architecture things are concerned with defining things. And when you put a definition in there, somebody says, okay, so I'm going to define bed. Well, bed's the place you sleep, right? Okay, you know, that's nice. But if we put a purpose statement in instead of a definition, you get a much better set of diagnostics when you're looking at your architecture. For example, a bed in a hospital might be a place for putting a patient on and transporting them down to operations or into the intensive care unit or hopefully out of the intensive care unit all the way around. It focuses on the problem-solving activities. So again, from an architecture perspective, if you can populate that architecture with purpose statements, you'll actually have a much better, more robust understanding of what's actually going on. We will argue a lot about different modeling types and things like that. One of our colleagues here studied under Peter Chen, and Peter Chen was famous for introducing some of these concepts in the academic world early on. But we've come to realize now that the use of modeling is much more important than the specific modeling method. What really has to happen is that everybody has to agree. The models from the architectural perspective are living documents. And that's what's happening as the organization goes forward. Now I'm going to talk for a minute about an enterprise model here because many organizations are trying to come up with enterprise models. And unfortunately, the shorthand approach to this is that if you spend three years modeling your enterprise, you'll have at the end of three years the way your enterprise looked at three years ago. And that can be helpful. Don't get me wrong, but it may not be the best business value. We advocated instead a more just-in-time focused piece, which is just simply to say, let's focus on the scope of the problem. And we use this as a double check, too, because if you find you're going beyond the scope of your problem, you probably don't have a good understanding of the problem in the first place. And that's a good place for everybody to come together and re-look at the assumptions that we've done in all of these. The models need to be accessible, not in somebody's drawer or on a hard disk somewhere, but in some sort of library function where everybody can get to them. And finally, let's go ahead and admit that even though we don't necessarily like color and clip art or our models, enterprise architectures that are illustrated are much more usable than ones that are not. In particular, let me tell you a story again from the Defense Department here. I had a boss at one point that would ask the question, you know, where are my boats? Where are my battleships? I think it was the question. Yes, that's right. Where are my battleships? And the answer would be, yes, man, the battleships are resource entities and we have resources that float and we have resources that go under the water. Battleships are the kind that float and some of the ones that float have guns on them. So that's what a battleship is. You point to a box on a chart. And the executive just went furious and said, no, no, no, you need to put clip art on there so that when I show this to a general officer or an AV captain, they understand where their boats are because if they don't understand them, they won't see any value in what we're doing here collectively. So let's ask you guys a question. We have a good architectural foundation here. We've talked about architecture for half hour. And the answer is, it depends on what you're trying to do. Most people look at this house and go, wow, that's kind of interesting. And if all you're trying to do is add a dish, network dish to the top of the roof, your IT people can look at that and say that's a very suitable architecture for putting a dish network on. On the other hand, I wouldn't recommend any investment in this architecture because this foundation is clearly cracked. And anything that you put into this will eventually be falling into a large hole in the ground filled with rubble. The problem is, again, management doesn't understand this. They think that all houses are the same and that they all look perfect and that everybody has two and a half kids and blah, blah, blah. So let's talk about how all this works. Architecture is about helping us to transcend levels of abstraction. It's about to understand whether something is in fact complete and to get some utility from it so that when I need to go in and change the air conditioning vents, I can actually do it. The models are more downward facing in detail. The architecture is the assembly of models and it's more of an integration type function. In the past, we tried to get this perfect understanding, as I said before on the last slide, but it was not timely and it really wasn't feasible. So we need to change our focus in to look at specific components governed by something like the Zachman framework to give us something of more immediate utility in order to do this. This is a chart you would never show to a manager. It's just way beyond the pale in terms of what you're actually trying to communicate. However, it may be a perfectly reasonable diagram for some documentation on something that you're actually attempting to do. The best resource in most organizations today are your web people. Web people understand the term information architecture. It's the only place, as far as I can tell, in technology that it's being taught. And what a web architecture does from an information architecture perspective is it connects people to content. You've probably all been to websites where it's been hard to find what you're looking for. And the web architecture is the way in which you avoid that particular piece. So find the web people in your organization and get them to help understand this. Here's, again, a different description of an architecture. You can see this goes very deep into some areas and very shallow into other areas. Here's one more representation of the same concept here. Again, not the same architecture, but a different concept. In all of these cases, what we have is data structures that are expressed as details organized into larger components. The larger components are organized into models, and the models are eventually organized into architectures. What this means is that the attributes are organized into specific entities. Sometimes we call them objects. The attributes are characteristics of specific things in your environment. And the things at the entity level are the things whose information is managed in support of the strategy. And there are lots of examples of those. We have them taught in all kinds of classes that they do. The entities and objects are then organized into models where these combinations of attributes and entities are structured to represent specific information requirements, poorly structured data that constrains organizational delivery capabilities. And we've already given you an example here of the one where we showed if we didn't have the right data structure supporting it, the organization would have trouble managing its pay information. The problem is, look at the last one, models organized into architectures. There are virtually no examples of this that are ever taught. And if you've been working on a project, you've seen it, perhaps in fact, it's a lot of work to put this together. So the architectures are used to plan new development. But more importantly, remember we only spent 20% of our IT dollars on new development and 80% of the dollars are spent on existing development. So this is why there are very few examples that are there and most people don't actually see the things that are happening. Let's take a different approach on architecture and let's just define a couple of terms fairly straightforward. If I ask you guys collectively what the word 40 or what the number 42 means, you may not understand that as a reasonable question. On the other hand, if I tell you that it's a part of the Douglas Adams trilogy, the Hitchhiker's Guide to the Galaxy, and that 42 is the answer that the supercomputer created when they wanted to find out what the meaning of life was. They created a gigantic supercomputer. It ran for 300 centuries and said at the end of it all, the answer to life, the universe, and everything is 42, you're still probably thinking what the hell you're talking about. I've associated fact 42 with the meaning. Okay. So now I know that 42 is the meaning of life. I could just as easily associate that fact with my age, which 42 years ago was 17. Is that helpful? Probably not. But again, this is how we structure things. We then take that and add a request to it. So we move the information layer up above the data layer by saying that we're just collecting facts and meaning, but now that somebody has requested that information, we now have a request that differentiates it from data. And finally, we get to enlightenment, if you will. Intelligence, knowledge, and wisdom. If we understand how that data and information is transformed into strategic use for the organization. Now, I do that to show also the structure here. Many organizations will say, well, we want to manage our data separately from our information. My answer to that is if you look at this diagram, you can see that the consequences of trying to manage them separately are going to be much more difficult than the consequences of trying to manage them together in an integrated fashion. I also get occasionally flown out to different places where people say I tried to build some data stuff a while ago, but we didn't do anything with it. It didn't work. So we gave up. And then I tried a couple years after that to build some information. That didn't work either, so we went straight to intelligence. We wanted to skip those other steps and just go straight to the answer. And the problem is, of course, you cannot do that. It doesn't work. So let's go a little further on this. One more slide on this will tell us how do data structures represent organizational strategy. And there's two answers. First one is providing effectiveness and efficiency. And I like to use a restaurant example here. If I'm going to create a restaurant and I'm going to have a different dish for every single dish that I have, like a physical dish for every single type of thing you can order off the menu, it means if I break the dish when I'm bringing somebody a piece of apple pie, I have to go back into the back room and find a specific apple pie dish. That restaurant is going to have a different goal than a restaurant that uses the same dish for every dish, because I just have to grab the next dish off the clean pile piece and put the apple pie on that. The goal of that organization would clearly be efficiency and effectiveness, opposed to the dining experience of eating apple pie from a specific apple pie dish, corn cob. From a corn cob dish, you get the picture. I don't know what a jello dish looks like, though. I guess we'll have to work on that. This other also gives us the ability to be more dexterous as an organization, because as an organization, we can be more flexible and adaptable if our strategy is supported well by our architecture. So a lot of questions that data architectures answer, I'm not going to read these all too. You get a copy of the slides, remember, but it just talks about arrangements. And the process of coming up with these arrangements is also an important one, because what happens is the organization has some sort of information needs. And those needs become instantiated and integrated into a data architecture, whether you do it consciously or unconsciously. That architecture should then authorize specific information systems requirements. If we don't have a feedback loop on there, we have no idea what's actually going on, but most people think you're done at that point. And in fact, you're only done when your organization ceases to exist or stops changing. I haven't met any of those in my 30 years in this business. John, you ever met one of those? Yeah, I never have. No, exactly. John, be that this, at least as long as I have, so that's probably a century between the two of us that we've got in there. We're going to talk about also your information architecture is what really gives you the leverage that you're trying to achieve in the organization. Remember, it's our only non-depletable, non-degrading, durable strategic asset. And when we change data, whether it's with our data exchange partners or whether we're in the organization, we're really trying to obtain leverage around this. And we have a website out there called TheDataDoctrine.com that explains a little bit more about what data-centric is. But what we're really trying to do is eliminate the amount of redundant, or trivial information that people have to wade through in order to get to the real good piece that's happening there. If you look at the diagram at the top, it's a very simple engineering equation. A fulcrum and a lever of people can move a very large thing, but if I want to reduce the rod associated with it, I need less of the energy on the other side. Doing this helps to simultaneously lower IT costs and increase knowledge worth of productivity. Now, we're heading towards our case study here. I've got a couple more slides to get through as we do this. But I want to show you that this is the world we live in from an architecture perspective. All of our architectures can be classified as as is or to be, whether it currently exists or whether it was what we hoped to build after we finished, and whether our architecture is conceptual in nature, logical in nature, or physical in nature. And whether the architectural components have been validated or unvalidated. What we'd like to try to do is to map every transformation onto some of this and move all of our architectural components into the validated state in order to do this. It's very tough because architecture is clearly a program, and the way most organizations go about doing this is that they start out with some sort of strategy, and then they move to IT projects, which seems a reasonable thing to do, but in fact just the opposite of what they should do. They really want to go to data and information. So we want to switch that around and say let's do strategy first, then your data architecture, and then your IT projects. And that's really the only way you can actually make this work correctly. Unfortunately we've taught everybody completely the opposite for many, many years, so we've got a ways to go to do this. Now I mentioned architecture and engineering. Remember we're talking data architectures here. And the process of doing this requires an interaction between data and engineering. Engineering is a discipline that we need to pay attention to. This is a model of, excuse me, it's not a model, it's an actual mixer on a USS Midway. It's taller than I am. It has a clutch and built in 1942, and it still works. And even if I had added that other piece onto it, which was a little kitchen aid mixer, I could not have made pancakes for 10,000 people, whereas this machine has clearly served much of that in the long run. So architecture, again, I'm not going to read this, it's just trying to figure out what part of the architecture do I actually need to do. If I'm only remodeling three rooms of the house, I only need three rooms of the apartment. I don't need the entire house in order to do this. You'd be amazed, though, again, that the number of systems we've come to that don't even have this amount of documentation or this amount of documentation, or this amount of documentation. By the way, this is from the veteran system, some healthcare system that we worked on many, many moons ago. I'm actually going to skip this, that's an example in there. So I'm going to jump ahead. There's one more example in here that you guys could look at, but I'm going to jump ahead because I want to make sure Brian has time to present his case study in here as well. So Brian, first of all, an NGO is a non-government organization. Right, so really all that means is it's a nonprofit in its independent of states. Kind of going back around, we're talking about the industry that these people work in are healthcare. So you're looking at HIV and AIDS, malaria, so anything of concerns for developing countries. They also provide leadership training and really they focus on health information system management. The main function of the company is project management and design for healthcare implementations and they operate in, I think, 30 countries globally. Oops, that was fast. Sorry, I'm nice to Peter's computer. So the problem where we looked at or we came into, because we came in to solve was that data needed to make key business decisions was not accessible across enterprise and really we came down to three things. Timeliness, so reports are coming in weeks late, months late, sometimes year late. Accuracy, when they did get reporting it was all over the place. And then lastly, it was isolated into certain segments of the business. So we really stayed in HR, stayed in finance and so on. So really we took the first step at what was the root cause. Well we found out there was no enterprise what understanding of its data assets. They lacked a conceptual data model. They didn't have a common vocabulary. So if I said the word project to Peter, he would tell me one example. And if I went over and said it to Mike, he would tell me a completely different meeting. And that could be a problem if you need to report on projects. And then really the last thing is they lacked existing system and data architecture and really they lacked an overall vision. And the vision they had was not aligned with their business model. And of course SLS, right? Yeah. And then always the shiny object syndrome. So pretty much if they saw a tool and it looked like it might work they would buy it instead of actually looking at the fact the data did it actually fit within the organization. And that led to minimal integration across enterprise. So next what was the solution, right? So first thing we started, we worked on was the vision and purpose for their data architecture. And what that means is we really wanted to, you know, date architecture as a journey, not a destination. So really leaving document. Let's start with that first. Out of that we helped them define a business glossary and then also enterprise conceptual data model. What is the vision and purpose? So really it's a 100,000-foot view that represents the processes, procedures, and technologies that make up the components of the data architecture. Kind of had to align it with their business model, which is a federated data architecture. And that supports the business strategy. And all that means is that a set of entities or projects that have a level of autonomy to support its goal while unifying entities. So that would be the shared services, provides a framework and definition on how data is to be managed and captured. And really if we look at this picture, the gray boxes are the investment boxes that you have to use to actually create business value out of the purple boxes or the reporting in BI. So it's color-coded is what you're saying, right? And then the next thing we built was the business glossary or the start of the enterprise taxonomy. Back to that project example, you know, it's really important to have vocabulary aligned across the business to be able to understand and communicate with the business. This business glossary also helped us define initial entities for a conceptual data model. And last and probably most important, it helps IT engage with the business to validate the entities and provide meaningful business definitions. We expect everybody to read that, right? And so this is the enterprise conceptual data model that we built for them a little quicker. And really what this shows is how data would flow throughout the enterprise, where it links across different business functions and also using the business glossary having the common vocabulary across. And really it's important that we build this for them because in the future, if they decide to make a change, they can start looking at this kind of model we built and determine if we'll have an impact on it. Brian, that's actually a data blueprint, isn't it? Yes, quite literally. So on here, though, this is where you came up with things like what the actual definition of project was so that everybody now had a standard term for all of that. What business value did this kind of provide to the organization first by making this data architecture kind of aligned with the business strategy? It supports the organizational strategy. It helps reduce IT costs because there's a data asset, knowledge, and reuse. There's help making business decisions, help making software purchases because you can realize what impacts you're making. Like I said, data asset, knowledge, and reuse. And then last but not least, the accurate and timely reporting, which is very important for them. So how does this support the organizational strategy? It defines common vocabulary across enterprise. The cohesion allows IT to effectively support the organizational strategy, and last but not least, helps IT understand the business needs. How to actually reduce IT costs? The data architecture guided IT on software implementations and mitigates poor software purchases and reduces the overall cost of implementations. We also reduce IT costs by focusing on maintaining and managing the data landscape. You will focus on just the critical pieces instead of trying to focus on everything, which could be costly if you're trying to manage 100% of stuff when really 20% is what you're supposed to be managing. The data asset, knowledge, and reuse. So knowledge of how long the data can be leveraged is increased because you now can talk to the business and say, you know, we can reuse extra port for this upcoming, you know, presentation or things of that nature. You identify key integration points. So you, like I said, allow IT to focus on the critical data assets and increase reuse of data assets for future integrations. Last thing does is it allows identified impact of data flows, allow IT to plan for future implementations, and overall reduces the impact of organizational existing data assets. This helped Accurant Time Reporting because it reduces the time needed to build the reports. So instead of taking, you know, months, a couple of weeks, now we're having faster decision-making because it takes a couple of days. Also, there's a single source of truth. So now I don't have to call Peter to get the report. You have to call Mike to get the report. I can now just have the report right in front of me without having to make that chain of phone calls. We really believe that the implementation of good enterprise data architectures is the biggest key to unlocking knowledge, work, or productivity that's out there. And again, as you said on the slide here, the less massaging. I looked up in Wikipedia the other day. There's actually a term called munging. It's a computer science definition for this. And it's actually the right definition because what it says also is something that you captured in the discussion here too, Brian, which is that when somebody does that transformation, again, somebody asks you for a report, you ask somebody else for the information to go into your report. Those steps are not recreatable. Right. They are destructive. So you end up with a one-time data set that is really useful to answer that problem that can't be reused throughout the rest of the organization as they go on that. So you did a great job of presenting a huge piece. Sorry, that was too quick. No, you did fine on it. And really, we've just been looking because there just aren't a lot of these enterprise architecture examples out there. So we hope you guys can take this and use it as an example as you're looking at it because it really does talk about how all of this fits together and what kind of intelligence it is. And the really interesting part about what we do is that for the most part, we get called in for something completely different. I have a business problem. And we look at it and we say, oh, yeah, for example, they didn't in this case. But they might have called us in and said, can you tune our Oracle system? Can you make our Oracle system go faster? And the answer is yes, we can, but it's probably not going to be possible. And so that's really an interesting conversation that you have to have then with them as they're trying to figure out, well, I thought you were going to fix my Oracle system and you're like, I'm sorry. What you really need to do is understand what your data assets are. Right. So let's talk now just about the top of the hour here. If you're going to build a house, would you at all build the house based on a blank piece of paper? And the answer is no. You want to see it. You want to look at it. You want to see what's going on there. You would not build a house without that sketch. If somebody drew the sketch and they showed you that they were breaking it out of Coca-Cola bottles. Okay, one of my favorite things, right? You'd probably say, no, Peter, I don't think we want you to design our particular house. That'll take you a lot of money early on. You need that model. Okay, well, again, we need the same things here. Plus, let's assume that you decided that the Coca-Cola bottle house was a good one, right? Well, all right, if you're going to do that, how much is it going to cost? Well, I'm going to have to buy 8 million bottles of Coke. All right, well, that's at least a million dollars in there. So, you know, how demanding is the work going to be in order to come up with all of that all the way around. If I hired specialized Coke model constructs who come from Pennsylvania, I'll make this up, right? You know, it would be nice if we had a common language. This, again, is the architecture where we look at them and they say all architecture from all over the world know how to read the blueprints correctly. All data architects from all over the world know how to read your data blueprints correctly. That's a good thing, right? You know, we'd like to just double-check to make sure it's going to support. I'm going to put a water bed on the second floor of my Coke bottle house. Oh, water bed, that's a lot more weight than we thought we were going to put in there. In the first place, we'd better recalculate some of these in order to do this. We can review the models. We can test them. We can actually simulate them as we go through this in order to come up with it. And if it was a good house, would you like to build it again? Yeah, the Coke bottle house is really going to catch on. I can see this is the rest of my life. Now I'm going to be building Coke bottle houses all over the world, right? But if I don't have the documentation, of course I can't. I've got to build each one from scratch. And that's an absolute waste of everybody's money. And finally, of course, we probably are going to drill into the house or put something in or do something to it that's not planned in the original. And again, Brian, that's sort of half your life, right? If you come to me and say, hey, I got this car and I want it to float. I'm like, wow, that's probably not going to work, right? So again, it makes it easier to maintain all of these things here. So let's review. We've got three minutes left. An information architecture is a structure of data information assets, okay? Or a structure of information assets if the database part confuses you. That supports, so it's got a purpose, that supports the implementation of organizational strategy. If I'm going to sell things to customers and I don't have a list of customers in my organization, it's going to be a little difficult to make money. I did. I did. Again, you've never seen any examples of that. No. We can't tell you that story. That's Brian at a conference, though, and he'll tell you some things off the slide. Most organizations then have data assets, information assets, that are not supportive of structures, of those strategies. And the reason for that is because they're not known. If they're unknown, they can't be helpful. So we want them to be helpful. So the question is, how can an organization more effectively use their information architecture to support strategic implementation? Second really big takeaway on this as well, what do we mean by using an information architecture? What's the application of these data assets that we've been talking about in support of strategic objectives? We can assess this by understanding the maturity of the practices that are around this. Again, we have another webinar that we talk about, the maturity rating on, but just Google DMM and you'll see it out there. And this results in increased capabilities for the organization, dexterity, and probably most importantly, self-awareness. I have a bit of an idea when I'm doing this in front of real people. I stand up on a desk and say, I'm getting ready to do a backflip. Everybody in the room here is laughing because they know I'm completely incapable of doing a backflip without a lot of practice. So how are we going to do this? This is a self-awareness piece. We know we can't do it just that way and that architecture is going to give you that as well. We accomplish all of this through the use of this data-centric process and as I mentioned before, the Data Doctrine website. I'd love you to go out there and join with us and sign us on it. So then the last question is, how does an organization achieve better use of this? Well, it's through continuous redevelopment. We're not going to start with a blank sheet of paper because your organization already has some form of an architecture in place and these architectural components must be re-engineered using an iterative incremental approach focusing on one component at a time and applying formal transformation processes. So we are right at the top of the hour, Shannon. We did it again. Came in. Perfect. It's time for questions and answers. See what we get. I love it. Thank you so much and just to answer the most popular question that we receive, just to remind everyone, I will be sending a follow-up email by end of day Thursday with links to the slides, links to the recording and anything else requested throughout the webinar. So just to dive into questions here, we've got a lot of great questions already coming in. So, Peter, how is data architect role different from a data model role? If the answer for the DA role is more of an enterprise function, then is it really part of an enterprise architect's job function? So it's a great question and truthfully, we don't have a lot of formal guidance around this, but let me go to one slide that I think does show some aspects of this. The key is that a modeler is usually focused on down from the model. So it's more of an implementation type of a process as opposed to architecture, which is focused on more of an integration type function to that. That said, however, modelers tend to make good architects and architects tend to make good modelers because they both value what they're doing. What we're moving from is something that is more abstract. I showed it at the bottom of this chart. Even though it's more abstract, it should probably be at the top. It's just something that's more granular. So the details at the modeling level are typically, I'm going to build something or I'm reverse engineering something to know how it was built. I'll give you a very quick example on that that I like to use a lot. We reverse engineered a number of data structures and one of them we reverse engineered. We found that this hard drive had A through D on it and the next hard drive had E through H and the next one after that had I through K and all the rest of them. And we said, well, why on earth would you arrange your data in such a funny fashion? And the answer was when they built it, the PCATs that they had had 10 megabyte hard drives and all the data you could fit on there. Is that a good reason for bringing those data structures forward into the new world? Absolutely not. And again, that's where somebody like Brian can come in and help you understand it a better way of doing that. Hopefully that answered that question. Great question. Now, talking about the case study specifically, did the business understand the difference between an entity and an attribute? No. I quickly answered that question. There's always a education that has to go on when you're first interacting with the business and really the way I've learned and Peter can maybe help support this, to help communicate that is how can you shine a light on that term through a business lens? So instead of entity, we might talk about it as more real thing like a project. So the project, we may call entity, they're going to call a project and kind of having those conversations with them to determine, to help them see that an entity is more of a thing instead of a conceptual idea to us. That is a great question. It really does point out some of the value that you're able to bring when you come into an organization. We talked about one aspect of the business problem that Brian was dealing with. He had that multifaceted business problem. One aspect was what is a project? You might say, well, how complex could that be? Well, it was so complex that two managers could stand up in a meeting and say, you're under budget and they'd both be telling the truth. Yep. Because they both were using different definitions of projects, which meant it was really hard to manage the budgets for the project. And if you're in a caregiving organization and you want to do good things for the rest of the world, you need to have enough money to be able to do it. And being able to say, can you pay people or not, that's going to be an issue. So what is a project? Whether a project is entity or an attribute, it didn't matter so much to them, but you were able to show how designing that in a structure meant that they could then do other things with it because if they couldn't get past what's a project, they were never going to get to what's a program, how much budget. You've actually worked for organizations that didn't know how many people they had working for them, didn't you? Correct. So reducing IT costs, how does a data architecture will first uncover the current cost? Is data portfolio effort function mandatory for realization of data asset value? I read that one slower to me, Shannon. The second part of that was very interesting. On, quote unquote, reducing IT costs. How does a data architect roll first uncover the current cost? And is a data portfolio effort function mandatory for realization of a data asset value? Okay, so let's split that into two parts. The second part of the question was a portfolio or an inventory of what your portfolio is. Your data architecture, of course, should show the major component of your enterprise architecture in there, but I've never found a single organization in 30 years of doing this that has a complete inventory of all their data assets. So when we talk about portfolio, let's talk about portfolio as the same way we talk about essential modeling. When Brian asks a group to pull together a model, they're making judgments about whether something is essential to the model or not. If I look at Brian and say, what are some essential elements of Brianness? Brian has glasses. Okay, and he's got shoes on. Now, those got other things on as well. We're just going to make those essential pieces of Brian. All right, so we can do a caricature. Yeah, right. I think I'll stop the shoes here. Those essential characteristics are what you're trying to do at the portfolio level as well by saying what are the essential piles of data that you have that are necessary in order to run your organization. That's the answer to the second half of the question. The first half of the question was interesting also because they're asking about valuing and how do we save IT costs by doing architecture work? I wish I could show you a picture of another slide that I have. I don't, but I'm going to ask you to imagine here for just a quick second that we have a fairly complex set of things that are happening on the screen here. It's an enterprise architecture. In this case, showing it from a process flow perspective, we start with process one and process two, and it goes through all of these various processes. I've been at organizations where you look at the inputs and find that the only difference between the inputs and the outputs of those systems are that you've inverted the date. So in other words, we're doing it the way of Europe, which is day-day MM, excuse me, YYMMDD at the input, and by the time it gets to the output, we've actually converted it to something else, which means we can eliminate the entire set of systems that are there and instead put it at conversion routine that will handle it much better than application code much easier to maintain or an XML transformation function or lots of other things. So there's many, many different ways of seeing how architecture can reduce your cost, but the most important thing is by highlighting what your current procedures are. As soon as somebody looks at this and says it takes you seven steps to get a check issued, we do it over here in two. That's a good practice that you can learn internally, and you can say, hey, how do we go about learning from each other on the inside, in this case by comparing notes that are there. Love it. So does data architecture also include relationships between models in addition to just models? The architecture is composed of models, and the models are typically broken up into views in there. But yes, if the models are not associated, at least if you know the models are included, I guess that'd be a piece, but that would show you a gap in your knowledge about the information architecture. You probably want to address that before you've made any attempts to correct things. It's really bad to try and attempt to correct things when you don't know what's going to happen when I stick my knife in the wall, right? Or whatever. Interesting question, Jenna. Yeah, you know, there seems to be a lot of questions about the difference between modeling and architecture, and so the next question is if you can kind of go back and show an example of a data architecture, not a data model. Correct. So let's talk very bright for just a minute here about the difference between the two. So here's a data model. I didn't show this one during the presentation, but it's a part of, in this case, the delivery view of a local welfare agency that's doing this. And you can see the model here shows social service programs, clients, service delivery partners, and welfare agencies. At high level, it's conceptual in nature. It doesn't have any attribution or even any keys in order to show all this. But this model clearly allows us to see what's happening within that particular function. Now, if we show the rest of the architecture for this particular piece, you'll see that the model is still part of that architecture, but that the architecture is more complete, showing in this case all of the major essential aspects that are happening in this particular model here. So hopefully that helps, but really your architecture is made up of models, and the models are made up of entities and attributes, and we know what all that stuff is, so it's just a matter of getting it to a complexity piece. I think the thing that we're adding here that may be helpful to some people is that we're talking about model components, and just simply saying that we don't have to have the entire... Has any of you guys in here done a whole enterprise model for an organization? I'm looking around the room here. Yes. Okay. Once mic or a couple times? I'm trying to think back. Okay. Depends on what you mean by these dire organizations. There you go. That does come back to it, right? So this was, on this one, our Virginia State Department of Social Services, and it was their strategic high-level data model, and it accomplished everything that was essential. However, you can see it is not at a level of detail. It's very useful for people. So it was really helpful to explain to managers what was going on, but we were not going to re-engineer IT or drive costs out with this model. We had to go further down. Great. I see maybe a simple definition would be modeling is a piece of data architecture, but data architecture is not strictly modeling. Okay. I think we can go with that. I think about it as level of attraction. The more of an abstraction you have, the more it's more just a model and an architecture. Yes. And really the key is not to argue about the definition of are you architecting or modeling, but to instead say, what are we trying to do with that? If we're trying to build from here down or understand the behavior of something that is, that's from a model from the as is to the model. If we're going the other direction up, how do we fit? That's really more of an integration function that we'll pull in there. Sorry. I'll let my slide get away from me. Next question, Shannon. Good questions. They are great questions. How long does a data architecture strategy project typically last? Typical is going to depend on, of course, the size of it. Complexity and everything else. What I would say, first of all, is don't think of it as a project, but think of it more as a program, because it is, if your architecture is never going to change, so for example, we have been asked to document the data architecture of a specific piece of software. We actually wrote that one up and it took six weeks to do. There's an article out there, if you want to read the details about it, be happy to point that to people. But that's more the exception, I think, than the rule in terms of knowing it, because when you put your architecture out there, the only time it's not going to change is if your organization doesn't change at all and most of our organizations evolve on a regular basis. So periodically, you need to come back and visit it. Let me talk about the U.S. Marine Corps for just a second on this. That's the group we've worked with extensively over the years. And their enterprise architecture for some of their systems is so well documented that they could actually take us to a room in Kansas City that we go to occasionally to visit with them and say, these are the only changes that haven't been made to the enterprise architecture model and we're simply waiting for some more year-end money to come through so that we will be able to bring the architecture model up to full compliance with our own internal standards. Now, just to understand the importance of this, the Marine Corps, when they feel the change to their pay system, they feel that in 18 hours to the entire world, because paymasters follow the troops then so if our Marines are fighting in a far-off part of the world, the guy who pays them, those in with them to make sure that we keep morale very, very high. So there's an instance of strategy implementing the data architecture in a very, very constrained fashion and also a very, very, very well-implemented group of individuals. Again, it's been our pleasure to work with them over the years. Getting you into more in the specifics, do you show all data entities in your diagram or only master data? Do you show duplicates as well? So let's go back to my taxonomy that we have. This is the general environment that we are working in. And when you ask the question, what do you show, it depends on what you're trying to do from a modeling perspective. If you're working on an as-is conceptual model, there's probably not going to be a lot of detail in it that we showed like with the State Department or the Social Services one. On the other hand, if you need a physical as-is model so that you can diagnose a specific problem that a software vendor may have introduced into their system without knowledge of it, you are probably going to need absolute detail of everything in there because if you have incomplete information, you can't actually make any good decisions on it. So again, good question. Hopefully that's clear. So the next question is, for global enterprises that have same business division with similar business processes, does it make sense to spend effort on a global data model that can be used by all countries with slight customization of the common data model? So what would be more useful would be to understand what is the same and what is different? Yep. Because if you understand those deltas, then we can say, okay, this is a common set of threads and you've seen this actually in a couple of your projects. That is correct. Peter's very correct. Sorry, I've got to give a little more example there and he's going to punch me if I say anything else. Anyway, yes. It very much makes sense to understand the differences because if everything is the same, you only need one copy of it. I don't know that you would even need to do global modeling if it was a software package that everybody used and you were having trouble with it. I would certainly investigate reverse engineering portions of it if it's a package that the vendor very likely has that information and they're actually usually pretty happy to give it to you if you buy the software from them. So you can dive into that. So where do you draw the line in responsibility between a data architect and an enterprise architect? Kind of scratching our heads on that one here. Clearly an enterprise architect, well, do you ask the question specifically, what's the difference between an enterprise architect and a data architect? Let's cheat on that one here. All right. So I showed you a bunch of architectures and an enterprise architect would be responsible for multiple architectures. So an enterprise architect might be responsible for one or more of all of these types of architectures in here. That may not be the question that you were going to ask and I'll go ahead and answer the one I think you're probably going to ask anyway, which is that an enterprise architect for a large organization, again, let's just say the Marine Corps because they're clearly a big, large organization, might have overall responsibility for this and then data architects would have specific responsibility for specific portions of the architecture in there in a nice hierarchical relationship. As far as drawing the line, if you've got a fight going on between those two people, that's not a good thing at all. Hopefully they're going to have more in agreement than a disagreement on that. Ask a clarifying question if that's needed. Absolutely. I'd be surprised if we didn't get this question and what is the relationship between data architecture and data governance? I'm going to put up a different picture. I'll have to remember to include this one in there for everybody. Governance is about making sure that what you're doing is the right thing. This is actually a slide from the last webinar that we did last month on here, but I think it illustrates the question very, very well. The first thing we'd like everybody to understand is that governance has to have a purpose, and that purpose is usually driven by a data strategy which talks about specific business goals that it should have. The governance feedback is then metadata that says how well is that strategy working. Of course, these are just parts of an organizational strategy. Some organizations have 100% of the strategy and data. Others have a portion of it in their strategy. Out of that, then data governance should really be helping control and implement how IT does things. Again, simple things like deciding whether a package should be, you know, if this package should be purchased versus that package or whether we should build our own or buy another one are all very important and all of that. And finally, we get down to the organizational operations which says how well is the thing actually working. So now you look at this picture here, and this actually is an architectural picture of how these functions work. Even though I've drawn an architectural picture here, the architects are going to do the same thing. They may, the data governance people are very likely, most specifically. It's unlikely that data governance can function effectively without understanding the architecture of the organization. So the data governance should be helpful in determining which pieces of the architecture needed to be done first, need to be uncovered and surfaced, and which pieces might be better done in phase two or phase three further down the road. The architecture also is going to be important in data strategy because if somebody says, hey, we're going to become a data-centric organization, somebody might want to say how long is it going to take and how much is it going to cost. Again, Brian's been in those discussions those while he's chuckling a little bit there. But the architecture is also going to be important from that perspective as well just to say, hey, can we in fact identify all the people in our organization that have multiple jobs? We might not be able to do that because we did a very poor job of managing the data in the first place. I'm sure we can come up with lots of details but then we'd have to shoot everybody on the first call. Yeah, we can do that. Shannon, I'll drop the slide in the other deck there to make sure everybody gets a copy of that as well. Perfect. Thank you. And, you know, we've got a lot of great questions. We still have 10 minutes left so we can still get to a lot. But if we don't have time today to answer all the questions, just keep them coming in and we'll get you written answers to be included in the follow-up email going out by end of day Thursday. So just continuing down the line here, Peter, I have done ELDM for a large enterprise. So are you cherry picking the essential concepts into a data architecture and showing significant relationships? Is that correct? That would be good. But let's put that in context as well. So Enterprise logical data model in there and it says cherry picking. I'm assuming that the questioner is saying I'm putting the essential elements into it. So again, one of the things that Clive taught me was not just that definitions for the entities and the attributes should be actually labeled purpose statements, but the purpose of the modeling exercise should also be clearly defined. We're going to go to the trouble of coming up with good information about Enterprise X or whatever it is we're doing, and I'll go back to my DSS example here. The purpose of this model was to show how complex, in this case, Virginia makes its Social Security delivery programs. Now when I say complex, what we do in Virginia, we do this by telling all the localities they can do their own thing and we'll tell them which things they can do. You go to a simpler state, just take Wyoming, for example, where they have one program and it does the entire state for 300,000 residents. It's a very different, very not complicated model like this at all in terms of what they have to do because many of the pieces here do not exist because they have a very different business model. So the question was, what are we talking about in terms of Enterprise modeling? You've got to be driven by a purpose. We are making this model to answer this question and what question this is will determine what things, what elements, what aspects of models are going to be important, whether certain subject areas are included or excluded, whether you keep detail as well as master data showing up, whether you show level of detail beyond simply the entity names that we have at this level or whether we go in and identify primary keys and important keys and all the rest of that stuff that's in there. So I think the question was right and I think we answered it right. Well, certainly I will ask the questioner to post some additional questions if that's not correct. But moving on to the next question, could you discuss how data policies and standards are an integral part of an organization's data architecture? Great question and we didn't address that at all so thank you for pointing that out. Yes, while it's important to focus on this aspect, which is what we're showing you here and the cube that I showed you a couple of times already as well, this is where the role of governance and strategy starts to play as well. We're doing this for a reason and the policies should be enabled in order to do this. Again, my easy example on this is the Consumer Product, Consumer Protection Financial Protection Bureau, which is one of the groups that we work with and Linda Powell and I will be doing a talk on this at EDW next month. Not next month, April, but anyway, we'll be there. And so her mission is to help consumers better deal with consumer financial products. So when she's looking at what's going on in the enterprise, she's looking at it from that perspective. It's mission driven and the policies that are driven out of that mission are designed to help American consumers better deal with predatory lenders, bad automobile things, you know, whatever we're talking about in terms of consumer mortgages was a big hot spot for them too. I don't want to talk too much about them. Linda's going to give some examples at EDW. But in fact, our talk is called Making Data Do Good Things for People or something like that. But anyway, so that's really what we're talking about. Now, yes, thank you for doing that. We should definitely revise these slides and get some more pieces in there. Anything else we left out besides policies? That's a really good observation. I do. I love all these great questions coming in. We get the idea it's a program, not a project. I'm just curious for the good sides of the first incremental delivery of the architecture. So, when somebody comes to you, what are you going to do first? Well, yep, that's a good question. Well, it really depends on what's already there. Typically, I know that we start with, and I've got to work it up, Peter. Hold on one second. Which slide you want? Hold on. The first thing we start with is the vision and purpose of the data architecture. That 100,000 foot view of what it is, the components. As you see on the diagram on the left, it's not very detailed, but it really tells the picture. We're getting all the data generated in the green and it's going through the capture and the integrating and the gray and really the purples, the delivery or what the business value out of it is, which is managing content and creating reports. And so really, this is kind of where we start, is to get everyone on the same page of what we want our data architecture to look like. And then, if we want to do something more tactical, it really starts with a business glossary or a conceptual data model. You also get another value from this, too, Brian. I'm going to explain it to you to me. When you hit this level of detail, if something's obviously missing, like we didn't have policy in our discussion, something to look at this and go, where's policy? Yeah. Right? And you say, oh, great. By the way, when you show a model, the worst thing anybody can say is it looks fine. Exactly. But one of the best things somebody can say is, hey, you forgot this, which is why you do this, to show them these are the major things and somebody's going, no, you don't have it all in there. That's good. I'll essentially dig over it. I think I did that accidentally one night. Did I answer your question hopefully? We shall certainly see if there's an additional clarifying question here. So how does big data fit into all this? Well, those of you that have heard me rant on big data before know what my answer is, the problem with big data is that it's an ill-defined concept. Now, if you want to ask the question, how do big data technologies, which is something that we can actually identify objectively fit into this, what you're talking about there is I need to do something here that my current capabilities don't allow me to do. And if big data techniques will let me get to that, then they become a part of your data architecture. It is also a good idea, as many organizations have done, to start experimenting with this in a sandbox area to learn what these capabilities do, because the next time they're sitting around at a business meeting, somebody looks over at Brian and says, hey, Brian, I've always wanted to be able to see both of my eyes like a snake and also infrared. They've got these things on the sides of their pockets. You ever seen any technologies that do that? And Brian goes, yeah, big data technologies actually do really well in that kind of an environment. The infrared's going to tell you there's something next to you. It's big and it's edible, but maybe too big for me as a snake, and so I probably don't want to eat it. By the way, military context coming out there, but again, we won't tell you too much on that one. Hopefully that helps. Certainly. Now, a little bit back to data governance. Outside of stewardship and data asset value, what are the touch points between data architecture and governance as data architecture as IT and data governance as a business shared services? DGL says taxonomy functions in it. I'm seeing duplicate activities if you could help clarify. So, yeah, clearly it's hard enough to keep any of this work going in an organization, LSAC, some tangible business value coming out of it. So if you've got two groups working on the same thing, that's almost the opposite. And so somebody mentioned earlier the difference between the enterprise and the data architect in there. We would not want all of our data architects, reverse engineering, and understanding the architecture of the same system. That would make no sense whatsoever. And similarly, you need to coordinate this. Now, my standard answer on this is we've been selling beer to each other for more than 8,000 years. So we know how to do that part pretty well. But this architecture stuff is relatively new on particularly in the data space. It really goes back 100 years. So while we don't have a hard and fast rule, clearly we want to minimize the duplication and maximize the value that goes on there. And beyond that, we'd rather have it done than not done. So, you know, aside from that, I don't know that we can say there's an absolute guarantee. There is a slide in one of these decks that shows Peter's vision of the world of most everybody reporting back into the business instead of IT. But that's a different topic that we go into. Just looking at the time here we've got, I think we can squeeze in one more question. Again, if you've got more questions, feel free to keep typing them in. I will get the questions to Peter to write up the answers before the... to go out in the follow-up email by end of day Thursday. So how do we establish data governance in an agile project management environment where things can very quickly by develop... can change very quickly by developers without wanting to go back to a model? That is a fantastic question. So I mentioned the data doctrine a couple of times. We introduced it on this webinar in December. Take a look there. The difference is that agile projects, the minute they run into data requirements that are incorrect, if you want to keep to your agile sprint method, the only possible outcome is more small piles of data. On the other hand, as soon as you hit an incorrect data requirement, you should stop investing in software and go back and invest more in architecture in order to do this. So again, it's thedatadactrin.com. Take a look at it. It's actually based on a chapter from the data strategy book that we'll be talking about at Enterprise Data World coming up. And there's someone with to have an offline with me on that one. I'm happy to take that one on. You can see we've got a couple of events coming up. March, we're going to do MDM. April, we're going to do modeling strategies in this. And then we've got two specific pieces at Enterprise Data World. Actually, we shipped three that are going to be there. But we're so looking forward to seeing everybody in Atlanta coming up next month or two. And Shannon will also have the band there on Monday nights as well. I love it. That is fantastic. And Peter, thank you so much for another great presentation. Thanks, Brian, for jumping in and sharing the case study as well. That's fantastic. We do love case studies. Absolutely. So just a reminder, again, one more time, I will be sending a follow-up email by end of day Thursday with links to the slides, the recording, and I'll get these additional questions out to Peter that were you didn't have time to answer today. And thanks to our attendees for being so engaged in everything we do. We just love all the questions that come in in the engagement in these webinars and participation. And I look forward to hopefully we'll see everybody in March for the next webinar. And I hope everyone has a great day. Thank you. Thank you. Thank you.