> Issue LIV: September 2011 > Mitigating Service-Orientation Risks with RUP
Fillipos Santas

Filippos Santas


Filippos is an IT Architect for Credit Suisse Private Banking in Switzerland and a Certified SOA Trainer, Analyst, Architect, Consultant, and Security Specialist. Additionally, he is certified by The Open Group on TOGAF 9 and by IBM on the Rational Unified Process V7.0. In the last 10 years, Filippos has been the lead for the analysis and architecture of a number of successful SOA projects and for transforming legacy architectures to service-oriented architectures, primarily in the financial sector. His achievements include the conceptual and physical design of the international insurance claims service network that connects insurance policies, customer companies and state authorities in 44 countries across the globe, combining legislation, business processes, business rules, business objects, knowledge bases and different platforms.

Filippos recent work with Credit Suisse has been as an SOA Architect, combining the profitable and established functionality of legacy systems with centralized business process services, decentralized business rule services, domain specific BOMs and entity services and end-to-end traceability to business requirements and processes.


rss  subscribe to this author


Mitigating Service-Orientation Risks with RUP

Published: Sept 13, 2011 • Service Technology Magazine Issue LIV PDF

Abstract - In this article, we examine the application of RUP phases, roles and practices in mitigation of risks related to SOA delivery projects and Service Inventory Analysis. We show the importance of the elaboration phase in SOA projects, and we clarify the specific technical issues and risks introduced by SOA projects.


SOA projects tends to be large and challenging, with complex management environment, technical risks, many interfaces, stakeholders, and suppliers. Although SOA benefits and ROI are long-term, most investment and impact is up-front. This results in a high risk of not delivering any benefit to the business. Success of service-orientation is based on:

  • intensive and balanced teamwork among multidisciplinary, well-educated teams;
  • long analysis and architecture before starting implementation of services;
  • reuse of agnostic software at domain and enterprise levels; and
  • several levels of abstraction on documentation of all interfaces and models.

In the article [REF-1], we established that the above strong requirements of service-orientation are supported by RUP. Since the above requirements are crucial for the success of any SOA initiative, the possibility of fulfilling them by applying RUP is a very good motivation towards adopting this for implementing SOA projects.

Several publications have demonstrated how to implement SOA with RUP or how to extend RUP with SOA activities. However, very little has been written on how to use RUP to mitigate the risks related to SOA implementations. The main reason for adopting RUP in SOA projects is because RUP provides a prescriptive way how to mitigate technical and project management risks. In this article, we will examine these risks and how they are mitigated.

Motivation: ‘Risk First’ brings Value in SOA

In order to get the project going, the teams would usually address the easiest or best-known aspects or use-cases first and create a coherent team and build confidence (low hanging fruit). This approach postpones all the (possibly unknown) risky elements towards the end of the project and results in issues close to the delivery date, adding costly, unplanned iterations to the project or consuming all resources without delivering any value. If this is the outcome of the first projects of a SOA initiative, then the initiative is dead.

Risk-driven teams, on the other hand, identify potential risks and tackle them early in the project lifecycle. Once they understand and mitigate of these risks, they deal with confidence with the functional aspects of the project. The project has higher probability to deliver the first services on time and within budget. This is a very positive start for a SOA initiative.

What kind of risks are we talking about? Standard risks in software development involve code integration, usage of unproven technologies, strict performance requirements, big number of interfaces and business objects, complex topologies, high volume, etc.

SOA is influenced very negatively by the above because:

  • Agnostic services participate in many processes and are subject to additional volume and performance requirements;
  • Service composability and intrinsic interoperability introduce additional requirements on the way services are composed;
  • Service composition may demand the introduction of a new technology; and so on.

If our project methodology allows for managing these risks early in the project, then SOA projects will have more chances to become streamlined in all organizations. In the following sections we will see how RUP and SOA Principles and Patterns can contribute in this.

Brief Overview of RUP

The main building blocks of RUP, or content elements, are the following:

  • Roles (who) - A Role defines a set of related skills, competencies and responsibilities. The roles are grouped in four role sets: analysts, developers, testers and managers.
  • Artifacts/Work Products (what) - A work product represents something resulting from a task, including all the documents and models (artifacts) produced while working through the process.
  • Activities/Tasks (how) - A task describes a unit of work assigned to a Role that provides a meaningful result.

The above are organized into phases, iterations, disciplines and workflow details (when). Within each iteration, the tasks are categorized into nine disciplines:

  • six engineering disciplines: business modeling, requirements, analysis and design, implementation, test, deployment; and
  • three supporting disciplines: configuration and change management, project management, environment.

