 I'm Gordon Evers from the University of Minnesota. I'm formally retired, but I'm still teaching. My favorite class, which is the class on data modeling, advanced data modeling. And the students that come into that are ones that have had or should have had an interdict directory course in database. So they've used the database management system. They set up some tables. They've done some querying, some SQL stuff. And then they come in. And the first thing they discover is what they don't know. In fact, David Hay and I had a very interesting exercise over a beer last night, because I was saying, even professionals aren't able to answer some of the initial exercises that I have in the class. And he said, oh, what are those? And so I presented one to him. And he struggled, and he struggled, and he struggled. Well, it was because he kept thinking about tables and trying to put things in tables. And if you do that, you're going to get all bound up. And that's a little plug for object role modeling. I'm not doing anything on object role modeling this year. I did last year. But anyway, the talk that I'm doing this time, I have spent a lot of time with many different organizations helping them design databases. And it always involves working with the business users. In fact, it's important to get the right business users there, the ones who know their world. And when I go into a company or into an organization, one of the preconditions is that I'm not going to be the one that keeps doing this in that company. I'm going to do it once. And I expect them to have observers or participants, preferably from IT, who can learn how I do it and can clone that. And that's happened in many organizations, so that they can begin to do it themselves. I think a lot of times the data modeling activity that we do have in organizations is really poor. And the problem is that you've got to get the stuff from the users. You can't just come up with it as data modelers. Unfortunately, there are many data modelers that think they know better than the users. And that's pretty presumptuous. Anyway, this is really an amalgam across several different projects that I've been involved with, probably 20 or 30 over the years. And OK. So the outline we're going to talk about, there are different ways that you can elicit. And I love that expression. I got set right on that today at this conference. It's not gathering requirements because it's not a passive activity. It's sometimes like pulling teeth to get the users to tell you what their world looks like. So eliciting response. You can do it through a variety of ways. My preferred way, and it's not the only way, but is to have an extended series of project meetings. And so I'm going to spend a lot of time talking about that, what I mean by design project meetings. And then I will talk about the role of interviews and other types of group meetings as alternatives, or let's say to complement. Just to put data modeling in a context, when you're building an information system, first you have to set some priorities, and you have to do some scoping, and figure out what is the area in which we're going to be talking to the users about. So carve out a portfolio of development projects based upon priority and level of understanding, and simplicity, and greatest payoff, and so on. You can go through a design phase, and there's four different things that we design in general. There's the data, there's the processes that become application programs, there's the user interfaces, and then there's the platform on which you're going to run all this stuff, the computers and communication networks, and storage devices. And then as you do this, part by part in an organization, you can fold that up into an enterprise-wide data model, and gradually grow that as you go through these kinds of exercises. You might start out with a simplified enterprise data model, and then flush that out by feeding back information from these projects. So the design product is stored in a design database and then you can construct the system, generate code or whatever it happens to be. And I'm not concerned with that part of the process. Here we're talking about how do we populate that design database. The chosen user area that I'm going to focus my attention around is the right-of-way section of the Minnesota Department of Transportation. The right-of-way section is responsible for obtaining the right to build the road over the land. So they first have to decide where they're gonna build the road, and that's usually all kinds of neighbor and community hearings and so on. And then once they've decided and agreed upon where they're gonna build the road, they have to acquire the land rights, the surface rights, not the mineral and not the air rights, but the surface rights to build the road over that area. And there's usually a lot of owners involved. They've got to make some appraisals and make purchase offers. And if those are all rejected, go through a process of eminent domain to acquire the land anyway and then build the road. And so once they have all the road, there was a piece of road in Minnesota that we waited for over 10 years to gain the rights to all of the road pieces before they could start the construction. So that can happen. So that's just a list of the activities that are involved there. This particular project was one that had a reasonably manageable scope. It wasn't too complex. There was a great need for it because at this particular time, and this was some years back, but the principles of running the project meetings are the same, essentially. Very high payoff. What they were doing was they had about 100 people in this organization that was involved in the right of way and they had all of the information in Manila folder files on cards that would be wheeled around from one department to another and from one desk to another. And if anybody took some information out, they would have to put in sort of a replacement flag saying where it was so that if somebody else wanted to get it, they would know where to go to get it. And so it was things like land records and information that they gather in this process. It was mostly this manual operation. There had been two prior attempts to computerize this function. Both of them were horrible failures. So this group of people were very resistant to being computerized. There had been two efforts before and they had a real bad taste in them up. So they were reluctant to even embark in this attempt. They maintained one cobalt file with some 250 data items to describe pieces of road in the state of Minnesota. And that file served no internal purpose. It turns out it was simply a record of all the parcels of land the state of Minnesota owns. And the only time they needed that was when somebody in the legislature asked them how many pieces of road do we have and what are they worth? And so they could provide an answer to that question. So that's the internal operations. Okay, so the process that I would go through. First of all, you gotta pick the project as I said before. And then choose the area of application after you've done that kind of inventory of where things are in the organization. Have a meeting with top management. And at this initial meeting, we wanna have the management of the user area represented from the IS department and then the database expert facilitator. And that was me. We explained the process and the product, what we're gonna try to produce and so on. One of the interesting things was and the benefits and so on, but they wanted to know how long is this gonna take? I said, I don't know. I mean, what are the things that contribute to how long it takes to do a project? One is obviously complexity. And until you've dug into it, your complexity is somewhat of a guess. Well, they pushed me on that one. And I said, well, somewhere between 12 and 18 months. And that had to suffice them. But it ends up that the project took 15 months, right in the middle of that. The purpose here was to obtain a commitment for management so that they could tell the users when this project calls for you to come to a user meeting, you be there. And that's what you have to hear from the management. So we had a kickoff training session about 50 of those people came. I told them about what we do in data modeling and it went right over their heads, I'm sure. But I had a framework to hang on as we went through the series of meetings. They began gradually to understand what is a many to many relationship, for example. What does it mean for there to be a dependency? And then we started a series of these project meetings. At this meeting, I explained the objective of data modeling. What we're trying to do is to model the user's world. And I can't emphasize that enough. We are not modeling a database and we are not modeling to even build a database. We are modeling the user's world. Whether we implement it or not is a separate question. That's based upon the priorities and the available resources. We're modeling within a defined scope to accurately completely model a chosen user's domain. Why do we do that? So we can understand that domain. We ultimately are gonna ask the users to validate this model. And you can't validate something unless you understand it. And it's our responsibility to ensure that they understand it. What are the principles of data modeling? The benefits, the process, and the product would be a model in data. To call it a data model is really interesting because it's not a data model. It's a user world model in data. Yeah, that's a little semantic thing. A few principles that I have. We do data modeling at the highest conceptual level. In our modeling scheme, we do not want to impose any artificialities, any spurious kinds of constructs that are unnecessary from the user's understanding. And I'll give you just one example. There are people out there that say, oh, you've got to resolve all your many to many relationships with an intersection entity, an association entity. And I say it's a many to many relationship. Do you think users can understand it? If I draw two boxes with a fork at each end, users can't understand a many to many relationship? I think most of them can. In fact, it would be more confusing for you to stick two one to manys down to an association entity. Because then the idea that that is, yes, that is a many to many relationship, no, it's not a separate entity. It might be. But it's first and foremost a many to many relationship. So that's just one of the things. And that happens to be a limitation that's imposed by the relational model because we cannot have multiple pointers, multiple foreign keys in a table. So that's just one example of the kind of thing that we really need to, in our choice of modeling tool, at the highest level, at which we're going to prepare and present things to the users. We want to do it in a way that doesn't obscure the basic information. Question? Well, that is a repeating group. If you've got an employee that has multiple skills, where are you going to have to put the skills information in an employee table? You can't put it in the table. You have to have a separate skills table where you've got the confidence and key of employees and skills. Do you think users can understand the concept of a multiple-valued attribute? Of course they can. In fact, in the diagram and documentation, we would do it that way. You don't have to have flat records for the user, flat tables. Yeah, yeah, yeah. Exactly. Yep, yep. Sir, whatever communicates best with the user because that's our goal. And anything that interferes with that goal is undesirable. And if it's not necessary, don't do it. It's easier. Here's another principle I like. First of all, you have to, yeah, involve all the interested parties. You want to find out who all the stakeholders are. Because if you don't have them all at the table and somebody comes along and says, oh, I need information, or I have information about customers, and you haven't brought them to the table in the design of the customer information, you have a problem. It's easier for users to learn about data modeling than it is for data modelers to learn about the user environment. The user environment is a lot more complex. I don't care what user environment it is. But data modelers, at the very least, my message is, don't presume their world. And even if you think you do, keep your mouth shut and listen to them. They're the ones that have to sign off it. And they're not going to sign off on something that you do. They're going to sign off on something that they do. Capture all possible or expressible semantics. So one of our goals in modeling is to capture as rich a set of semantics as possible. Whether it's expressible in your favorite data modeling tool or in your DBMS, that doesn't matter. Capture it anyway. Maybe you write a trigger and a stored procedure to enforce it, but that's a whole separate question. That's an implementation question. Another principle that's really important, the users collectively, not individually, but the users collectively, will always know more about their world than we could ever formally express in a model. Always know more. So is a model ever complete? No. It can't possibly be. There are things that we just don't know or don't know how to express in that world. And finally, be inclusive within the agreed upon scope. Be inclusive. If there's anything out there that the users talk about, put it in the model. Now putting it in the model, the next thing you have to do is you have to tell users, no, we're not necessarily going to implement that because that's a down the road question. At least get it in the model and if you don't implement it, you at least see where it belongs. You at least see how it fits into the model. All right. So I talk at the initial stage, what are the benefits of data modeling? And you can read through some of those. Let me just indicate that the last couple of bullets there, it's a base for information system development. So often we don't do a good job of designing a database and we build a poor design. And then the ways in which it's a poor design, that has to be compromised, let's say, by the application developers. They have to figure the workarounds and that can be very expensive. Better to get your data model right first and then do your coding. Of course, you have to have some analysis of the process, business processes first before you even can begin to do data modeling. The database will be more viable and more stable. In this particular environment, I'll give you just a glimpse of what happened. Some, we came up with about 40 major entities and 15 years later, I had one of my students was in that organization and they said, you know, we haven't still fully built out that model and they still call it the Everest model. It was interesting. But it was guiding their application development activities for many years to come. And the reason why is because we made sure that we had an accurate reflection of users' world. Data modeling is a small part of the total IS effort, I would argue, the development effort. But when it's done right, it can reduce the overall development costs. If it's done wrong, the downstream impasse can be disastrous and costly. You don't want the application development people to be making up for a poor design. Yeah, question. Can I defer that question? I just went through Lynn Silverston's workshop on Agile and he gave me a perspective. I think there need to be some parallel efforts. I'll just give you a quick answer. I think there need to be parallel efforts. One is a long-term modeling effort. And then within that, there can be these Agile things. The goal of Agile is Agile software development. It's not Agile data modeling. You cannot develop a data model in three weeks. But you have to have a base there. Now you can set some priorities on which part of the model, which part of the user's world, you're gonna try to flesh out, okay, based upon whatever schedules you have for your Agile development, okay? That would be my view, okay? So you're gathering information. Once you've set the scope and the objectives, everybody agrees what you're trying to do. You're trying to model their world. And so a series of questions. Where would you go? What would you look for? Who would you talk to? And what would you ask? Okay, let's suppose, you know, I've already said you wanna talk to the key users. But let's say we're talking to the business users. What questions do you have? Are you gonna ask them, what information do you need to make good decisions? What information do you need to do your job? Or show me a job description for your job. What are the major entities that you deal with? You know what's gonna happen if you ask these questions? What are your major entities? Here he goes again, right? Show me some input forms. Show me some output reports. Show me some existing documentation of databases. Or files. They can bring and show you some of those things. But what's the question that is going to really get them set off? Let me give you a clue. If you go to a party and you wanna start a conversation with somebody, what's the question do you ask? What do you do? It's a no-brainer. And you know what happens? If you show genuine interest, they'll dump all over you. Because they're excited that somebody's interested. That's exactly what'll happen here. Tell me what you do. Describe to me a day in your life at work. What do you do in your job? Bring some of the artifacts that you work with. That'll be some of the other things, like output reports, input forms and so on. You won't get them to stop talking if you start with that. And that was at Steve Hoverman in his workshop. He said, that's the key. Ask them what they do. Oh, no. I have a turning point thing where everybody can have clickers. And I wanted them to click and give me the top three. So we're not doing that now. But we're not talking about implementing a system here. Well, all I can, sharing doesn't happen very well. My experience has been, if you're open and honest with them, the sharing question, or the desire not to share to be protective, that just goes away. You have to show them you're serious about describing their world. And they want to describe their world to you. If you come back and say, we've got this database design project and we want to build a database and we want to make sure it's right. You're not asking the right kinds of questions, okay? Questions to their work. Yes, absolutely, absolutely. One of the things we said, one of the benefits is they gain an understanding of their world. That's fine. But that depends upon the kind of user you have. Yes, they'll tell you what they have. But that's why you have to pick the right kinds of users. And I'll speak more to that in a moment. Oh, this is what I like as my ABC to EFD. EFD, modeling process. Ask and analyze, bounce back and forth what they're telling you, make sure that you understand that, and then design. And that's the important part. Design, design, document, put it in a dictionary, have a narrative associated with that, and then evaluate that against the users, the experts, and the rules of construction in your data modeling scheme. Formalize that in a data model and generate the definition for a DVMS. Now, of course, there's pieces to this, but the important point here is in coming up with the model, it's predicated upon you understanding their world. I can't emphasize that enough. That's your goal, is to understand their world and you want to communicate, and you want to capture that, document that in a way that you can give it back to them and say, is that a reflection of your world? And you shouldn't be building application systems or revising them or whatever until you've established that and the users have agreed. All right, so here are some best practices that I've come up with. First of all, I find that bi-weekly meetings are the best with the users. Now, this sounds like it's gonna take a long time, but one of the things that you're doing in running these meetings is you got the users together, they're gonna talk about, then you want to try to document the kinds of decisions or the kinds of things that have been talking so they have to take that away, prepare that documentation, echo it back to the users, they need an opportunity to review it, come up with some additional questions and then they come to the next meeting. And my experience has been we can't quite do that in a one-week cycle. And we'd like to do it in maybe a 10-day cycle, but it's easier if you say every other Tuesday we're gonna have a meeting. Second of all, well, and then spanning a night. We don't have full-day meetings. You probably all know that if you try to do a full-day meeting, the second half of the day is about a quarter or a third as productive as the first half. And so one of the ways that when people were coming from out of town on a project, one of the things we'll do is we have an afternoon, they go rest and relax at a hotel and then we have four hours the next morning and then they go back home. And that was very fruitful to do it that way. You want as participants, first of all, we look for a commitment of a half a day a week, half a day for the meeting and half a day to review what you're writing and cycling back week by week, meeting by meeting. You wanna get the knowledgeable, the visionaries and the thorns in your side. You wanna get the people who are complaining, they are observing and complaining about what's going on in your company. And you can all find those people. You don't want the passive people who just sort of accept the status quo and don't think about how could it be done better. Okay, ask them what they do. Rotate experts in and out as you step through the domain. You set the scope but you can't do it all at once. So as you move area to area, like this right away section there were 100 people but we wouldn't have 100 people. The meeting we would probably have eight or 10 or 12 or 15 depending upon which area we were working with. The facilitator needs to be an outsider. An outsider can be independent of the politics or above the politics. They need to be experienced in the process but not the domain. And if they are, I said before, keep your mouth shut, listen to what they have to say. Solicit user input. Get their individual perceptions on the table. You ask the dumb questions. And you know what I found? If I ask, because you see, they don't want to look bad among their peers so they're not going to ask the dumb questions. At least not initially. But if I set the example of asking all the dumb questions, you know what? They will feel free to ask the dumb questions of each other. The facilitator who knows something, I'm a data modeler too, okay? And we're trying to come up with a data model. So the facilitator should be somebody who has some expertise in data modeling. But probably more important is they have some expertise in eliciting responses from people. And make sure that everybody has a chance to talk, et cetera. Yep, that would be a good approach, yes. Then we need to scribe somebody who can record what goes on at the meetings. And for that I asked that it be somebody half time. Responsibility. And I found that that's just about right. We evolve documentation, we grow documentation. They are not recording minutes of each meeting. They're taking what's said, some of it may be a revision or modification of previous discussions they've had. Some might be new stuff, whatever it is, you're trying to grow a set of documentation. And finally, you want to negotiate to a collective agreement, that's your goal. Your goal is to get the user's picture, their collective view of their world. How do you decide to get the right people to the table? Well, the old standard information architecture or some of you know that as the crud matrix is a way of finding out. Here we've got the data areas down the side and across the top we have the functional areas. And so you can look at a chart like this, a matrix like this, and you can look across, say okay, we're going to do some work in, let's say, what's a good, this is obviously made up, but let's say product, we're going to try to design around the product information and you look at this and you see all of the people who read it, you notice nobody creates it and nobody updates it, so there's something wrong with the model. And that's okay, because this reveals things like that. You say, you're going to ask the question then, okay, who is responsible for creating and maintaining product data? Because you want to make sure that they're at the table. The raw material one underneath it, I think that's one that shows everybody updates but nobody reads it. But the point is, you can use some kind of a mechanism to help you find out all the functional areas that touch that information there ought to be representatives at the table. The product, the documentation that we produce, first of all, we had a set of guidelines for that. At the front end of it, set the scope and the objectives, and it starts with some use cases. What is it that you do in your organization so it can be use cases? And let me say a useful way of categorizing use cases is those that set things up for industrialization, retrieval and reporting, update and maintenance, archival, and destruction. Archive is simply to take off of active storage and destruction is to actually destroy. And it's interesting that there's not a lot of attention. How many of you have formal record destruction policies? If you didn't put your hand up, talk to your legal department and find out how important that might be. If you can't show in a court of why certain information is missing, like a 20 minute gap in a Friday afternoon audio tape, and some of you can relate to that, then you're suspect immediately. But if you can show that you destroyed that in the normal course of events, you're completely off the hook, legally. You have your excuse. We didn't destroy it because you asked for it and we said, oh, we'd better quickly get rid of it. Okay, that's a violation. Right, right. And he's saying lawyers will wanna destroy it quickly and that's true, but you gotta bring all the stakeholders to the table, okay? Your goal is to get a global model diagram with a narrative description of entities, relationships, attributes, and we do things like one attribute per page description. We'd look at that and sometimes there wasn't a lot of information there. Some at times attribute description would end up being many pages. And then, and this could be later, formalize the description in a DDL and generate for a target DBMS, okay? So, just a couple of experiences in this case. The users got excited. As they would be talking to each other, we'd say, what do you do? And then somebody else, and they'd been working together for 20 or 30 years, say, oh, I didn't realize you did that. Immediately, that begins to open up more floodgates for you. They were getting excited about learning about their world in dimensions that they never did before. Learning and self-confidence grew. They started asking each other the dumb questions. In fact, it's interesting because at one point I tore my Achilles tendon, collapsed on the gym floor, and I couldn't move, basically. And so, the scribe came to me and said, I guess we'll have to spend the meetings. And I said, no, they're getting pretty good at asking each other these questions. And so, just document what the discussion. Well, he came back to me in the hospital and he was in tears. I said, okay, I guess we'll suspend the meetings till I get back. And we did for, I don't know, about six weeks. And I came back and we were just embarking on another dimension, another area, of that overall model. And we got into that, it was eminent domain and condemnation. And I said, well, no wonder you got discouraged. I said, this is much more complicated than anything that we've done before. So, relationship with Central IS. We had a Central IS people, remember my deal is, you're going to have somebody that can clone my expertise. He came a few times, a few months later, stop coming. Why do you suppose? That's an interesting thing to speculate. I mean, he had an opportunity to really advance his career by becoming an in-house expert in running data, these kinds of model meetings. Well, what do you suppose was going on at all these meetings? What were they talking about? What was that? Trashing. Trashing, I, no, no, that wouldn't be it. They're talking about their world. This is an IT guy. He is not interested in finding out about everybody's world. As far as he was concerned, this was wasting his time. One user forged ahead early. He came to me and he said, we've now designed the appraisal section information. And he was the manager of the appraisal section. He said, do you think it would be okay if I started to put some of this in a spreadsheet in Excel? I said, sure. They didn't, it wouldn't have been very much volume. But he was excited to do that. It's just to buy and install new equipment. Anyway, we produced about 40 pages of documentation. We used a case tool to help in the documentation. This is an example of a picture that we ended up with after these 15 months. So, some guidelines. I won't go through the details of this. What I want to do, just a couple of things. We are, we only know the user's reality through the perceptions and the minds of people and it needs to be the people who know something about that world. And at the end, we are seeking consensus among those people. And so the whole process is a process of negotiation. They have to negotiate away their differences and come to consensus or come to agreement. There was one interesting thing here. We'd say, what is an entity? Or what is a file? And I finally figured out how I could answer that question. Anything that is in replication. So if you see a form that gets filled out many times, or see a report that has several lines, that's an indication that you've got a file somewhere. Or an entity. Here are some best practices, just to summarize a little bit. Top management support, don't be limited to a fixed deadline. The one thing that I have found on every project, except one, is that we always know when we're done. So this isn't something that would continue on indefinitely. Set the scope and you'll know when you're done. The one time when we didn't was when we didn't have the right people to the table. We had data entry clerks and people responsible for entering data into the system. And whenever we'd ask the question, what do you use this information for? What does it mean? They wouldn't have an answer. They didn't know, because they weren't the real users. So we canned that project. The inclusive, I said, break the expectation that it will be implemented by weekly meetings, focusing in on entities, growing the documentation, the facilities should be an outsider, the scribe should be an insider, so the organization can take ownership. Okay, so that's the short meeting. Let me just defer to the end, okay? We're running out of time. Besides that, you can do some interviewing and the two kinds of facilitated group sessions. So I'm sort of backing up and saying what are the different ways in which you can elicit requirements. I'm gonna change that word gathering. And with interviews, the big advantage is that everyone gets heard. You can do them one at a time or very small groups of users. The pluses mean that those are the advantages. The accelerated meeting is one where, like in a JAD session, you come together and you hold up in a retreat center or something for one or two or three or four or five days and you're gonna bash through this. Let me speak more. The accelerated sessions are good for brainstorming, good for taking straw votes, setting priorities, raising issues. But I don't think they're good for coming to a consensus because that takes time or for resolving issues and the extended is what we have been talking about. Here's a little chart that kind of shows where the sweet spots are for these. The interviews are at the bottom. The visionaries you might wanna spend some extra time with, okay? So you see how those fit together. I'm not gonna go through the details here. There's lots of literature out there about how to conduct an interview, you know, pre-plan the question or have it free-formed, free-flowing, but you wanna make sure that you understand the situation first, that you select the people that you're gonna interview wisely, perhaps indicate that you're gonna be doing this and then advise them before you go. Think through what you need. Ask the classic questions, flag the nouns and the verbs and what you're talking about because the nouns will become entities and the verbs or objects and the verbs will become relationships. Okay, so we had an interesting opportunity. I was supervising a doctoral student at this time and there were two projects going on. They had him come in to do one with the extended project meetings and they had already started or planned to have a JAD session. So it was kind of a unique opportunity. It was an opportunistic thing and he wrote his dissertation on comparing, we'd surveyed and so on, comparing the results of these two approaches. There's some people that think that you should do this design in an accelerated meeting idea. They had an outside contractor that did this. Both were led by relatively novice facilitators in experience in the process, but very familiar with the domain. Notice that's just the opposite of what I'm suggesting. And then we gathered information and surveyed things afterwards. There's a citation there for some of the work. Okay, two, the first column is the data planning which was the accelerator. It was division wide. They did rent for five consecutive days. There were about 76 participants, two facilitators and they acted as described as well, which I don't recommend. The extended one was a more detailed design of the forestry inventory database. We had, they had bi-weekly, half-day meetings as I suggested over a period of about six months. There were 11 participants and one facilitator. Who else, and that was the PhD student who also served as described. Here was the plan for the accelerated meeting. They were gonna have an introduction kickoff and training session on day one. Day two, where they were gonna define all the entities. Day three, they were gonna define all the attributes. Day four, define all of the relationships. And on day five, they were gonna partition and prioritize that to see what they implement first. Does anything sound strange to you about that? In one day, we're gonna gather a group of users together and we're gonna identify all of the relevant entities in their world. It was the 76 participants. I indicated the scope on the previous slide. Yeah, okay, here's what actually happened. They spent their first day defining entities went for two and a half days and the Astra says difficult and contentious. So the facilitators decided arbitrarily to move on. Entity, they said we gotta define our attributes, right? Entity definitions were incomplete, missing, poorly stated, no consensus reach which hindered the definition of the attributes and the relationships, of course. A global data model was never produced nor was any detailed design projects defined and prioritized. The contractor promised to develop these later in a final report. But you see, they were domain experts. This was a forestry consulting firm. So they felt that they could do this. Here's an example of the data modeler thinking they can do a better job of modeling users' world than users. How presumptuous. Don't do that. The data planning workshop was unsatisfactory. Final report admitted of where used matrix. Global data model was useless. The contractor was fired and there was no user validation of the results. A comparison survey found that the contractor confounded the fact that the contractor has apparent lack of experience, participation, organization in the management of the workshop. The novice facilitators were in both approaches to look at this. The advantage in the extended biweekly one was the facilitator was able to learn and modify what they did even though they were novice. He would come back to me and say, we had this situation, what do you suggest I do? And so I would give him some advice and counsel. If you're kind of do this all in five days, it's completely unforgiving for mistakes. You can't recover. And you certainly aren't gonna meet your goal. So just to summarize again with some additional lessons learned, an accelerated approach may be good for eliciting information. I did use the word eliciting though, great. Requirements, setting priorities, but it's not good for design. Difficult to read consensus, particularly when there's a broad scope. An experienced, prepared facilitator is critical. The accelerator approach is unforgiving. Clearly define and communicate the organizational goals. User domain experts, you'll get the best results and use them as needed, but you gotta get the experts in user domain. Top management support, obviously facilitator, expert in the production of the domain and dedicated scribe from within the organization. That's really important. If you try to do the scribe and you are the ones that write the report or document the database, it's just gonna be shelfware in all likelihood. And if it's not and if you implement on the basis of that, the users are still gonna forget it. They didn't participate. It's important. Select the first design project that has manageable scope. It's maybe a new way of doing things in your organization. So you wanna pick a willing user group. You wanna pick a project that is relatively straightforward and simple, but has a relatively high payoff and your PR will do good for you. Consider a blend of the two approaches, obviously. You can do some interviewing, you can do some accelerated for part of it, maybe kick it off with an accelerated meeting and have everybody say what it is, the kinds of problems we face and then go into the extended series of meetings. Okay, if you wanna look at the slide, you can see the rest. But there are some people, I'll just say one thing. Oh, did I include, did I skip that? Oh, I don't have it there. It must have been a different. I had a picture of the thing, which is the ultimate in a data model, right? It's the universal relation, we call it. And that was the theoretical name for it. Okay, where did we do? One minute, I mean, one minute's short. We've got time for one minute questions. Ah, good point. This is all about process modeling and what they do. That's absolutely true, but the data is rooted in the business processes. And so what you do is you listen to what they say they do and you ask in questions about what is it that they do to or with? Okay, what is it they need to know about something that they're gonna do something to or with? You're listening for the nouns and the verbs in what they say. The nouns will become the entities or at least be candidates for those entities. And the verbs will be the relationships and the adverbs and the adjectives are gonna be the constraints. Okay, well they can have that, but these meetings are for data. Okay? Our goal here is not to develop software. It's not develop application processes. No, you won't be asking the same users because you're gonna have different stakeholders. They'll start that way, okay? But then they're gonna ask questions about user interface. We said nothing about user interface. The whole documentation is metadata. It's a narrative form, okay? Our deliverable was that document that I outlined in the slides. It started out by saying what is the goal? What is the scope? What are some of the use cases or the business processes that involve this data? And then the global data model and then we would describe that entity by entity and attribute by attribute within those. And we grew the documentation. That would be the goal was once you've got that documentation translating it into a DDL or a relational model or whatever would be pretty straightforward. Yes, yeah. You've now got the user's information and a pretty comprehensive picture. Like I say, this served them. In fact, it's serving them today after all these years. This model is serving them today because their world hasn't changed very much. I mean, roads are roads and you build them on top of the land. So if you take the time to accurately describe the user's world, don't be hung up with associated entities or flat files, relational databases, whatever. I would argue don't even be hung up with tables at all. Just model in ORF because now you're modeling the nouns and the verbs. And ultimately that's what the description is based upon. You wonder about attributes. Let me just say this. An object has an attribute or a descriptor by virtue of playing a role in a relationship with another object. That's the only way that you get an attribute. You can't have an attribute unless you're talking about two objects and a relationship between them. So let's talk about the objects and the relationship. And if it happens to be a functional dependency, then you will know from that what table to put it in and what the identifier is gonna be. But you don't need to, all you need to know is that there is this relationship between them. If it happens to be many to many, guess what? It's gonna become its own table. But you're not making those decisions up front. Is that I set up what? A page per attribute? Yeah. We were thinking when we went through this process in this way. But yes, each attribute would be an object. What's interesting is that you're gonna have the same attribute appear several times, okay? Because something like, let's say, phone number is gonna appear multiple places. Or address location, or something like that. And that's why you really should be thinking about documenting that object by itself. And that's what you do in a oral. And every place that it gets used, it could be an attribute. Other questions? Okay, thank you very much. Appreciate that. Thank you.