provisioning (only within some controllable
service inventory vs. to unknown consumers)
In the investigation presented here, the information
on phenomena and context was gathered by
interviews (both face-to-face and by phone) with
several persons representing distinct roles (e.g.,
software architect, software developer, project
manager), by document analysis (design guidelines,
service specifications, models) as well as by systems
analysis (sample services). The final case report was
checked for correctness by the contact persons of the
companies. Very condensed versions of the case
reports are contained in the following Section.
4 CASE STUDY
4.1 Case 1: Mail Order Company
Context. The case stems from a leading trading and
services corporation; its 123 companies employ
around 50,000 persons in nearly 20 countries. The
IT department has circa 230 employees for
development. The application systems landscape
consists of 200 application systems and includes a
central mainframe application that is responsible for,
e.g., customer data management, invoicing and order
picking. Since the mainframe application was
written in assembly language (current in-house
software development uses Java and J2EE), it should
be replaced by a new application system.
In 2002/2003 it was decided to conduct SOA-
directed reengineering of the mainframe application
for two reasons: First, SOA is able to cope with the
unavoidable heterogeneity (in terms of functionality,
technology, life cycle and controllability) of the
corporation’s systems landscape, which is a
consequence of continuous acquisitions of
companies. Secondly, SOA increases the flexibility
to react to new requirements such as seasonal
business (Christmas etc.), promotions and changing
legal regulations.
The new service-oriented application system
should cover the functionality to manage customer
orders (i.e., order management in the narrow sense
of the word, stock management, customer data
management, invoicing and order picking), which is
currently covered by several application systems
including the mainframe. The consumers of the
intended services are several types of clients (e.g.,
call center clients, web shop clients ‘business to
consumer’ (B2C) and ‘business to business’ (B2B))
that are mostly under the control of the corporation.
Especially the management of customer data is
subject to strict security restrictions, and the web
shop client for consumers (B2C) is performance-
sensitive.
The service design process, summarized in
Figure 2 using the Business Process Modeling
Notation (BPMN), is hybrid: Top-down, business
processes and their sub-processes are identified. A
business process is defined as a set of logically
related activities that are chronologically ordered,
started by events and lead to results. For IT-
supported business (sub-) processes, use cases are
derived. A use case (e.g., ‘create order’) is an
interaction sequence between a role and a software
system to solve some business task. Use cases are
modeled as UML activity diagrams. Indivisible
(atomic) interaction sequences within a use case that
have a business goal are called application functions
(e.g., ‘find shipment with items’). Application
functions are candidate application services.
Simultaneously, object-oriented analysis is
performed bottom-up: First, domain classes are
identified, i.e., application-independent objects of
the real world with attributes and functionality (e.g.,
‘article’ or ‘order’). Then, from the domain classes,
analysis classes are derived that specialize the
domain class within the context of a particular
application system. For example, ‘stocked article’
and ‘orderable article’ are analysis classes of the
domain class ‘article’. Each method of an analysis
class (e.g., ‘create’, ‘release’, ‘cancel’) corresponds
to an application function, and an application
function can be realized by one or more methods of
an analysis class.
Application services (e.g.,
GetShipmentWith-
Items
or DeliveryConditionOperations; the
latter one changes the type of some delivery to
‘urgent’ or specifies the delivery address) are the
interfaces of software components that provide
methods to realize application functions. They result
from candidate application services by applying
design rules. These rules comprise the SOA design
principles ‘abstraction’ and ‘statelessness’ as well as
the requirement that an application service should
correspond to the smallest application function. The
last requirement leads, for example, to a separation
between the application services
CreateCustomer,
which, among others, includes name and address,
and
ChangeCustomerAddress.
Subsequently, the designed services are
evaluated by the SOA design principle ‘reusability’
and the criteria ‘similarity’ and ‘stability’. Similarity
means that existing services must be extended if
they provide at least 50 % of the functionality of
some new application service. Stability calls for the
CASES OF SOFTWARE SERVICE DESIGN IN PRACTICE
379