Members of the nine principles may work in parallel. Each of RUP's nine disciplines has a role that focuses on breadth (leadership, impact and integrity, definition of standards), and a role that focuses on depth (details and precision) for that discipline [REF-9]. In [REF-1] we saw how the RUP disciplines are mapped to service-orientation stages. RUP is architecture-centric, use-case-driven and risk-driven in that values are produced by the engineering disciplines guided by use-cases, and technical risks are either mitigated early in the project, or the project stops.

Figure 1 – The RUP Hump Chart Mapped to Service-Orientation Stages.

The RUP Phases

On the contrary to other approaches, the RUP disciplines do not correspond to project phases. RUP introduces four sequential phases, each with its own objectives and concluded by a major milestone. The four phases are shown in Figure 1.

Each phase has a certain focus and provides answers to key questions. These are:

  1. Inception - Focus is the scope of the project. Key questions are: what services should we build? Should we build them?
  2. Elaboration - Focus is on mitigating the risks related to the project. Key questions are: Can we build the services? How should we build them?
  3. Construction - Focus is on implementing functionality. Key questions is: Are we building them?
  4. Transition - Focus is on delivering the software. Success is defined by answering the following question: Have we delivered it?

Each phase is divided into iterations. The length and the number of iterations in a phase depend on the time needed to provide an answer to the key questions of each phase.

How Risks are Mitigated in RUP Phases

Major risks are identified and handled during the inception and the elaboration phase. The last two phases, construction and deployment do not involve any major risk. In particular:

Inception - the most important technical risks are identified together with the use cases (business use cases and system use cases) that involve these risks:

  • For example, a business process that will be automated in a project involves communication with an external system and the project team has no experience on this kind of communication.
  • Or, several business processes need to be centralized and the team has to introduce a new process engine.

Once the risks and the use-cases (or sub-processes) are identified, they are assigned to iterations of the elaboration phase. In the same example, we may decide to create one iteration to examine how to retrieve all the data needed for the external communication, and one iteration to deal with the protocol aspects of this communication.

Elaboration - Each iteration in the elaboration phase, involves:

  • specification of the sub-processes assigned to this iteration;
  • implementation of the specifications in a prototype (proof of concept);
  • testing of the protoype implementation; and
  • updates to the architecture and design based on the outcomes of the prototyping and testing.

The implementation of a prototype or a proof of concept and its successful validation is important for the risk mitigation and part of the assessment of each iteration. Without a validated prototype there is no proof that the team knows how to handle the risk and there will be a danger in the later phases of the project (and other dependent projects) will be impacted negatively.

At this place, we want to emphasize the prominence of testing in RUP. The test discipline includes roles from all the role sets: managers, analysts, developers and testers. This contributes to the importance placed upon the testing stage within SOA delivery projects, where services need to be tested rigorously as if they were commercial products [REF-2]. However, RUP goes one step further and the demands of the prototypes are also tested to some extend (e.g. performance tests in the prototype related to the new connection to the external system).

Prototypes in SOA

A prototype is an experimental, preliminary version that serves as a model of the final product. In many projects, this is typically related to a UI prototype to check if people like the new interface or check the customer’s requirements.

Service-orientation is less interested in the shape of the UIs and more focused on service contracts and service logic implementation. However, it is unlikely that a well defined service contract will serve as a proof of concept of a risk mitigation. In most cases we will need to check:

  • if a legacy system is adequate as service logic of an agnostic service subject to certain requirements;
  • if a composition or agnostic service logic can be implemented by the team in a platform where they have limited experience or where several interfaces to various technologies are involved; and
  • if the platform can (or under what circumstances it can) support the required service granularity of an agnostic service and composition size of a composition service.

It is very important to clarify once again that this prototype meets a clearly identified subset of the requirements: e.g. prototype for checking performance requirements but not functional requirements. The majority of prototypes in SOA projects:

  • do not involve UIs or well elaborated web services;
  • do not involve functional requirements;
  • require minimal configuration of the environment; and
  • can be implemented with high level executable languages which are not necessarily used in the productive environment.

Notice that the implementation of a prototype implies that certain parts of a service will be implemented twice. The first implementation (the prototype) will serve as guideline for the second implementation. The former will be thrown away (or will be reused for other prototypes), the latter will be deployed on production.

Notice also that the definition of the Service Inventory Blueprint in the Service Inventory Analysis Stage (Figure 2) involves the implementation and testing of prototypes in order to mitigate all the risks derived during the definition of the inventory. Since the service inventory blueprint is defined in parallel to service delivery projects, the prototypes can be delivered sequentially or in parallel by the corresponding projects.

