Firstly, the Service-Oriented Modeling and Architecture (or SOMA) offering is an extension of the IGS GSMethod and is available to IBM customers through service engagements (see the IGS SOA services here). This means that the techniques are described in a certain manner, and based on existing techniques included in the existing GSMethod base. From "Analysis and Design Techniques for Service-Oriented Development and Integration" SOMA is described as:
SOMA is an IBM offering that defines the three service modeling steps identification, specification, and realization. These steps consist of several sub-steps prescribing several artifacts to be delivered and recommending appropriate techniques ...
SOMA identification can start both from business models via domain decomposition, which includes functional area analysis and process decomposition, and from existing systems. An additional goal-service modeling technique ties business goals, for example expressed as Key Performance Indicators (KPIs) to the identified service abstractions, facilitating runtime monitoring of business goals (a key business performance and service management issue).
It is the combination of techniques specific to SOMA, the GSMethod base and the IGS professionals that provide the value to our customers - a value that can be enhanced by using Component Business Modeling (CBM) to identify areas where a migration to SOA will provide most benefit, and then traditional development practices for service implementation.
Conversely the RUP for SOA is a commercial product, the RUP itself as a framework and base has been adopted by many organizations over the years. The RUP for SOA plug-in was only a set of additional artifact and activity descriptions that extend the existing RUP content. This approach has meant that the RUP for SOA is entirely consistent with existing techniques and is able to leverage them as it does not attempt to be a stand-alone method. However, this does not imply that there is no relationship between SOMA and RUP for SOA as you might think (and the existence of two separate methods from IBM has confused many people) as SOMA describes the use of many techniques that really are generic and described in both GSMethod and RUP, such as Use Case Analysis.
In fact, as there is almost no dependency from SOMA to proprietary GSMethod techniques, it would be possible to describe the techniques and artifacts in SOMA as extensions to the combination of RUP with the SOA extension. The initial work is underway, both teams have made some changes in the methods and content to align terms and concepts where possible; also the content describing SOMA is being captured in Rational Method Composer (RMC) so the delivery of the two methods uses common tooling. The next, and most significant step is another round of consolidation where we can finally describe techniques in SOMA in terms only of the RUP and RUP for SOA techniques, and while SOMA will remain an IGS engagement method, the alignment between our services method and commercial offering will be complete. I hope to be able to report more news on this work over the next few months - I exect there will be many meetings and phone calls in the meantime.
Finally, as an aside Joe Marasco (previously of Rational) forwarded the following link which takes a wonderful and irrevelant look at the subject of software development processes - enjoy www.waterfall2006.com.