This chapter is from the book
This chapter is from the book
This chapter is from the book
CASE STUDY
Several years ago, two of the authors were involved with a very large software development program—over 300 people working on a portfolio of related software projects. This program had been in progress for several years by the time we became involved; however, the team hadn't yet delivered anything of substance, and everyone was getting worried. We were asked to provide mentoring to the team responsible for coordinating the overall technical effort. We were involved with three aspects: overall software process improvement (SPI) to help them to become effective with object technology, enterprise business modeling, and enterprise architecture (Chapter 9). All three of these efforts needed to be in sync with each other and needed to evolve in parallel; otherwise it was feared that the development effort would become even more chaotic.
The enterprise process modeling effort focused on the development of a high-level use case model, which depicted 10 main actors and 25 use cases. The actors were each described with a short paragraph and the use cases with a one- or two-page formal use case specification. The model needed to be reviewed by an outside agency, and the team felt we needed to ensure that the use cases were well written (point-form descriptions wouldn't be sufficient in this case). The team had originally developed a detailed IDEF0 process model, which had been previously reviewed and accepted, but we discovered that the project teams weren't using it in practice, even though it was available to them (it was even posted on the wall). This was more a reflection of the prejudices of the developers; their perception was that if something wasn't object-oriented, it wasn't any good.
The organization model focused on the three different types of sites on which the systems were to be deployed—small sites with fewer than 10 users, large sites with more than 10 users, and disconnected users who may not have network access for days or even weeks at a time. The reporting structure was well known, relatively rigid, and well documented already.
The high-level domain model was captured as a UML component diagram, which reflected our desire to take a domain engineering approach to the enterprise architecture (Chapter 9). Each domain component was then described with a UML class diagram showing the main business entities within the component and the relationships between them. In all, about 150 entity types captured were within the model. Similar to the process model, the team had originally developed a detailed enterprise data model, a model that was openly derided by the object developers (although it was actually pretty good). The bottom line is that it doesn't matter how good your models are if their audience isn't interested in them.
The enterprise business models were initially developed on a part-time basis, two to three hours a day over a period of six weeks by a team of 10 people (not everyone was involved at all points, however). The team included some of the original enterprise data and process modelers, several business stakeholders, a couple of technical project leads, and a mentor skilled in the new modeling techniques. The models were then updated over time as we discovered that we had either missed or misunderstood a few concepts. The enterprise architecture team, which included several of the enterprise business modelers, used our models to formulate the enterprise architecture. The project management office (PMO)—which was responsible for portfolio management (Chapter 8)—used the models to help them define and prioritize the projects within the program. Individual development teams used the models as the starting point for their requirements and business modeling efforts, providing feedback, which we used to update our models.
To communicate and support our models, we were actively involved with both the enterprise architecture and project development teams. The models were made available within a shared documentation repository, and the diagrams were printed and tacked to the walls of well-traveled hallways. When we did this, we announced via e-mail to everyone on the project that the models were available and whom to contact if they needed help or wanted to provide any additional input. Our open approach was well received by our coworkers and helped us help them do their jobs.