Figure 2 – The Four Primary Steps that Comprise the Service Inventory Analysis Stage

RUP provides several generic guidelines for identifying risks. On the other hand, service-orientation introduces a set of principles that have to be respected during analysis and design, and a set of patterns that can be considered in solving problems throughout projects to SOA.

Identification of risks during Inception:

The analysts and architects identify candidate services and possible implementations. The technologies taken into consideration should be well-tested, and if possible, the organization should have positive experience with them. Introduction of new technology to the organization may be beneficial for the project, but the risks related to this need to be justified by the benefit to the company and the customers. Furthermore, the implementation of the new services must be beneficial for the company and the customers.

Mitigation during each iteration of the Elaboration Phase:

  • The business and system analysts need to identify the objects, processes and rules related to the risk and the associated service(s); and
  • The service architects choose a solution from a list of candidates, and check the risks related to this solution. Developers will implement and test the prototype.

Each iteration in the elaboration phase of a new service needs to be long enough so that multiple project teams can be coordinated (analysts, architects, other developers, testers, and configuration managers), create and test prototypes and resolve the architectural issues. Notice that the scope of each iteration should be only the mitigation of one risk.

Examples of risks and their mitigation:

  1. New Service with Legacy System: A typical risk in the introduction of a new agnostic service based on a legacy system (e.g. Legacy Wrapper pattern, or composition involving a legacy wrapper) is that the current deployment of the legacy system cannot handle the loads required for the new service.

    Mitigation: Check with a prototype if the service with the legacy system:

    • can be scaled by applying the redundant implementation pattern to the legacy system;
    • can be called asynchronously;
    • can be scaled up by deploying the legacy system to another platform;
    • can be scaled by applying the state repository pattern to the new service;
    • can support compositions better if the service is of lower granularity; or
    • can provide specialized implementations for the capabilities that are subject to the high performance requirements (application of the Distributed Capability pattern, Figure 3)

    Another typical case involving legacy systems is the need to include two or more legacy systems in the logic of a single service. In this case, several prototypes may need to be constructed in order to check the previous issues including the application of the distributed capability pattern (Figure 3).

    Any of the above mitigation scenario depends not only on the capacities and configurations of the legacy system(s), but also on the requirements to the new service. For example:

    • If the different processes that call the new service do not share the same data, then it may be possible to consider redundant implementations of the service for the different processes (unless there are licence, cost, platform or other serious issues that prohibit this); and
    • If the processes do not need to consume the result of the service call immediately, then asynchronous communication can be considered (provided, again, that there are no other reasons that prohibit its approach); etc.
  2. New Service with New Technology: typical changes in technology involve a new operating system (e.g. Linux instead of Windows), new hardware (e.g. decentralized system over mainframe), new communication protocol (SOAP over RPC), new database, new process engine, new schema (redundancy over normalization) etc.

    The standard risk mitigation approach during the elaboration phase is a prototype implementation of an end-to-end service call in the new technology in several iterations. That is, check in one or several prototypes the integration to all the systems affected by the change: the DB, the security directory, the transport protocol, the state management, the process engine, etc.

    Common patterns that involve the introduction of new technology includes:

    1. Service Data Replication, where the conditions of service autonomy are checked with a prototype before the implementation;
    2. Service Broker and all its related patterns, where the facilities of the broker are checked with several prototypes before the team decides on the architecture;
    3. Rules Centralization where the team needs to check the facilities offered by the rules engine and the performance overhead involved in the service calls;
    4. Event Driven Messaging, where a prototype can check how availability concerns are mitigated; and
    5. Orchestration where several prototypes can provide a good idea about the modeling, coordination and administration of services and transactions, the deployment of the process engines, the performance overhead and provide valuable information on performance and management of compensations before any streamlined implementation takes place.

All these patterns demand extended elaboration phases with many prototypes and much testing in case the team has little experience with the technologies. From all of the above, it becomes clear that the architects, the business analysts and the developers need to be involved very early in the project when a new service is introduced.

Figure 3 – Distributed Capability

Service Re-Factoring

This scenario involves the reassignment or normalization of existing service capabilities to new services applying any of the Service Normalization, Logic Centralization, Service Decomposition (see Figures 3 and 4).

Identification of risks during Inception:

Existing compositions or service consumers may break. The analysts and architects need to identify the compositions and the consumers which are affected by the introduction of the new service. Old and new versions of the service capabilities may need to coexist. The capabilities of the new service become available to further service compositions: this may expose the service to unknown scenario.

Figure 4 – Logic Cenralization

Figure 5 – Service Decomposition

