When Fusaichi Pegasus won the 2000 Kentucky Derby, it came as no surprise. He had a good pedigree and was known to be among the best in his generation - a proven performer. On a different tack (and track), in the much less exciting world of enterprise modeling tools, pedigree and sustained performance are still the essential characteristics of a winner. And you would do well to place your bet on the latest thoroughbred from the stables of Sybase: PowerDesigner 8.0.

GOOD BREEDING

Like Fusaichi Pegasus, Sybase PowerDesigner 8.0 has an impressive lineage, one that you can trace back to the S-Designor product from Powersoft Corp., which acquired the product from SDP Technologies, a French company. With Sybase's PowerSoft acquisition in 1995, the S-Designor product - renamed PowerDesigner - joined the Sybase camp along with PowerBuilder, the flagship product of the erstwhile PowerSoft.

PowerDesigner has strong roots in the areas of logical and physical data modeling, and a keen rivalry with ERwin/ERX, now from Computer Associates. In fact, PowerDesigner and ERwin were both winners of the 1995 Readers' Choice Award at DBMS magazine, an earlier avatar of Intelligent Enterprise. While ERwin stayed put on the well-defined tracks of data modeling, PowerDesigner expanded coverage into the rocky terrain where relational modeling meets object modeling, and now stands in firm competition with products such as Rational Rose from Rational Corp. and System Architect from Popkin Software, in addition to ERwin.

BROAD SUPPORT

PowerDesigner supports conceptual data modeling, physical data modeling, and object-oriented (OO) modeling with the Unified Modeling Language (UML); the UML support extends to use cases, sequence diagrams and class diagrams. PowerDesigner also supports forward and reverse engineering for SQL scripts, ERwin files, ODBC data sources, XML, and object language sources, including Java, C++, and Visual Basic.

PowerDesigner has several additional capabilities, including a rudimentary but nontrivial ability to generate test data based on the model objects, a repository for managing and sharing design document versions, a business rules feature that lets you attach business rules to objects, and a powerful facility to compare and merge models, as well as compare and synchronize objects that have differing definitions.

THE WINNERS

So, what does all this mean to you? As a software architect or designer, these features let you carry out many activities in what I call the "software design life cycle" on a seamless platform, such that objects created in different settings (or "models," more formally) are aware of each other, work together, and can be managed together.

As a software development manager, you can now trace the path from the use cases and sequence diagrams that the business users help define (and can understand at a glance) to the software code that developers are working on and the tables in the database that your DBA manages.

As a CIO or CTO, you could perhaps save some costs on purchasing a separate test data generation tool and software version management tool, at least initially. More important, you will likely see shorter design and development time scales and better quality and manageability in the software development life cycle - a direct result of having empowered your software architects and designers.

INHERENT RISKS

While the benefits are many and real, there are also some real reasons for caution. Multifunctional tools, such as PowerDesigner and the Rational suite, offer functionality to many different types of users, including business users, business analysts, application and data architects, database administrators, developers and testers - practically the whole gamut of the software development team. Therefore, you potentially have several different people applying simultaneous changes to an interrelated set of documents, an inherently risky situation.

Second, such tools typically allow various process paths within the software design life cycle. Say for example you choose a process that starts with an OOM tool (the use case diagram), then goes into other tools, and ends with another OO modeling tool (the class diagram). Your architects and your team may prefer to go about it differently from you - and even differently from each other, which can affect the coherence of the overall software architecture. In other words, this flexibility will need to be tempered with process discipline.

Finally, whenever you generate code or code templates using automated tools, the developers are almost certain to manually change the generated code, thus creating a disconnect between the parent constructs in the design tool and the code these constructs generated. Notwithstanding the PowerDesigner compare-merge feature, in my experience, this disconnect can't easily be recovered, and sometimes is even acceptable - you just have to work around it. However, if you do not want such a disconnect, then you must have a very rigid process in place to prevent it.