Service Oriented Architecture Design and Development Method
René van Donselaar
Universiteit Utrecht
Introduction
As application portfolios grow, enterprises have increasing difficulty managing all applications.
One of the main issues is that applications are built with the tools that are available at a certain time and
therefore the application portfolio will contain applications that are built based on different programming
languages and design patterns. Making applications that are built using different programming languages
exchange data is a complex and costly task. Tracking the functionalities that are covered by applications
is difficult and redundancy occurs by a lack of documentation and integration of applications.
Architecture with a higher level of abstraction can help solve these problems. Service Oriented
Architecture (SOA) is a form of enterprise architecture based on both internal and external services which
communicate via interfaces (Brown et al., 2002). Services are used to provide other applications or
interfaces access to functionality that can come from one or more applications. When using services the
underlying applications are invisible to the user and can communicate with other services, independent of
programming language or platform. This also creates opportunities for interoperability with other
enterprises, making it more easy to use each other’s services. SOA requires that the services are
documented and reused within business units to maximize development efficiency and reduce the
complexity of growing application portfolios. For the implementation of SOA, the business has to be
adapted to follow the new set of principles. Although the business is an important aspect of successful
implementation of SOA, the application design and development also needs to be adapted. Using existing
applications and adding new interfaces is not enough, it requires a new development method that is
integrated through the whole development process. In this paper we will discuss the Service-Oriented
Design and Development Method (SODDM) by Papazoglou and Van den Heuvel (2004). Papazoglou is a
Computer Science professor and has specialized in Service Science. Over the years he has published over
eighteen articles related to SOA. His most famous work is Service-oriented computing (2003) which has
been cited over 1400 times. For developing SODDM Papazoglou worked together with Van den Heuvel
who is an Information Systems professor. Van den Heuvel is an expert in service systems and business
process management. His latest work on SOA is Business policy compliance in service oriented systems
(2011) that describes a form of adaptive SOA that can handle the changing business policies within an
enterprise. The SODDM method is based on Rational Unified Process, Component-based Development
and Business Process Modeling. It bears resemblance to many other agile development methods by using
an iterative process with phases. Within the phases we see distinct differences with an agile development
method like SCRUM (Schwaber, 2009), which is based on products with a product backlog. SODDM
starts with a planning phase; defining the business needs and goals in order to identify services rather than
products. This step is crucial for business alignment and for managing the application portfolio. The next
phase involves analyzing a business case in order to find possible solutions and alternatives, much like in
a PRINCE2 project (Jansen, 2007). The difference is that this phase is also involves specific SOA related
analyses, like service coupling; where the goal is to make the business processes as independent as
possible. The services in the business process are also analyzed for their cohesion; the services should be
highly related to one another. Other phases are: Provisioning, deployment and monitoring. SODDM
provides an agile based development method that is geared towards managing services and tight business
alignment in order to implement a SOA architecture.
[ Example ]
For this example an imaginary airline company referred to as Aircom will be used. First,
the planning phase is explained. Aircom has a set of business needs that have to be addressed:

Customers should be able to do their own bookings

Customers should be able to check for available seats

Customers should be able to pay for their booking
A business goal is derived from these business needs. Aircom has the goal of servicing their
customers with an online booking web application. The next activity is to look at the current
technology landscape in order to define a solution. The technology that is fit for the project is
chosen based on what is currently available, the costs of the development and what technology is
already used within the company.
To find which services need to be created and which have already been incorporated, the current
portfolio of services is analyzed in the analysis and design phase.
Table 1 - portfolio analysis
Service name
Booking registration service
Booking cancellation service
Booking availability request service
Customer login service
Customer registration service
Customer payment service
Is implemented
Yes
Yes
Yes
No
No
No
Table 1 depicts the portfolio for the bookings business process, which is a combination of the asis situation with the to-be situation. It shows which services the company had already
implemented and those that need to be implemented. Since some services are already available
they can be coupled with the new services for web based bookings. By doing this, the SOA
principle of reusing existing services within a business process can be addressed.
After this a business process realization scenario is chosen, which consists of four major
categories:

Green field development; which starts with the development of a service and then looks
at the possible language for the webinterface.

Top-down; when using an already existing interface.

Bottom-up; when a new interface is to be created.

Meet-in-the-middle; when an already existing interface is being mapped partially onto a
new service.
The choice for a scenario is based on costs, risks, benefits and return of investment.
The service is specified according to three elements, which are structural, behavioral and policy
specifications. This specification can be written in XML as is shown in the example below. Here
the existing service of booking registration is shown.
<portType name=”canReceiveA43_PortType”>
<operation name=”BookingRegistrationRequest”>
<output message=”tns:BookingRegistrationRequest”/>
</operation>
</portType>
The first specification is the port type, which is used to communicate with the service. An
operation is defined with its name, in this care ‘BookingRegistrationRequest’. The output
message is in many cases identical to the operation name and is the message that is sent when the
operation is triggered.
In the specification of services many more attributes are documented, such as the programming
style and service policies. The business processes are described and the roles that perform them.
After the design is finished the construction will start in the construction and testing phase. The
construction will be based on the previously defined planning, analysis and design. The
constructed service is tested on its functionalities according to its specification. Strategies for
service metering, rating and billing are defined in the provisioning phase. In this example the
service could be offered for free and the billing could be incorporated in the actual payment for
the booking. The service is now ready to be deployed in the deployment phase. How this is done
has to do with the outcome from the process realization analysis. For this example the new
service is deployed within the existing IT structure of Aircom, as they are already offering
similar services. For the web interface an external party is used. Finally the service enters the
execution and monitoring phase. Here who will be responsible for what part of the service is
described. For the existing services no changes are made, while for the new services members of
the business process are assigned to each service. The service is monitored by looking at aspects
of the SLA that can be measured. In this example the time that it takes to get a response from the
booking service is measured to see if it is according to the SLA. The up-time of the service can
also be measured which is stated in the SLA.
Literature review
SODDM was first introduced by Papazoglou and Van den Heuvel (2004) and is based on
Rational Unified Process, Component-based Development and Business Process Modeling. Rational
Unified Process was introduced by Kruchten (2004) and is based on the best practices in software
engineering. SODDM addresses the need for a method to design and develop services within an
organization that uses SOA for their enterprise architecture. Brown et al. (2002), describes the process of
design and development of web applications in a service-oriented environment. This study only shows the
design and development aspects and does not deal with the complexities of the business side and how to
translate this into services. Zimmerman et al. (2005) also provided techniques for analyzing and
designing SOA development based on UML and Rational Unified Process, but this study is more general
and does not describe an entire method for dealing with development. Reijnders et al. (2011) has
compared many of the service-oriented software development methods, in this study SODDM is also
described and compared with other methods like SOMA. SOMA was introduced by Arsanjani (2004) and
is an agile method developed and used by IBM for a SOA architecture development. Another method is
the WSIM by Lee et al. (2006) which is based on the extending existing development methods for
development geared towards SOA. The study also shows that SODDM and SOMA are the most dominant
studies on this subject.
Process Deliverable Diagram
After analyzing SODDM a graphic representation of the process and its deliverables was
made. It shows all activities one must perform on the left side, ordered from top to bottom. On
the right side a connection is made with the deliverables that are produced by each activity. Van
de Weerd & Brinkkemper (2006) can be used as reference for reading PDDs.
Figure 1 - SODDM PDD
Activity table
All activities that are depicted in the PDD have been included in an activity table. Here
each activity is described. The name of the activity is displayed and next to it are the (optional)
sub activity names with a short description in the last column.
Table 2 - Activity table
Activity
Plan
Analyze
Design
Sub activity
Analyze
business
needs
Review
current
technology
Conceptuali
ze
requiremen
ts
Analyze
costs and
benefits
Categorize
and
decompose
business
environmen
t
Review
business
goals and
objectives
Identify
processes
Scope
processes
Description
Business needs are analyzed in order to define BUSINESS GOALS.
(Papazoglou & Van den Heuvel, 2004)
The current technology landscape is being reviewed in order to find
suitable technologies that can be used within the business in a
TECHNOLOGY LANDSCAPE. (Papazoglou & Van den Heuvel, 2004)
The requirements of the new environment are conceptualized and
mapped to new or available implementations. (Papazoglou & Van
den Heuvel, 2004)
A financial analysis of the costs and benefits is performed that
produces a BUDGET AND SOFTWARE DEVELOPMENT PLAN.
(Papazoglou & Van den Heuvel, 2004)
The business environment is categorized and decomposed into
BUSINESS AREAs based on the functions provided by the business
processes. (Papazoglou & Van den Heuvel, 2004)
Business goals and objectives that drive the development of business
processes are reviewed as part of the ANALYSIS. (Papazoglou & Van
den Heuvel, 2004)
Current processes are identified in order to create an AS-IS PROCESS
MODEL. (Papazoglou & Van den Heuvel, 2004)
This defines the scope of business processes in order to create TO-BE
PROCESS MODEL. (Papazoglou & Van den Heuvel, 2004)
Incrementally adds more implementation details to an abstract
Analyze gap service/process interface. (Papazoglou & Van den Heuvel, 2004)
Analyze
process
An approach that considers diverse business process realization
realization scenarios. (Papazoglou & Van den Heuvel, 2004)
Address
Analyze and solve design concerns such as managing granularity,
design
concerns
Specify
services
Specify
business
processes
Construct
Test
Provision
Execute
service
Monitor
reuse and composability. (Papazoglou & Van den Heuvel, 2004)
Specify the service by structural, behavioral and policy specification.
(Papazoglou & Van den Heuvel, 2004)
Describe the business process structure, Roles and non-functional
business process concerns. (Papazoglou & Van den Heuvel, 2004)
The development of the web service and implementation of the web
service. (Papazoglou & Van den Heuvel, 2004)
Test
Run the implementation and compare its actual to its expected
dynamics
behavior. (Papazoglou & Van den Heuvel, 2004)
Test
Test how the system executes functions and if they follow the
functions
expected behavior. (Papazoglou & Van den Heuvel, 2004)
Test
Monitoring the systems on-line response times and transactions
performanc under peak workload conditions. (Papazoglou & Van den Heuvel,
e
2004)
Test
Tests whether all services function properly when assembled into
assembly
business processes. (Papazoglou & Van den Heuvel, 2004)
Govern
Align the business strategy with the IT strategy. (Papazoglou & Van
service
den Heuvel, 2004)
Certify
List all the properties that the application may attain. (Papazoglou &
service
Van den Heuvel, 2004)
Create a pricing model that could be used to calculate the charges for
Rate service the customer. (Papazoglou & Van den Heuvel, 2004)
Define
billing
Define a strategy for billing services that way the customer needs to
strategy
perform his payment. (Papazoglou & Van den Heuvel, 2004)
Ensure the new process is carried out by all participants. (Papazoglou
& Van den Heuvel, 2004)
Measure the service level objectives and performance. (Papazoglou &
Meaure
Van den Heuvel, 2004)
Evaluate the service level objectives and performance. (Papazoglou &
Report
Van den Heuvel, 2004)
Concept table
The concepts that are present in the PDD are listed in Table 3. Each concept is shown by
name and explained with a short description.
Table 3 – Concept table
Concept
Description
Describes the objectives of the business. (Papazoglou & Van den
Heuvel, 2004)
Describes the current available technology that can be used.
(Papazoglou & Van den Heuvel, 2004)
A description of functions served by business processes. (Papazoglou &
Van den Heuvel, 2004)
BUSINESS GOAL
TECHNOLOGY
LANDSCAPE
BUSINESS AREA
DEFINITION
BUDGET AND
SOFTWARE
Describes the tasks, deliverables and schedule. (Papazoglou & Van den
DEVELOPMENT PLAN Heuvel, 2004)
Consists of BUSINESS GOAL, BUSINESS AREA DEFINITION and BUDGET
AND SOFTWARE DEVELOPMENT PLAN (Papazoglou & Van den Heuvel,
PLANNING
2004)
Consists of an AS-IS PROCESS MODEL and a TO-BE PROCESS MODEL.
ANALYSIS
(Papazoglou & Van den Heuvel, 2004)
AS-IS PROCESS
Describes the current business processes and services. (Papazoglou &
MODEL
Van den Heuvel, 2004)
TO-BE PROCESS
Describes a desired situation of business processes and services.
MODEL
(Papazoglou & Van den Heuvel, 2004)
The design of the service that describes the granularity, reuse,
composability, specification and business processes. (Papazoglou & Van
SERVICE DESIGN
den Heuvel, 2004)
SERVICE ORIENTED
The tested construction of the service. (Papazoglou & Van den Heuvel,
APPLICATION
2004)
Internal and external parties look at the quality of the service and
REVIEW
report in a review. (Papazoglou & Van den Heuvel, 2004)
Can be an SLA, and contains all service certificates. (Papazoglou & Van
SERVICE CONTRACT
den Heuvel, 2004)
Shows the costs, benefits and resources that are involved with the
BUSINESS CASE
provision. (Papazoglou & Van den Heuvel, 2004)
A description of how the customer should pay for the service.
BILLING STRATEGY
(Papazoglou & Van den Heuvel, 2004)
Consists of a BILLING STRATEGY and one or more REVIEWs, SERVICE
CONTRACTs and BUSINESS CASEs. (Papazoglou & Van den Heuvel,
PROVISION PLAN
2004)
SERVICE MONITOR
Contains the response time, throughput and availability of the service.
REPORT
(Papazoglou & Van den Heuvel, 2004)
References
Arsanjani, A. (2004). Service-oriented Modeling and Architecture. IBM developerworks.
Brown, A., Johnston, S., Kelly, K. (2002). Using Service-Oriented Architecture and ComponentBased Development to Build Web Service Applications. Rational Software Corporation.
Jansen, P. (2007). Prince2 Compact. Pearson Benelux: Education.
Kruchten, P. (2004). The rational unified process: an introduction. Addison-Wesley Professional.
Lee, S., Chan, L., Lee, E. (2006). Web Services Implementation Methodology for SOA
Application. Industrial Informatics.
Papazoglou, P., Van den Heuvel, W. (2004). Service-Oriented Design and Development
Methodology. Int. J. of Web Engineering and Technology (IJWET).
Reijnders, G., Khadka, R., Jansen, S. (2011). Developing a Legacy to SOA Migration Method.
Department of Information and Computing Sciences, Utrecht University, Tech. Rep. UU-CS2011-008.
Schwaber, K. (2009). Agile project management with Scrum. O'Reilly Media.
Van de Weerd, I., Brinkkemper, S. (2009). Meta-Modeling for Situational
Analysis and Design Methods.
Zimmerman, O., Schlimm, N., Waller, G., Pestel, M. (2005). Analysis and design techniques for
Service-Oriented Development and Integration. IBM Deutschland.
Appendix
Conceptualized requirements (conceptual solution)
Requirements
Name
Some requirement
Some requirement
Some requirement
Description
A short description
A short description
A short description
Owner
Who submitted the requirement
Who submitted the requirement
Who submitted the requirement
Business solution
Name of the solution
Textual description
Components description
Graphical representation of the business solution (use cases)
System
«extends»
Performed action
UseCase1
UseCase5
Performed action
UseCase2
Performed action
UseCase6
UseCase3
Name of the actor
Name of the actor
Performed action
UseCase4
User template
Name
Role
Description
Name of the user (if available)
Name of the role within the system
Short description of the user
Usecase template
Id
Name
Description
Extends
Unique usecase id
Name of the usecase
Short description of the usecase
Extends which usecase(s)