• Software Architect

By Ali Arsanjani, Simon Johnston, John Smith, IBM © Copyright 2005, 2006 by IBM Corporation. All Rights Reserved.

Topics

• Introduction
• Method Integration Overview
• Principles
• Scope
• Key Decisions
• Acknowledgements

Introduction

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.

Method Integration Overview

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.

Principles

The plugin is based around the following guiding ideas:

1. Allow for future growth; minimize or avoid constraints on future additions of activities, workproducts, roles, etc.
2. 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
3. Converge on customer facing and internal IBM messaging
4. Method must remain tool agnostic, but provide guidelines of integration for toolmentors, favoring the IBM portfolio
5. Enable the capabilities of the activities of the method rather than restrict them based on GS Method or RUP or other legacy methods.

Scope

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 a process.

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 introducing.
• 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 iterations.
• 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.

Key Decisions

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.

Acknowledgements

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.