RUP/SE

IBM Rational adopts a process-led approach to software development, with the Rational Unified Process (RUP) sitting at the very centre of its intellectual property. IBM's marketing materials for the Atlantic release reassert the RUP principles.

RUP takes a project-focused view of software development. However, the On-Demand Business calls for a much broader range of software-related activities - not just software development - and not all of these fit into a traditional template. Even before the Rational acquisition, IBM already had lots of different processes for various things – and of course the acquisition of Price Waterhouse Coopers (PWC) brought in some more. Although there is a mechanism for plugging additional process into the basic RUP framework, this doesn't escape from the project focus of RUP.

RUP/SE is a RUP plug-in for the systems engineering domain. Systems are defined broadly, to include human activity as well as software and hardware activity – thus the whole enterprise or any part of it can be regarded as a system. RUP/SE gets away from a project focus, and gives us a solution focus instead. It supports the construction of a business solution as a system of systems, with the RUP process patterns instantiated recursively for superordinate and subordinate systems, yielding a form of twin-track development. This can be nested to as many levels as you like, yielding n-track development, with the tracks operating at completely different timescales.

Systems engineering is traditionally seen as a specialist domain within the software world, mainly aimed at building very large and complex systems in such areas as aerospace and the military. This typically calls for higher levels of complexity and rigour in the solution development process, and possibly more sophisticated tools and techniques than regular software engineering.

IBM's material on RUP/SE emphasizes its suitability for some of the traditional systems engineering problems, without mentioning SOA. But for SOA, RUP/SE appears to have a lot to offer, and here are some of the reasons why:

• SOA involves the construction of systems of systems
• SOA is not amenable to the traditional project – whether waterfall or spiral
• SOA typically requires twin-track or n-track development

My review of Rational Atlantic tools for SOA was published by the CBDI Forum in January 2005. (members link non-members link) For ongoing material on SOA, please subscribe to my SOAPbox weblog.