 You're going to hear a lot of things this week about how to go from the top down to do data modeling, you know, process modeling, maybe, definitely metadata, but let me tell you about my background a little bit because it is unique. I have over 25 years in IT data management, including consulting, which is like 50 years, right? Over 20 years of metadata experience, I work for New York Stock Exchange, Citibank, so pretty big companies. I've implemented Roshade and Platinum at various sites, as well as homegrown metadata repositories. I'm a metamodeler. Currently the president of the MPO, which is meeting tomorrow morning at 7.30 for those of you that don't like sleep. I'm a former member of the IBM Data Governance Council and Meet the Boss, but the one in highlight here I really want to harp on because I'm a former developer, BA, DBA, data modeler, DA, and enterprise data architect. Now all these skills come into play because you have a better overall view of what can be accomplished and more important what cannot be accomplished, and we'll see about that. I've implemented several enterprise-wide data and metadata management, data governance, data modeling strategies, so there's not a whole lot that I don't know, however I am not an expert, anybody that claims they're an expert is sort of stretching the truth. I currently function as the enterprise data architect at Defense Medical Logistics, like Lisa mentioned, and it's part of the Defense Department of Defense. We're responsible for moving all the medicine from Walter Reed right down to the battlefield and replenishing all those medical supplies. I love golf, but hate long walks on the beach. That's a joke, folks. I love the Oakland Raiders. Anybody know who that is next to the fat guy in here? Nope. Cliff Branch. Very good. Who said that? Very good. Cliff Branch is a Hall of Fame wide receiver for the Raiders. I had the honor of meeting him, and what he's doing right there is he's putting his Super Bowl ring on my finger. It was a magical moment. Did he go to Heath? No, he made sure, if you notice, he makes sure that he has his hand on his ring. He wasn't going to let it go. Well, you notice it's on my pinky. No, but he's a super nice guy. I just had to put that in. But you didn't come here for that, but let me give you some background. We're going to cover the background, the granularity of your high-level business processes and how that drills down. We'll talk about the business term on three different levels, and I'll explain that in a minute of the handout there. Creating a conceptual data model, which is called the DIV-1 and the DOE-DEF 2.0 that we use as a framework. We're going to use that DIV-1 to create an accurate logical data model. We're going to use the metadata repository assisting in the integration effort, and how do we support the developers? That's what it's really there for. Now I'm going to tell you the tools we used. You could use other tools if you want. This is a generic approach. I'll just tell you how we did it with certain tools. You can use whatever you want, though. What is the problem? We had different granularity levels at the process model level. You could imagine if you have, we had like 10 different process modelers supporting 20 different groups for 40 applications. We had an overall framework that we put everything in. This request comes in. We do this. We create this process model for this particular operational view, a business operational view, which is very high level. We found out that what they were calling an operational view was actually at too low a level to be useful at that level, and we'll explain that a little bit later. There was no implemented data strategy architecture that can be distributed and governed throughout DML for this particular process. There was some on the overall process of how we actually get everything started, but there was nothing that dealt specifically with this area. There was no true enterprise data assets or business terms that can be drilled down into implementable BIOs, which is business information objects, into the conceptual, logical and physical levels of data models. Some approach was considered by the enterprise architects, and I'll get to that later. Development shops needed assistance for their information gathering and disseminating of data at the DML application level. That's where they dealt with. This includes a lack of definable stewardship and authoritative data sources. They did not have any of this at the time. They knew it was a problem, so I figured this would be a good time to bring all that together. And the number one problem that I faced is politics. None of you have ever dealt with politics, right? Well, DML has two different masters in two different areas, run by two different generals, and there's a colonel that reports, that leads DML, and last time I looked, generals told colonels what to do. Did you ever try to tell a colonel what to do? Hardest thing in the world. Yeah, only if you're a general, it's easy, but you understand that. Anybody that's worked in the military understands that. Well, we have these two conflicting masters, so to speak. How do you please them? To make matters worse, the project that I was hired under, even though I function as an enterprise data modeler, was Agile-based. Now, I don't hate Agile. I just think they miss the boat when it comes to data management because it's always get it out. And what suffers? The definition suffer, data management suffers, silos, silos everywhere, right? And of course, we have this little cartoon there. I'll go find out what they want. You guys start coding, right? Does this sound familiar? Sort of like the Titanic, right? Full speed ahead. What icebergs? Don't worry about it. Yep. Because we had a good framework in place that was to be, and my boss was instrumental in getting that in place to be done. So I thank God for that, actually. When the management under worked very well. Well, they understand each other very well, but one side has five applications. The other side has 40. Guess who wins? They have more people, more money, and everything else. So the problem is, if I didn't force myself on them, they still wouldn't have talked to me. What's the definition of a human? A being that resists change, right? If you're going to do something all the time and you're going to be successful at it, your next engagement, you're going to do it again, right? So that's what I was dealing with. But anyway, nice guys. I got along with them great, and we're on our way now. But it took a little bit. All right. The following architectural components are what's used in this initiative. We used ARIS, which is a business process modeler. We used the CA Irwin data modeler. And we used the ASG Roshade metadata repository. Luckily for us, one of our parents, one of our parent organization, had a copy of Roshade. So we just bought some extra scanners. And we told them it's in your best interest to take our knowledge of the tool and take your tool and let's collaborate. So we did that, and that worked out really great. But there was no data management process or governance to implementation of this approach, all right? Now, some of the definitions here I want to go over. The OV6 is a process model at a very high business operational level. That's what OV means, operational view. The div 1, 2, and 3 are the conceptual, logical, and physical models. So if you see them in the document, you'll know what they are. The SV10 is the system or application or logical view of the developer level processes. This is the last lowest level, detailed level of the process that the developers would use, OK? But as you know, developers like to have the physical names as well. And I'll show you what we did with that, all right? And everything you're going to see about data management and governance are just for this particular process that I put together, just so you know. There's other parts of data management and data governance that I'm not covering here, but it exists. OK, recommended solution. First of all, they had to realize that DML needs to capture and manage metadata at an enterprise level. Too many times, we deal with, and I'll cover this now, the application level. Now, when I first got there, they thought that this middle layer didn't need to exist, that they can go right from the enterprise, right down to the application. Now, in a small company that may work, but in any company of size, is this the same exact thing as up here? Never, all right? There's this intermediate contextual level where the context of what's listed up here is now feted out. So this is a one to many, and this is a one to many down here, all right? Now remember, this LOB level, line of business, or I call it program in here, because that's what we called it, and application or system level are the guts of what I'm going to be talking about. But let's not forget what's up here, because this is where everybody searches. Everybody in the enterprise is going to want to know, all right, if I have a customer, what kind of customers do I have? Where are they at? What line of business, okay? Similarly, business terms over on this level, this is an enterprise level business term up here, customer, production order, process order, something generic. This is very abstract and generic at this level, but it points to something that's could be feted out at the conceptual level, just a conceptual data model which would exist, and then that has a relationship with the logical physical models, okay? Any questions on this? Yes, exactly. And thank you for bringing that up. The conceptual level we had were just entity level, okay? It's a concept. You don't need attribution yet. The attribution comes when you get to the logical level, and then physical level obviously drills down from that, yes, that one? Do you have a question about something? I mean, these were parts, whoops, parts of the the DODAF, Department of Defense Architectural Framework. Right, thank you. There are other artifacts in that framework that we didn't use for this particular process, yes? Absolutely. Now everything I read in the Department of Defense documents did not say that there was attribution at that level, okay? That's, I don't know if they gave me the wrong documents to read or whatever, but I chose not to do it anyway, but yes. All right, yeah. You understand what I'm saying. Yup. You'll see that later on, but for right now I'll tell you at the conceptual level we would have create material item list, which is the list that we have of all the medical supplies that need to be shipped out, patient streams, patient conditions, those kind of high level concepts, which then break down into several entities and attributes to perform the function, okay? Okay, let's talk about the granularity. I first became aware of this when I received what was called the div one conceptual data model with attributes on it at the code level, and this is, wait a minute, something's wrong here. Number one, it did not cover anything that was in the OV6, the operational view that we were given. Number two, it was horribly associated, and I should have actually bought it here to show you. What I did was I dug and found out that a non-data modeler had put together a conceptual data model, okay? She was a brilliant business analyst and did a good job of gathering requirements, but she was asked to do this unknown to me and failed miserably at it, so what I did was I stepped in and we had a little training session and we got her up to speed on that. Not that you wanna do that, but yeah. Yeah, and instead of asking for help of somebody who does know and could help them along, they decided to put it out there. Now, unfortunately, I found out about it after we got the review back from the parent company and they says, there's attribution in here, what is this? It's like, okay, yes. There were two data modelers in her building, but she had very little contact with them, okay? Okay, no, no, no. This is common, yeah. Really? Almost, but maybe hopefully Nick, one site doesn't write. I haven't found it yet, but. Well, we're on our way of doing it. Of course, we got other challenges as well, yes. So Bob, with this framework set in place before that individual started? Yes. No, this, what I developed, was not. So in all fairness to her, she had the same documents I did about the Div1, though. You had a requirement to do. No, just Div1 at that point. Okay, all right, go ahead. We were not gonna trust her with any kind of logical model. At least they didn't trust her with a logical model. Okay, so the big problem was the confusion within Aris, the process modeling itself, modeler itself. So I asked the guy that was in charge, the enterprise architect that was in charge of Aris. I says, give me a dump of everything you have, and we'll throw it into the repository and find out what we have. What we found out was they had at least two of the same exact elements, named differently. And Aris is a good tool. All you had to do was say, yes, this is this. And it brought it in here to actually associate that at the same level of an existing element. They chose to create a new one, okay? We had different granularity. And by granularity, let me clarify that. There's the high level views, and then there's the system views, which are at real detail level. Both of them were in there. Now, there are reasons why they do that. But in an OV6, which we have to glean those high level business processes out of, there should only be high level business processes out there. The system level comes later, as we'll see. All right. So the solution, he was already creating an Aris user guide. And I says, all right, what we have to do is we gotta put governance in there. And then what we'll do is we'll bring that in, we'll separate that and create this high level business term that's above the OV6 level and put that in a repository. So this way, if they want customer, we'll list all the customers at that OV6 level in the repository. So this way, they can look it up, find out what they need, what area they need it in, and then go from there, okay? Now, this took, well, I'll save this. I'll save this particular statement till later. The Div1 conceptual model element must be at the program or mission thread levels. That's this LOB level right here. That's where things start to conceptualize, where you take your OV6 as your operational views and you actually break it down into workable processes that we're gonna need to go forward with. That's where you get, glean your data elements out. That's where you create your conceptual data model out of at that level. And they also call the mission threads too. They had various ways of splitting things up. I says, fine, if it makes sense for you to put it at this level and call it mission thread, call it mission thread. If you need four levels, do four levels, but make sure they're definable and you keep them in their own part of that hierarchy, okay? Any questions on it? And this is the pyramid that's over there as well. A little more descriptive. The enterprise level asset is the highest level. It's not in the ARIS process, all right? Because the ARIS deals with that high level in other artifacts, but not within what we're doing here. The programmer line of business level grouping of application is by the business view or purpose. Everything we did at this particular level, at this level here, is by business view. If it doesn't exist, we make it. Otherwise it doesn't get drilled down, okay? And we didn't have any problem with that portion of it either. Yeah, we'll get to that. I got examples for that. If I don't get to it, remind me. The application or system level is your local application level, okay? For this particular presentation, yes. Because business terms are assets. Assets are business terms. Also, assets could be something else, but not in the context of what I'm presenting here, okay? This goes into a little bit more level of how I define the different levels. The assets will be managed in the metadata repository. We actually created the three different levels in the repository of business terms. Because think about how your business people handle all of these. Do they think in, oh, it's in this data model? Or anything like that? No. All they wanna know is, where's my customer? Where's my account? Where's account number? And those are business terms. And they're at both the entity and attribute level. So, we have to give them some kind of hierarchy here so they can drill down to find what they need. Yes, the data what? The enterprise architects and enterprise data architects deal with the enterprise and conceptual level. Right up front. The enterprise architects are the ones that do the process modeling. The enterprise data architect, which I am, do the div ones, conceptual data models, and then assist with the transformation of that into the div two, logical data model. But at the logical data model level, we have the information architect or data modelers. Okay. Yes. Yes. Nope. They're abstract. And they may have the same name and I'll explain that in a little bit. I have examples. Okay, let's talk about the business terms for a little bit. Here's an example that I promised you guys. Up here, we got the enterprise business term, which was a new term to what they were using. This is not at the data model level, so forget about that. All this is is record. How many records does your enterprise have? Right? Well, three of them are mentioned here. However, at this level, they may all be named records. Are they the same? No, they're different. They're gonna have different attribution. They're gonna have different processes that they perform. Right? So, this is at the div one, conceptual level, the OV six level. That's that here. Okay? That drills down, and these are one to many's. Okay? One to many and then one to many here. Now we get to the logical physical level. All right? So then we drill down. Let's say I'm looking for a record and I wanna know, all right, I want an equipment record. So now I'm gonna drill down into here, into the repository. The repository's gonna bring up the different records that I have in my different data models associated with this particular area or line of business. All right? Now, down here, we break it up into the logical and physical, right? We, Erwin gives you both logical and physical, so do the other data modeling tools. But I wanna bring your attention down here. Here's equipment underscore ID. Are they the same? You remember I mentioned over here that they thought they could eliminate this level and go right from enterprise to application? Well, what if I have equipment ID up here that's gonna go right down here? Is it the same? How do you know it's different? There's no way that they have of knowing that this term up here means exactly the same thing in all the applications. Now that's an important point. If you don't get that, let me know. Break group. Either that or I lost you. No. They're both primary keys, but they're primary keys to different tables if you wanna look at it that way, okay? This one is the primary key to the maintenance record. This one is the primary key to equipment record, okay? But they're both named the same thing. How many times have you seen within your portfolio, right? Everything is named the same, but means something different. And how many bad decisions have been made because you make that assumption? This takes that whole, all the way out because now you know that this equipment ID, let me look where it comes from. Oh, it comes from here, all right? Now if I look at record up here, both of these are gonna show up, right? Yes. Nope, actually I never heard of it. But then again, I'm just a lowly enterprise data architect in one small division of the DOD, probably. So I'd really be interested in learning about that. Because I always like to know what's going on. Yes, your lady in the back. This up here, called customer, would then be mapped to each occurrence at this LOB level. Is it a customer? In sales is a prospect, a customer, something they're calling a customer. You don't know, you have to do some analysis there. But who better to do that analysis than the steward of this line of business? Do they know their data better than I do? Yeah, right? Yes. No, we're matching on meaning. If customers up here, or prospect is up here, then customer within sales would be here. You got that? Meaning, it has to be meaning. It's really a prospect, but they're calling it customer here. And we don't wanna change that, right? As a matter of fact, one of the guys said, oh, we're gonna have them change the name of their entities. Yeah. And he really believed it. Okay? Now, us, we who have been through it, know that that's impossible. Go ahead. He's giving us an example of a hominem. Yeah. Where you have one name, two things. It means two different things. This is one of the ways mechanisms we use to identify them. You don't, let me make one thing clear. Hold on. This is not to fix anything yet. You're in your gathering phase. This is to classify and define what it is. So this way, when these stewards get together at this level, they could say, you know what, I have equipment ID down here. Oh, so do I. What's it an equipment ID for? Oh, it's for a record. Oh, all right. Mine's for a maintenance record. It's a little different. Or maybe they get together and they say, you know what, it's the same. Okay? Yeah, good. Forget about the word record. As a customer, okay, that's a business issue. That is, this guy is referred to in terms of, that's where your conversation is. The record is, it's all magic, because that's the technology. Okay, I guess the issue for me is, I'm not, where you want to take your conversation. Because when I look at the framework, I typically think that this is a three-layer architecture that is prescriptive in nature. What I seem to see on the right-hand side of the screen is something that's descriptive in nature. In other words, catalog the assets as they are today. And then show the disparity so that at a point in time I can do the bits. All right, in the meantime, where are you gonna put them? Right. That's all I'm saying. He's heard it his presentation all the way through the data. And I mean. I haven't heard anything this whole week yet. Right. Yeah. At this point, but I apologize, I did show a play. So. No problem. No, we'll call it a prospect. Even though they call a customer. And this is where the enterprise data architect, which is me, would need to meet with them and say, all right, what exactly is this? And then, yes you could. It might be a one-to-one. It is, it's an abstract term. And it's meant to be that way. That's where analysis comes in. You let them call this level what they wanna call it. Now, when you do your analysis to see where it goes, then you may have to add another term up here. Or you may have to have this associated with something. Now, there's nothing that says that this is named record and this is named record either. Cause you're gonna find that. All right. No, this is one-to-many. One of the many in here. Okay. If that's the case, it will be listed twice. Now, in very rare occasions, yes it does happen. Okay, then maybe this is your retail and under here you have another level in here that has your particular groupings or geographical location or whatever. You're not limited to three levels here. It depends on what your company is doing. Then maybe you put both terms up here, but be very careful about what you put up here. This is an abstract term. You may be bleeding from this level in which I've had that problem with a couple people. All right. Yes. It's more of a abstract term that the data person does right. What he will do, and this is how it should work, is that he looks at all the different records that are listed here. And everything that might be called a record and then makes that association. Okay. Yeah, this layer is what you do your preliminary analysis on. Because this is what you know. You know your applications. You know your grouping of applications within line of business or whatever. Okay. Now, one of the problems I had was actually all of the enterprise architects were sold on the concept of having an enterprise. Let me get this right. Enterprise-wide business logical data model. Basically a div two at the enterprise level. All right. This is how he started. Now, I don't know where they got the concept and I'm not gonna say that enterprise-wide logical data models can't exist, but I've never seen one that actually works. And for the reason, let me just cover this a minute. And this is why I have a big problem with it. Over here, you have requirement, right? Well, now they break it down into facility requirement, item requirement. Is that consistent throughout all of the enterprise? Does item requirement mean the same thing throughout all the enterprise? Does maintenance plan mean the same thing throughout all the enterprise? What they did was they took two applications and one of them was actually an offshoot of it, of another one, put them together and called it an enterprise-wide business logical data model. So my question to them was, all right, does all these enterprise-wide business logical data models have the same attribution throughout all the enterprise? Does it have the same associations and links to all the enterprise? And the answer I got back was yes. I was like, okay, that's for two of the 50 applications that we have. What about the other ones? Oh, we're gonna force them to use this. Has anybody ever forced a business person to use their data model? Because I want to really want to talk to that person. Yes, no, I did not. Well, now at least I know where they got it from. You know what? If you're through to wars like many of us have been, you've been called in to fix an enterprise logical data model. And you know what? I throw out my hands and I say, look, I'd just be ripping you off. And then I explained to them why. And if they were able to do it, they would have, let's take item, they would have 100 items. And then you'd end up with spaghetti code. Not only that, you'd have to force your business people what to do. So that's when I came up with, and I kept these lines in there just to make them happy. I came up with different business terms and those are on this enterprise level. For instance, catalog, requirement, item, record, these are all generic enough to point to other types of these business terms, right? If you'll notice over here, I took these item, these requirements and just left that requirement, right? Down here, I took record out and just put a record in. All right, now what did I do with the ones I took out? I put them at the conceptual level. So this way they're there. These are valid elements right here. Forget about this right here for now. But these are valid elements for that particular application or that particular conceptual model, right? So I didn't wanna get rid of them, but I wanted to show them how I'd split it up into something that would work. Now, over here is another div one or conceptual data model that I worked on. And these were some of the bare bones that we had from the OV-6s that I bought in and these were what I would do is look at the process model, find out what they were doing and then extrapolate what kind of relationships we had. And that's what this is right here. Now. Huh? No, no, it's just showing that there is a relationship between them. All these need to exist for the casualty stream to exist. Yes, in what? In what I'm presenting, there's two different conceptual models here. They're entirely separate. Yes, and you'll see that in a minute. I guess you guys didn't print out the handouts. I mean all of DML not DOD. Okay, yeah, thank you for that. I meant to mention that. Yes, yes, I'll have that in a bit. Somebody back here? Okay, all right, let me get to an example and it's probably a pull together for a little, some more of you. We mentioned the record, right? Now, within record, it's linked to three different records. It could be 10, it could be 20, depending on how many lines of businesses you have and how many conceptual data models you have. Okay, but if I wanna look up record in the repository, these three are gonna pop up and they're gonna pop up and say, all right, this one is in the maintenance LOB, this one is in the equipment's LOB, this one is in the integrated logistics LOB. Okay? Similarly over here, you have production order. All right, this is what I meant by the mission thread level down here. Optical production order. There's the assemblage production order, equipment maintenance production order. All right, so all these, if I wanna look up production order, I type that in and it brings up these three and lets us know that they're in these different mission threads or LOBs. No, it's a one to many. Yeah. If you wanna look at it that way, however, these are separate unto themselves and only valid within different lines of business. An instance of a record is either. No. The instance of a equipment record? It's the same. It's a parent truck. Up here. Unless you're talking about. Right. It wouldn't exist without that. Right. Yeah, well. Yeah. Yeah, conceptual, yeah. Yeah, look at it as a placeholder to point to all your occurrences of the other records within your conceptual and logical. Because afterwards. Pardon? Yeah, this is a separate entity unto itself within the conceptual model. I don't know if that answers your question. How much time we got left? None? Oh, geez, okay. Let me get through this a minute. This is the flow of everything. Aris here, you do the process models. Over here, you're gonna have to do some JAD sessions before you create your logical data model. Then it comes down. You create your div three, which loads into the Oracle. Or you can reverse engineer it, which is what they had to do a lot of times, then recreate the logical model to make it conform. Over here is the relationships as well. Let me get to this right here. Because this has the governance gates as well. This is the OV6 here. You'll notice all of the, I don't know if you can really read it, but patient stream would then come into the div one conceptual model, and then that patient stream would go and it breaks down into three different tables in the logical data model to perform different acts. Like I said, whereas working with Agile, they like different tables for lookups and things like that. Then it would go down to the physical data model, load into Oracle. In the meantime, we have the scanners that would scan all the information into the repository. So we had traceability from here to here to here and then to here. And then what happens is it takes the logical elements that are loaded into Racheid and brings it back into the SV10s, which is the system level application. And governance gates for each of those purposes. Can you give two and give three? Yes. Okay, I guess that's time. But if you look at what's on, I gave it to them early enough where they can give you the actual presentation. You can get through this and it's pretty self-explanatory. What we did. The metadata repository is used for all of this as well. And the last part is feed the developers. You have all these different metadata stores that come in and it's integrated into the repository for the developer to create reports or extracts for whatever they need. Benefits for developers, a high-level plan. You could do it. Sorry I ran out of time. I thought we had more time, but any questions? I'll be outside if anybody wants to talk more about it. We have to vacate the room right now. All right, thank you.