Figure 6 – Proxy Capability

Mitigation of risks during Elaboration:

The new service will participate in more service compositions. Therefore, it makes sense to invest in test automation tools, in case these are not already available. Check in a prototype what is needed from the new implementation in order to satisfy the requirements of the test automation tools.

Refactoring services may involve the temporary replication of code, until the old service consumer implementations are phased out. This may be improved by the application of the proxy capability pattern, in order to avoid code replication and take advantage immediately of the new implementation (Figure 5).

Is this however possible? If the service refactoring involves different platforms (capability A in service A is in platform A, capability A in new service B is now in platform B), it may be desirable to check if the old implementation of service A can invoke the new implementation in service B, and if the non-functional requirements on capability A are still satisfied. In environments with strict security requirements the prototype may reveal issues of authentication between platforms.

Mapping Service Delivery Project Stages to RUP Disciplines

MSOAM defines eleven project lifecycle stages, nine of which are service delivery stages. Only the service delivery stages are relevant for mapping to RUP (Table 1), because RUP does not support generic product lifecycle stages.

Service Delivery Project Stages
RUP Disciplines
Service Inventory Analysis
Service-Oriented Analysis
Service-Oriented Design
Service Logic Design
Business Modeling
Analysis and Design
Service Development
Service Testing
Service Deployment and Maintenance
Project Management
Service Discovery
Service Versioning and Retirement
Configuration and Change Management

Table 1 – Mapping of MSOAM Service Delivery Stages with RUP Disciplines.

The service delivery stages are further divided into sub-processes or activities. This subdivision allows us to make the mapping between the service inventory analysis, service-oriented analysis, and service-oriented design stages more granular with the corresponding RUP disciplines.


SOA Analysis and Architecture involves the mitigation of risks early in the project, in each iteration during the elaboration phase. Technical risk mitigation is an engineering work supported by prototypes; it is not a project management or pure documentation work. Early iterations examine only those scenarios and sub-processes that involve the major risks. Most SOA projects need the creation of prototypes for checking performance requirements, new platform configuration, security context propagation, communication between systems, etc. The iterations in the elaboration phase involve all the senior engineers from all disciplines in order to handle the major risks; their time should not be wasted with details of processes related to low hanging fruit. Non-risk generating topics related to exact specification of service interfaces should be postponed until the construction phase.


[REF-1] Mapping of SOA to RUP. Filippos Santas, April 2011, in [REF-2]

[REF-2] SOA Governance. Thomas Erl et al. April 2011.

[REF-3] MSOAM, The Mainstream SOA Methodology, Thomas Erl (

[REF-4] Suitability of Extreme Programming and RUP Software Development Methodologies for SOA Applications, Guillermo A. Callahan, 2006 (

[REF-5] Building SOA Solutions Using the Rational SDP. Uehli Wahli et al. IBM redbooks, 2007.

[REF-6] Mapping of SOA and RUP: DOA as Case Study, Shahid Hussain, Bashir Ahmad, Shakeel Ahmad, Sheikh Muhammad Saqib, Journal of Computing, January 2010

[REF-7] Working with SOA and RUP, Solmaz Boroumand, SOA Magazine Issue XVI, March 2008

[REF-8] Enterprise Unified Process: Extending the Rational Unified Process, Scott W. Ambler, John Nalbone, and Michael Vizdos, Prentice Hall (

As we mentioned in the introduction, there is no explicit literature in addressing SOA risks with RUP. Nevertheless, it is worth acknowledging other work that has been done in the area of mapping SOA with RUP. For example:

  • The findings from “Suitability of Extreme Programming and RUP Software Development Methodologies for SOA Applications” [REF-4] provides an abstract mapping between RUP and SOA methodologies;
  • A RUP for SOA plug-in was made available in 2005 to help extend the RUP analysis and design approach with workflows and artifacts required for service-oriented analysis and design. IBM has provided excellent documentation on this (see [REF-5]);
  • A mapping of high level service design stages to RUP phases was published in “Mapping of SOA and RUP” [REF-6], but this work did not cover service-oriented analysis;
  • A combination of RUP and the MSOAM [REF-3] appeared in the March 2008 issue of the SOA Magazine [REF-7]. This article uses RUP to elaborate service inventories and it focuses on processes related to top-down Service-Oriented Analysis stages in relation to the RUP activities related to Business Modeling; and
  • The “Enterprise Unified Process” [REF-8] delves into extending RUP with activities related to SOA or enterprise architecture in general. The limitations of RUP for operation and support of software after its deployment are treated by the Enterprise Unified Process (EUP), an extension of RUP.