By Ali Arsanjani, Simon Johnston, John Smith, IBM © Copyright 2005, 2006 by IBM Corporation. All Rights
This paper describes the third update to the Rational Unified Process (RUP) focused upon Service-Oriented Architecture
(SOA). This update represents a major milestone in the RUP guidance around SOA as it provides a unified method
combining previous RUP for SOA content with content from the IBM Global Business Services (GBS) Service-Oriented Modeling and Architecture (SOMA) method. The SOMA method has been successfully used
by IBM in a number of client engagements, and while it was initially developed leveraging the existing IBM Global
Services Method (GS Method) it was felt that in the area of SOA both IBM and our customers would benefit more from a
unified method approach than having two separate methods. When looking at the two methods it is clear that the authors
had very similar aims in mind and structured the methods in similar ways - in fact the two teams did meet in 2004 and
made some changes to both methods to align terminology. While this alignment is not necessarily surprising as both
methods are focused on the pragmatic activities of developing a service-oriented solution it was noted that a generic
framework could be extracted that would be able to describe both methods at a high level.
For customers familiar with Classic RUP you may wish to review Concept: Developing Service-Oriented Solutions.
For IBM staff familiar with SOMA you may wish to review Roadmap: Transitioning from IBM SOMA.
The following diagram illustrates the framework mentioned above. It represents a method neutral set of activities
required of any process for the development of service-oriented solutions. Now, this diagram is significantly
simplified from the content of either method but clearly represents the key activities of both methods -- Service
Identification, Service Specification and Service Realization. In the area of work products, it was clear that
there was a lot of conceptual alignment. Similar work products were required with similar roles and stakeholders, but
in some cases were realized differently; for example, as either a UML model or a Word document. This was seen as a
relatively simple alignment to make. Again, in general the major influences correspond well to the activities although,
of course, the reality is that all requirements have some bearing on all activities.
Figure - The Unified SOA Method Framework
It is possible to expand a further level of the framework, for the activities identified here are supported by a number
of techniques and it is really in the area of the detailed techniques that the integration of the methods takes place.
This paper will not provide the detail on the technique integration, however, it is important to note that the
development of a single and coherent method led to some changes in both of the methods used as starting points to
ensure that the reader will see a consistency in concept, approach, task and work product definitions. One decision,
for example, that provides a level of consistency to the content is to use the existing RUP for SOA Work Product:
Service Model as the primary source from which a number of textual reports and tables can be generated to provide the
work products expected by SOMA practitioners. In general this change provides the value that the UML service model has
additional semantics and can be used to develop both service specification and realization models, however the service
model has to be extended to capture additional information required by existing SOMA work products; for example, the
Work Product: Service Specification has been extended with additional properties source and status that capture
information routinely used by SOMA practitioners.
The plugin is based around the following guiding ideas:
Allow for future growth; minimize or avoid constraints on future additions of activities, workproducts, roles,
Maintain ability to add proprietary extensions to current or future commercial methods: for example, industry
specific extensions or assets in SOMA; proprietary content can also be added to the framework for service leverage
Converge on customer facing and internal IBM messaging
Method must remain tool agnostic, but provide guidelines of integration for toolmentors, favoring the IBM portfolio
Enable the capabilities of the activities of the method rather than restrict them based on GS Method or RUP or
other legacy methods.
This update to the Rational Unified Process (RUP) has the scope of introducing guidance for the Software Architect and Designer in developing a Service Model, a model representing a portfolio of services that
can be used as the basis for implementation tasks already in the RUP. It is also our intent to describe the connection
between business modeling and the services model. Many Service-Oriented Architecture (SOA) projects use
business-process models in understanding their business, functional requirements, and the services required to support
The scope of this update was addressed briefly in the introduction, but here are the set of requirements and scoping
statements used to guide the project.
Leverage the existing RUP; in this case it means that where possible we should describe new tasks
and work products in relation to existing ones in the RUP and not unnecessarily add new concepts. Also, new
elements should be added such that they fit into the overall flow of the RUP.
Look forward to future tool capabilities; although the RUP is not tool dependent, it should be
understood that there is no point in developing content in areas where no tooling will ever exist and then, there
is no need to not write a topic because the tool is not in the market but we can expect it to be soon.
Integration of other IBM experience in SOA; it is clear that other groups within IBM have
experience that can be leveraged; harvested; and added to the concepts, guidelines, and practice we are
Scope changes to Analysis & Design; we have looked at the literature that describes the
application of SOA to business design and the implication of SOA on business models, operational organization, and
business integration. We have also looked at the differences SOA tends to make on implementation, deployment, and
operational management. This is too broad a scope for the first iteration so we have only focused on architecture
and design issues.
Deliver a foundation; this is the first iteration. We expect that additional guidance can be added
to the framework presented here and the connection made between this content and the rest of the RUP in subsequent
Look to changes that need to be made in the base, but defer to future release; we know that some
concepts we introduce would fit better with terminology or other minor changes to the base RUP. While it would be
desirable to change the RUP, that would have wider implications and would take far longer.
We intend that this content be a part of the base RUP in the next commercial release of the product. In the meantime,
we want to make the content available to customers so content described here will be packaged as a RUP plug-in and made
available for download.
In parallel, changes are being made to the Business Modeling (BM) discipline that would make the connection between BM
and SOA stronger; however a decision was made to wait for the BM changes before completing the SOA plug-in. The
integration of both sets of changes will be made for the commercial release.
A number of key ideas will be incorporated from the GBS Service-Oriented Modeling and Architecture
(SOMA). While it is not possible to incorporate all the ideas and guidance in SOMA, mainly where it falls outside
of the scope we set, it has been useful in guiding our work.
Certain new principles have been introduced, including concepts that have affected the way we have approached the rest
of the content, one of which is the concept of a service portfolio and an enterprise-wide view of the services provided
in the enterprise.
The authors would like to thank the following for their valuable contribution to this work. Alan Brown and Sky Matthews
for their support and review of the content. Thanks to Eoin Lane, Steve Graham, Ed Kahan and Grant Larsen for providing
not only comments on the work, but many examples that helped us and sometimes stumped us. We would also like to thank
our colleagues working on the SOMA effort, Ali Arsanjani, Luba Cherbakov, and Kerrie Holley. Additional material was
included in this revision from Maryann Hondo, Web Services Security Architect at IBM.
Finally we would like to thank Claus Torp Jensen and his team at Danske Bank for their open and frank dialog
on the bank's experience with applying SOA in the real world.