The Design

A good- sized group of people involved in the development effort for EAB Healthcare has come together off-site for a day to look at the job they have just accomplished. The group is composed of some development managers, analysts, developers, and database designers. The Chief Technology Officer and the Vice President of Information Technology have also joined the meeting to understand how this unique project has been done. For the first time at EAB, an entire development team has worked together to create an application and database, including gathering the requirements all as one group, rather than in individual teams . Management wants to understand the benefits and issues and learn how they can make this process a continued success moving forward.

The group contributing to the postmortem is limited to three people from each involved development team. If too many people are involved, it is difficult to get much accomplished and to give everyone enough time to present their views. The people participating in the postmortem were selected by the team leader of each group involved; the team leaders attend the postmortem as well. Each team includes both senior- and junior-level people, giving insights from all aspects of the project.

For a few days prior to this meeting, the representatives spent time gathering information from their teams as input into the meeting and they are now ready to present their findings. The facilitator for the meeting is the Director of Information Research and Development. Although she was involved somewhat in the process, she is still outside the day-to-day activities enough to be a good facilitator. She can also understand the conversations to be sure that they are resolved to their fullest. Part of the facilitator's job is to put time limits on conversations and to make sure that they stay on the subject. There is a large clock on the wall, and the facilitator directs that no one issue can be discussed for more than five minutes. This could potentially limit the input, but it will help control the group from drilling too deep into a subject and thus getting off track.

The meeting starts off with a demonstration of the MDS application and how it interfaces with the database that was created. This gives everyone the satisfaction of seeing the first phase of the project complete and a great positive attitude for a starting point. It is important that the team members not have negative attitudes coming into the meeting but also not to be so positive that they are blind to real issues.

The Positives

The overall attitude of the development team at EAB is quite positive. This was the first time that all of the teams involved in the development of a project were able to work together and build the entire system from a single set of artifacts. The database team is really impressed with the requirements that they were able to share across the different teams involved. The team members have never had such a clear set of requirements nor such a clear definition of artifacts to build the database. In most past projects, the database team was used to getting the requirements and systems definitions on its own, and they often contradicted what the other teams had created. Models of the requirements in use cases and the activities that defined those use cases were unheard of previously. The team members had built some business and business process models in the past, but never anything like this. The ability to have many tables defined prior to even starting the database design models amazed the database team. This is not to say that they didn't capture requirements and didn't do their background work, but they think it's great to have one single set of artifacts.

The database designers are happy they used the UML for the database de sign models themselves . They found it very easy to learn the notation and understand the relationship types. The database designers also found the most useful parts of using the UML were the ability to visualize so many artifacts, including the constraints, triggers, and stored procedures. The biggest benefit they see in using the UML is the ability to model the tablespaces and quickly understand what tablespaces exist and how tables are partitioned across those tablespaces. During the design process, it was great to visually see what already existed and where new items needed to be created.

The analysts see some benefits to their new method of modeling as well. They have been using the UML for two years and they already understood its benefits at the start of the EAB project. However, they had never before been able to communicate their designs to so many people in one language. During the postmortem, the analysts present their view: Creating the conceptual and logical designs together with the rest of the organization was a great help. This was the first time we have developed an application with an understanding of the requirements throughout the process of design. The analyst group was able to work with everybody to define requirements together, causing a much better understanding of the system and enabling the building of a comprehensive design from requirements to application to the final database.

The application developers are also impressed with the use of the UML for everyone involved. Like the analysts, the developers had used the UML before this project, but the developers had only about six months of experience and had never really been too involved with the early requirements work. The developers are now quite happy that they were involved so early for the EAB job. During the process they really felt that they had decision power in creating the application and defining the requirements, instead of being handed the prototypes with the onus to build this. The other major benefit the developers see is the ability to communicate with the database designers. In the past, developers had to beg to see the database designs and then, well, good luck trying to figure out how the tables and classes map. Having the entire design in one language broke down the barriers to communication. Mapping to basically one metamodel gave them the ability to understand the object relational mapping and build a solid system.

The Negatives

When you have positives, of course there are going to be negatives as well, especially with such a drastic change in philosophies. The development teams had never really worked together in one language to build a system. They had obviously worked on projects that interfaced with each other, since the application and database must communicate, but the teams' communications were never good. Issues arise whenever you throw something new into the mix. Having a new language and methodology and the need for the teams to work so closely together opened the project up with a lot of concerns. Change, al though often for the better, is not usually conceived as such initially, and these teams were no different.

The group that took the change the hardest was the database designers. Although they have been modeling much longer than the others, the notation and language was completely foreign to them. They feared that having the developers and analysts involved in the database design would just cause delays with nobody getting anything accomplished. Most of these issues were overcome quickly, but still they created a negative expectation in the beginning. Also, few tools were available to support the entire process, and a decent amount of manual work had to be done. Although the team members believe this will improve with time, at the postmortem they present this as a negative. All the teams report that, although they began to work together, each still has a feeling of we know our piece of the system best and don't question us. This is something that, over time, will change as each group develops more subject matter experts in analysis and design across the project life cycle.

The analysts bring up some issues about the database designers not listening to them early in the project. They feel that the database designers were thinking of everything in a data perspective and didn't think outside of their box. This is something that the team members will have to work to overcome. Since this is so new to them, it is quite difficult. Even though one has the company's best interest in mind, one still may be thinking of oneself, and it is difficult to get away from that.

The application developers are of the same opinion as everyone else. They see the many benefits of using the UML, but the process still isn't perfect and there is plenty of room for improvement. The developers want to be more application centric. It wasn't quite as easy as expected to map from the logical design to the application design while still keeping the object relational mapping intact. During the process they saw that some of the logical design models began to become just logical data models, and that was not what they expected out of a logical design. They now see a need for the database designers to step back a little from the database world and just think of the logical design from a nonpartial point of view.

The application developers also, as everyone in the group does, want more. They want to see more of the application logic captured in the model designs and to have more of that code generated automatically from a model by some tool set. Most tools only generate the class code, leaving the business logic to the developers themselves. The developers see an advantage of keeping the logic directly in the model and modeling the business logic itself, helping to keep the model and code synchronized. This would keep the models complete with all artifacts needed for development.