FIT for SOA? Introducing the F.I.T.-Metric to
Optimize the Availability of Service Oriented
Architectures
Sebastian Frischbier, Alejandro Buchmann, Dieter P
¨
utz
Abstract The paradigm of service-oriented architectures (SOA) is by now accepted
for application integration and in widespread use. As an underlying key-technology
of cloud computing and because of unresolved issues during operation and mainte-
nance it remains a hot topic. SOA encapsulates business functionality in services,
combining aspects from both the business and infrastructure level. The reuse of
services results in hidden chains of dependencies that affect governance and opti-
mization of service-based systems. To guarantee the cost-effective availability of
the whole service-based application landscape, the real criticality of each depen-
dency has to be determined for IT Service Management (ITSM) to act accordingly.
We propose the FIT-metric as a tool to characterize the stability of existing service
configurations based on three components: functionality, integration and traffic. In
this paper we describe the design of FIT and apply it to configurations taken from
a production-strength SOA-landscape. A prototype of FIT is currently being imple-
mented at Deutsche Post MAIL.
1 Introduction
A company’s IT Service Management (ITSM) has to fulfill conflicting demands:
while minimizing costs, IT solutions have to support a wide range of functionality,
be highly reliable and flexible [22]. The paradigm of service-oriented architectures
(SOA) has been proposed to solve this conflict. SOA was intended to facilitate the
integration of inter-organizational IT-systems, thus becoming a key enabler of cloud
computing [12]. At present, it is used mostly for intra-organizational application
Sebastian Frischbier, Alejandro Buchmann
Databases and Distributed Systems Group, Technische Universit
¨
at Darmstadt,
e-mail: lastname@dvs.tu-darmstadt.de
Dieter P
¨
utz
Deutsche Post AG, Bonn, e-mail: d.puetz@deutschepost.de
1
2 Frischbier et al.
integration. Especially large companies, such as Deutsche Post DHL, use SOA to
integrate and optimize their historically grown heterogeneous application landscape.
From an architectural point of view, the SOA paradigm reduces complexity and
redundancy as it restructures the application landscape according to functionality
and data-ownership. Basic entities within a SOA are services organized in domains
without overlap. Each service encapsulates a specific function with the correspond-
ing data and is only accessible through an implementation-independent interface.
Services are connected according to a given workflow based on a business pro-
cess [29].
From an infrastructure point of view, services are usually provided and consumed
by applications. With the term ’application’ we refer to large-scale complex systems,
themselves quite often consisting of multi-tier architectures running on server clus-
ters serving thousands of clients. These applications have to be available according
to their business criticality. The desired level of availability is specified in service
level agreements (SLA) in terms of service level targets (SLT). These differ accord-
ing to the characteristics of the individual application and the means necessary to
meet the desired level of availability [7]. Usually, the different service levels can
be grouped into three classes: high availability (gold), medium availability (silver)
and low availability (bronze). Effort and means needed for the operations provider
to guarantee a given level of availability are reflected in the costs.
Deciding on the proper level of availability and defining adequate service levels
is a difficult task, which becomes even more complex in service-based and dis-
tributed environments. The SOA paradigm drives the reuse of existing services by
enabling their transparent composition within new services. As functionality and
data are encapsulated, services have to rely on other services in order to run prop-
erly. This results in a network of hidden dependencies, since each service is only
aware of its own direct dependencies on the consumed services. These dependencies
affect the availability of applications directly as applications rely on other services
to communicate and access information in service-based environments. Chains of
interdependent services can lead to an application with higher availability becoming
dependent on an application with lower availability even if the applications have no
direct semantic relationship.
IT Service Management has to decide on the criticality of such a relationship
and act accordingly. Criticality in this context does not refer to the probability of a
breakdown actually taking place but to the impact on the application landscape once
it occurs. The following approaches are possible to cope with disparities in service
levels of depending applications: i) all participating applications are operated on the
highest level of availability present in a chain of dependencies; ii) the configuration
stays unchanged; iii) the SLA of single participants is changed to minimize the ex-
pected impact. As the ”methods used are almost always pure guesswork, frequently
resulting in drastic loss or penalties” [38, 43], the first approach is often favored.
Although it succeeds, it is surely inefficient and expensive. Even hosting services
alternatively in cloud environments rather than on-premise does not solve this prob-
lem. It rather shifts the risk of availability management to the cloud provider who
will charge for it.
FIT for SOA? 3
Due to the lack of proper decision support, both the second and third approach
are usually avoided as they may result in serious breakdowns and loss of revenue.
Therefore, ITSM requires methods and tools to: i) model all relevant dependencies;
ii) identify hotspots and; iii) decide on their criticality. In particular, deciding on the
criticality is important as this allows for ranking hotspots (e.g. as preparation for
closer inspection) and simulating changes.
We introduce the FIT-metric to aid ITSM in these tasks, especially in deciding on
the criticality of dependencies in existing service-oriented architectures and simulat-
ing changes. Our metric consists of the three components: functionality, integration
and traffic. The necessary data can be cost-effectively obtained from end-to-end
monitoring and existing documentation. FIT is the result of our analysis conducted
at Deutsche Post MAIL and is currently implemented there.
The contributions of this paper are: i) we identify the need for applications and
their dependencies to be ranked according to their criticality; ii) we propose a metric
taking into account functionality, integration and traffic of the services involved to
aid ITSM in assessing the appropriate service level in interdependent SOA-based
systems; iii) we evaluate our approach by applying it to actual service configurations
taken from a product-strength SOA-landscape.
The structure of this paper is as follows: we present a production-strength SOA
in Sect. 2 to point out the need for a criticality-metric for service-dependencies. In
Sect. 3 we present the design of our FIT-metric in detail. We use a case study to
evaluate our approach in Sect. 4. We conclude our paper by reviewing related work
on the topic of metrics for service-oriented architectures in Sect. 5 followed by a
summary of our findings and a short outlook on future work in Sect. 6.
2 A Production-Strength SOA Environment
Deutsche Post AG is the largest postal provider in Europe, with Deutsche Post
MAIL division alone delivering about 66 million letters and 2.6 million parcels to
39 million households in Germany each working day. Furthermore, Deutsche Post
MAIL increases the level of digitalization in its product-portfolio (e.g. online and
mobile based value-added services) since 2009 [8]. In 2010 Deutsche Post MAIL
started to offer the E-Postbrief product to provide consumers and business users
with a secure and legally compliant form of electronic communication [9].
The application landscape supporting these processes and products was trans-
formed to apply the SOA-paradigm in 2001 [14]. Today, applications communi-
cate across a distributed enterprise service bus (ESB) by consuming and providing
SOA-services that are grouped in mutually exclusive domains. The initially used
SOA-framework has been a proprietary development by Deutsche Post MAIL called
4 Frischbier et al.
Service-oriented Platform (SOP). Today, SOP’s open-source successor SOPERA is
at the heart of both Eclipse SOA
1
and Eclipse Swordfish
2
.
The results discussed here are based on our analysis of the Deutsche Post MAIL
SOP/SOPERA application landscape using a Six Sigma-based [11] approach. This
included conducting interviews, reviewing documentation as well as assessing mon-
itoring capabilities to identify dependencies and business criticalities. All data pre-
sented in this paper is anonymized due to confidentiality requirements.
The main findings of our analysis are: i) long chains of dependencies between
services affect the availability of applications in matured production-strength SOA-
landscapes as the SOA-paradigm itself fosters the reuse of services; ii) SOA-
dependencies are hard to uncover for ITSM at runtime as they are hidden in the
SOA-layer itself; iii) the data necessary to identify and analyze them at runtime
may be already existing but is often not available at first as it is spread across differ-
ent heterogeneous applications; iv) to the best of our knowledge, there is no metric
available for ITSM to decide on the criticality of service-relationships based on the
data usually available at runtime. Based on these findings: i) we initiated a special-
ized but extensive end-to-end monitoring of the SOA-application landscape to allow
for dependencies and their usage to be quantified automatically in the future; ii) we
defined a cost-effective criticality-metric based on the available data; iii) we built a
prototypic software tool named FIT-Calculator to allow for automated graph-based
analysis and simulation based on the monitored data.
The availability-’heat map’ of the SOA-landscape as illustrated in Fig. 1 is auto-
matically generated based on the monitoring data currently available to us. It gives
an overview of 31 participating applications and their 69 service-relationships. Each
node represents an application providing and consuming SOA-services. The desired
level of availability for each node x is expressed by the node’s color as well as by
an abbreviation in brackets ([g]old, [s]ilver and [b]ronze). Edges denote service-
relationships between two applications with an edge pointing from the consum-
ing application to the application providing the service (direction of request). Edge
weights refer to the number of requests processed over this dependency within a
given period. Dependencies of consuming SOA-services on providing SOA-services
within an application are modeled as an overlay for each application (not shown).
This visualization allows ITSM to identify hotspots easily. Hotspots, in this con-
text, refer to applications that cause potentially critical relationships by providing
SOA-services to applications with higher levels of availability. In the given exam-
ple, 8 hotspots (A1, A5, A10, A11, A16, A18, A20, A23) cause 11 potentially criti-
cal relationships. On the heat map in Fig. 1, these relationships are marked bold red
with the hotspots being drawn as rectangles.
1
http://www.eclipse.org/eclipsesoa/
2
http://www.eclipse.org/swordfish/
FIT for SOA? 5
Fig. 1: Graph representing applications and their direct SOA-relationships.
3 Introducing the F.I.T.-Metric
The criticality of a single hotspot a depends on the criticality of each relationship
between a and the depending applications with higher SLA. To us, the criticality
of a single relationship e(a, x) in general is primarily influenced by: i) the business
relevance F
x
of the application x directly depending on a via e(a, x); ii) the impact
of e(a, x) on other applications in the SOA-landscape due to the integration I
a,x
of x
(i.e. x serving as a proxy); iii) the actual usage T
a,x
of the relationship e(a, x) by the
depending application x.
F
x
and I
a,x
refer to independent aspects of x’s importance to the system landscape
and the business users. An application’s core function alone can be highly relevant to
business users (e.g. business intelligence systems) while it may be unimportant for
other applications from an integration point of view. In turn, an application serving
mainly as a proxy for other applications can be relatively unimportant to business by
its own. As these two aspects of a relationship are rather static (i.e. an application’s
core functionality is seldom altered completely over short time and dependencies
between applications change only infrequently), they have to be weighted by an
indicator for the actual usage of this relationship.
Therefore, we define the criticality eFIT
e(a,x)
of the relationship e(a, x) as the
sum of F
x
and I
a,x
, weighted by T
a,x
in Eq. (1).
eFIT
e(a,x)
= (F
x
+ I
a,x
) · T
a,x
(1)
