In Defense of UML, RUP,and Application Design (Part-1)

by Frank Teti “Heavy” or not, a good methodology can be the key to success for a project. But using it properly requires practice, understanding, and communication.

Most technologists who build enterprise-wide business systems would agree that one of the hardest, yet most important, parts of the job is the task of gaining an understanding of business requirements. Translating requirements into design artifacts useful for implementing systems is an art as well as a science, and implementing business systems is as much about communication as it is about technology. Using Unified Modeling Language (UML) in conjunction with Rational Unified Process (RUP) provides more than enough guidance. However, like any language or methodology, it requires commitment and practice. Methodology as Foundation The seasoned architect looks at a project from a holistic perspective and tends to minimize the technical challenges while maximizing the other issues: unrealistic deadlines, weak project management, poorly written requirements, and so on. After all, in most business-systems projects, the technical architecture is usually well-known and documented. However, the lack of a realistic project plan or methodology can really doom a project. Take, for example, a recent project in which I was involved as the architect. Since the project was making the transition from the requirements phase to design, I was initially involved with resolving requirements and assisting management in its effort to estimate project timelines and associated resource loading. At a meeting with company management, we discussed the complexity of the project and our expectations for when it might be completed. Yes, the project was complex, but the only artifact we could really point to was the functional design document. We really had no technical plan that would demonstrate complexity, so we were, essentially, in a defenseless position. After the meeting, I marshaled the senior technical people in an attempt to create a detailed plan using a bottom-up approach. Although they really didn’t feel that this was part of their job, good architects know that building a software system is not just about using design patterns and writing code. A useful, detailed plan and methodology organizes tasks as well as task responsibilities in a logical sequence. Moreover, a detailed plan can provide sizing information that will help answer the paramount concern of management: How long is it going to take? The project plan we developed was for an enterprise-grade J2EE project for which we would loosely follow the four phases of RUP: inception, elaboration, construction, and transition.