| |
There are many tools and notations that address data modeling, but generally they are very focused on the implementation of the database. These tools and notations concentrate on logical and physical database modeling, usually ignoring other aspects of the business and its requirements. If you want to model and understand the business processes, requirements, and rules, you need additional tools and notations. If you want to understand the applications and how they relate to the database, once again you must move to other resources. This makes communication, reuse, and interoperability quite difficult, if not impossible.
There have been many methodologies, tools, and notations that championed different ways to best model, design, and build software applications from analysis through to database implementation. Some of these methodologies were very strict in the process and very tool intensive. If you wanted to customize these to fit how your organization did business, often you were out of luck. You had to do it the way prescribed by the tool or methodology. Since software development is an iterative process performed by different teams with different levels of experience and often in varying phases of the project's life cycle, it became quite difficult to work in such an environment. Working in such a linear path made it very difficult to accomplish work that needed to be done immediately without going through the other steps first. It was also quite difficult to go back and fill in some of the blanks once a step was skipped. The tools that support such a life cycle are often called upper CASE tools or full life-cycle CASE tools. Over time, people decided that a very strict methodology wasn't going to work in an environment that needed flexibility. They moved away from the upper CASE tools into what we call lower CASE tools. The organizations that moved to these types of tools and methodologies began to adopt best-of-breed solutions.
The majority of companies that moved to best-of-breed solutions have run into a new problem. How do the different teams involved in the development effort communicate requirements and changes? Using the full life-cycle tools and methodologies, although quite cumbersome, gave the business analyst, application developer, and database designer the ability to work together in the same environment with the same artifacts and information. Moving to a best-of-breed solution gives the different developers the ability to choose what is best for their subject matter but leaves the other teams behind. Often the business analyst is working with a documentation tool while the software developer is working with code or some UML models and the database designer is working with his or her own database modeling tools. The teams, which are working toward a common goal to solve a specific business problem, have now branched off into their own worlds and the door of communication has been slammed shut.
The relative inflexibility of the full life-cycle tools may have made doing an entire job difficult, but they at least brought the different teams together to solve the business problem that was placed before them. We have been involved with many companies that bring the business analysts, application developers, and database designers into a meeting and discover it's the first time they have met each other. The first question we ask in such a situation is, 揑f you don't even know each other and you are all working together to solve the same business problem, how do you communicate requirements, especially when they change??The answers are usually the same. The company has some really large requirements document that gets updated occasionally and an e-mail goes out to notify everyone. For most people, this is a pretty difficult and ineffective way to communicate changes. We have never worked on a project that had no requirements changes from inception to the end of the project. (If there were a company with such projects, everyone would want to work there.) How can teams, sometimes with hundreds of people involved, communicate the requirements, especially if the requirements change often?
Using the full life-cycle tools, since everyone was working in the same environment, made it easy to communicate the requirements and their changes through some sort of repository or data dictionary that was common across the tool and methodology. But going to a best-of-breed solution has put an end to the common information. Often teams meet to define requirements for building enterprise architectures without taking into account the other teams that should be involved. Because the teams are using different tools and processes, they often create their own plans and architecture, which the teams then pass on to the other teams involved, many times causing wasted effort. If the analysts are working with the developers, for example, to build an enterprise architecture without bringing some of the database design team into the fold, there is a good chance that the architecture being designed will miss some important artifacts needed by the database team. We are not recommending that everyone from every team be involved in all meetings, but each team should be represented. This will help to avoid the problems of six different definitions for customer or architectures that have to be thrown away because the database that has been implemented can't support it.
Having full life-cycle tools hasn't proved to be a good answer for bringing teams together. Also, nobody likes a process that is so strict that they can't customize it to do what they want, when they want, and with the parts they want. The best-of-breed option has provided a good solution for individuals, but it ignores the fact that even though the reporting structures may be different and each person may be working on different parts of applications, everyone still needs to work together as a team and share information readily.
The UML has the best of both worlds. There are many tools like Rational Rose, which will support the life cycle using the UML, yet they are flexible enough to do what you want when you need it. Using the UML as a language for the entire life cycle of the development effort allows all of the teams involved to work together in one way but to do their own part as needed. Since the UML is 損rocess agnostic,?its use can be altered as needed to fit into your company's structure and processes.
| |