Comparing Rational Rose and Rational Software Achitect

It is tempting to come to the conclusion that IBM/Rational has abandoned the Rational Rose product and that one must upgrade to the Rational Software Architect product - especially to get UML2 support.   That is certainly the position put forward by the IBM/Rational sales teams (and their business partners).  Development teams new to these tools might have good reason favor Architect but organizations already using Rose should consider if the switch is worth the effort.
I 'd describe the situation with IBM/Rational and Rose slightly differently than to say "Rose is dead".  For example, the Rational Rose product is still for sale , still supported with training, and actively supported with patches, forums, etc.  I'd also assert that it remains a viable (though admittedly not "cutting-edge") product for UML2 work.

It is true that IBM/Rational froze the version number/name at "Rational Rose 2003" for many years.   However,  IBM/Rational has continued to update the Rose product  - they have just kept these as point-releases underneath the "2003" version number.  It is not much of a secret that the main motivation here was to name/version the products in such away as to encourage customers (especially new customers) into the XDE and now Architect products. However, I use version "2003.06", there is a version "2003.15" available, and updates are available as recently as June 2006 - Rose is far from "dead".  If you go by product names, the "new" Rose is actually called "Rational Rose Enterprise 7" but users of Rose 2003 will find the product very familiar.  The differences between "Rose 2003", "Rose 2003.06" to "Rose 7" are proof that you can't tell much just from the name. 
But what about UML2 support?  Rose supports UML2 better than you might think.  First, we have to remember that UML2 includes most of the UML1 constructs - so it is pretty easy to build models with UML1 tools that are still consistent with newer UML2.  Also, many of the notational forms formalized in UML2 were practices that people had been improvising on top of UML1 for years (e.g. regions in the sequence diagrams or iconic representations of stereotyped classes) - they may have become "official" with UML2 but Rose (and many other older UML tools) can support many of these constructs.  Finally, Rose (like most of the tools in this space) is very extensible.  So, there are mechanisms to add-on to the product many of the UML2 features/notations that your organization or project need.
Finally, the cost and disruption to an organization isn't trivial.  Many organizations have struggled to accumulate the in-house tools and expertise they have now with the tools they have now - re-tooling gives them new products in a box but may undue much of their ability to execute.  Many of the people I see using any of the UML tools are hanging to some basic skills by their fingertips - it is actually frightening to imagine how far down the system development capabilities of these teams would fall if they had to start over with a new tool.  For most budgets are also factor - they can barely afford the maintenance on the existing tools (and many don't) so buying new or upgrades isn't realistic.
Some organizations are also rightly suspicious of the "Rose is Dead" and "Switch to Architect" mantra given that IBM/Rational said the same thing about Rose and XDE a couple of years ago and has since withdrawn XDE...and the migration path for XDE customers is back to Rose!
There are some areas of UML2 that Rose just can't support though and this should be factored into the decision.  For example, actions on the activity diagram.  There isn't really a good way to do this in Rose.  In my mind that isn't a big one though because, for example, the UML community seems to be in some dissent about what "actions" mean - the latest versions of the UML User Guide and UML Distilled disagree on this point.  A more serious shortcoming in Rose UML2 support is that you can't do the greatly expanded component diagram from UML2 - the "ball and socket" notation and the new ports notation. The new component diagram is powerful stuff and there isn't really any way to do this in Rose.
Some of this also boils down to style of the development team(s).  Development organizations that separate their software engineering activities (analyze, code, test, etc.) into separate teams, activities, locations, etc. are going to find the cost/benefit/feature position of distinct tools (like Rose) attractive.   Teams that have taken integration of the engineering disciplines down to the individual contributor (modeling the solution, defining tests for an acceptable solution, coding the solution, etc.)  will be drawn more to a workbench (like Eclipse but also Visual Studio) augmented with multi-language IDE features, modeling (Rational Architect), software testing (ParaSoft JTest), etc.
In the end, it isn't that we should be automatically cynical about the Rose to Architect upgrade path but that this should be a deliberate decision rather than an automatic one... despite what the sales teams and their apostles say.
- Brian

No comments: