An Approach to the Analysis and Evaluation of
an Enterprise Service Ecosystem
Nicolas Repp, Stefan Schulte, Julian Eckert
Rainer Berbner and Ralf Steinmetz
Multimedia Communications Lab
Department of Computer Science
Technische Universit
at Darmstadt, Germany
Abstract. Currently, the implementation of service-oriented concepts is one of
the main activities of many IT and business departments throughout enterprises
of various industries. Service-orientation as a concept is no novelty for many
enterprises - many software systems and components offering technical and busi-
ness functionality do comply with service-oriented principles. Nevertheless, the
analysis, evaluation, and integration of existing services are often neglected in
process models describing the implementation of service-oriented concepts. This
paper describes an approach to the analysis and evaluation of those existing ser-
vices to become part of the enterprise service ecosystem, which we call service
inventory. The service inventory is realized as a generic extension to existing sys-
tems development methodologies, which allows its integration into the already
used service-oriented methodology. The service inventory approach is based on
Service-oriented Architecture research, principles from systems analysis and de-
sign, as well as on auditing principles.
1 Introduction
A current trend in software and enterprise engineering is the Service-oriented Architec-
ture (SOA) paradigm, which can be used to design and develop complex IT systems.
The core concept of SOA is the “service”, which can be understood as a self-describing
encapsulation of domain-specific functionalities [1] [2]. Business processes and the ap-
plications supporting them can be built based on compositions of distributed and loosely
coupled services.
Following the SOA trend many software vendors as well as IT service providers and
consulting companies are jumping on the bandwagon, offering software, toolsets, and
methodologies for the implementation of SOA in an enterprise and the system develop-
ments based on services. Especially in the area of middleware, supporting SOA (often
referred to as the Enterprise Service Bus) and systems development methodologies for
the implementation of SOA (the focus of this paper) there is a vast range of offers from
almost all vendors. However, existing vendor specific systems development method-
ologies do not sufficiently consider the integration of an existing service ecosystem into
the SOA, as they do not accept the fact that many principles and aspects of SOA are
Repp N., Schulte S., Eckert J., Berbner R. and Steinmetz R. (2007).
An Approach to the Analysis and Evaluation of an Enterprise Service Ecosystem.
In Proceedings of the 1st International Workshop on Architectures, Concepts and Technologies for Service Oriented Computing, pages 42-51
DOI: 10.5220/0001348300420051
already in use. Furthermore, many software systems and components in use offer tech-
nical and business functionalities that already comply with service-oriented principles.
Those existing service have to be found and integrated into the SOA.
In this paper, we describe an approach to the analysis and evaluation of an existing
enterprise service ecosystem and its services, which we call “service inventory” accord-
ing to the concept of the inventory process in financial accounting. Parts of the approach
are the result of a research project in cooperation with an industry partner. The goal of
this research was not to create “yet another” systems development methodology but to
develop a generic enhancement of existing SOA systems development methodologies.
Furthermore, the development of a tool for the analysis and evaluation of services (“au-
diting of services”) was also an objective. Intension behind the tool was to allow the
creation of a service inventory by an experienced third party in a timely manner. Both
the approach itself and the tool have to be customized with respect to data models and
terminology in order to fulfill the needs of a particular enterprise.
The rest of this paper is structured as follows. In the next section, we will pro-
vide definitions important for the further understanding of the paper. The successive
section introduces aspects of service-orientation, which are the foundation of the eval-
uation framework included in our service inventory approach. The service inventory
approach is described in a separate section based on a generic process, which can be
part of existing commercial systems development methodologies. The paper closes with
a conclusion and an outlook on future work.
2 Basics and Definitions
2.1 Services and Business Processes
As already discussed in the introduction, we define services as self-contained encap-
sulations of domain-specific functionalities. The whole of services, which can be used
by an enterprise, is referred to as “enterprise service ecosystem”, which includes both
internal services and services obtained from external sources. The services can be com-
posed to execution plans containing the functionality of the business process [3] [4]
and subsequently be executed by a business process engine. The possibility of a map-
ping between business processes and services offering the needed functionalities are a
precondition for our work. We will not further discuss this topic in this paper.
Every relationship between a service provider and a service requester, no matter if a
service provider is internal or external, has to be documented in the form of a contract,
a so-called Service Level Agreement (SLA), describing the most important aspects of
the relationship. This contract can be explicit, i.e., described in a dedicated document,
or implicit by simply using a given service. Especially in business critical processes
the management and enforcement of SLAs is crucial [5]. SLAs can be part of the data,
which is examined during the service inventory process.
2.2 Service Inventory
According to the common understanding of the term “inventory” in accounting as both
“a detailed list of all the items in stock” and the “making (of) an itemized list ... (fol-
lowing the definition of the term in WordNet), we also use the term “inventory” in this
paper both for the process of taking stock as well as for the result of this process.
If applied to the concept of an enterprise service ecosystem, services (here: services
provided by the enterprise in scope) also can be seen as intangible assets of an enter-
prise, which have to be valued. The stocktaking of existing services, their analysis, and
evaluation is therefore called “service inventory”. Depending on the point in time and
the frequency of a service inventory, we can distinguish between a periodic (i.e., annual
or project initiated service inventory) and a perpetual service inventory (i.e., continuous
tracking of services). We assign no monetary value to a service during the service in-
ventory. Instead, the value of a service is measured based on its ability to be integrated
in the SOA, which should be implemented by the enterprise. To be more precise, the
measurement is founded on the assessment of several aspects of services, which are
discussed in the next sections.
In addition to the definition of the service inventory process, a service inventory
also describes the result of the taking stock process. Therefore, the service inventory
also represents a listing of all services at a given point in time. It can be managed by a
service repository. The description of services itself as well as the format of the listing
of services is out of scope of this paper. We will focus on the service inventory as a
process for the rest of the paper.
3 Service Aspects
This section about service aspects describes the foundation for the service inventory
process. Based on the aspects given in Table 1, the ability of integration in a SOA
is analyzed and evaluated. The service aspects were derived from different sources,
i.e., the common principles of service-orientation presented by Erl [6], the rules for
architectural design of enterprise IT by Voß et al. [7], the standardized specification of
business components by Ackermann et al. [8], as well as from our experience in SOA
Of further importance is the documentation of a service. It is the foundation for
all the aspects mentioned above - without a sufficiently complete and comprehensible
documentation the assessment of the services is not possible. To improve the usabil-
ity of the service inventory process we created a criteria catalog, which represents the
content and intension of the given service aspects. Every criterion is formulated as a
question, which can be easily answered based on a given range of possible answers
(mostly “yes”/“no”, where “no” signalizes a deviation from the targeted state).
4 Our Approach to the Analysis and Evaluation of Services
In this section, we describe the service inventory process. As a foundation for the service
inventory process, we will also present a generic systems development process with
respect to the implementation of SOA, in which the service inventory process can be
Table 1. Service aspects as the foundation for the service inventory.
Service aspect Description
Reusability Describes the ability of a service to be used without changes in different
scenarios than the ones it was specified for. Only changes in the parame-
terization of the service are acceptable.
Granularity Depicts the functional range as well as the complexity of a service. Ser-
vices of coarse granularity offer functionalities of an entire business do-
main, e.g., the implementation of an entire business process, whereas
services of fine granularity offer base functionalities useful in various
Autonomy Characterizes the independence of a service from other services as
well as from other resources. Furthermore, autonomy also describes the
uniqueness of a service with respect to its functionality, i.e., there are no
two services in one enterprise service ecosystem with the same function-
Context independence Describes the property of a service to operate without any context or state
information. Every call/execution of the service provides the needed in-
formation to operate. There is no keeping of state information or session
concept. Furthermore, a service has to offer compensating functionali-
ties in order to be independent from external intervention in case of an
Degree of coupling Specifies an additional measurement for the independence of a service,
aiming towards a preferably loose coupling of services, i.e., services can
be exchanged on the fly without the consideration of any dependencies.
Information hiding Neither information about technical details of the implementation nor
information with business or security critical character should be visible
to service requesters, especially if the service requesters are from outside
the enterprise.
Discoverability Characterizes the need to document a service and make it identifiable in
order to be found. Additionally, discoverability is also crucial in order
to avoid parallel developments of the same functionalities in different
departments or the unnecessary purchase of services due to the lack of
4.1 Prerequisites for the Approach
In order to apply the phases of the service inventory process to a given situation, we
need a sufficiently complete set of data about the service in scope. In contrast to the
inventory process known in accounting, we need a description of the subject we are
looking at because of its intangible character.
Based on experience from projects in the finance and telecommunications sector,
we observed that the following information about a service is usually available for an
Non-formal description of the service functionality.
Description of both service provider and service requester.
Service Level Agreements describing the non-functional properties a service provider
is willing to offer.
Furthermore, the following information is helpful, if available:
Formal description of the service functionality, e.g., in form of a semantically en-
hanced interface description.
Description of prospective service requesters and usage scenarios.
Classification of the service based on a service model used by the enterprise.
Documentation about the business processes, in which the services are/can be used.
It is not always possible to start the service inventory process with a complete set of the
information described above. In case of missing or ambiguous information with respect
to the service aspects, interviews or walkthroughs of the documentation in cooperation
with members of staff should be used to gather the missing information.
4.2 A Generic Systems Development Approach for the Implementation of SOA
As we stated before, the service inventory process is not a standalone process. It has to
be embedded in an existing systems development methodology for the implementation
of SOA and respective process. Therefore, we will first present a generic systems de-
velopment process in which the service inventory can be integrated. For this purpose,
we analyzed different vendor specific systems development methodologies for the im-
plementation of SOA, which we worked with before, i.e., methodologies, and processes
of IBM, Software AG, and IDS Scheer. Based on the similarities of the models and the
basic phases of the systems development processes discussed in Software Engineering
and Systems Development literature (e.g., [9] and [10]), we derived a simple generic
process for the implementation of SOA, taking full account of the given service ecosys-
tem. Both the generic process and the service inventory process are modeled using the
Business Process Modeling Notation (BPMN) [11], a standard for the description of
business processes broadly used in the area of SOA, in order to simplify the integration
with processes of different vendors or those already used by the enterprise.
The generic systems development process consists of five core phases, which all are
sub-processes themselves (see Figure 1). For simplification, we do not model iterations
of single phases or sub-processes as parts of the process in this paper, but they are
possible and valid in our process. The analysis phase is depicted in-depth, as the service
inventory process is part of it. The phases of the process are described in Table 2 in more
4.3 Phases of the Service Inventory Process
As stated in the previous section, the service inventory process is part of the analysis
phase in the generic systems development process for the implementation of SOA. We
can distinguish four phases of the service inventory process, which are depicted in Fig-
ure 2. An in-depth description of the single phases is subject of Table 3. The result of the
service inventory process can be directly used for the design of a SOA-based system,
as it describes services, which can be reused. The four phases are intentionally kept
generic in order to allow the adaptation to the current project context. Unfortunately,
there are also no generally accepted recommendations for service aspects, e.g., for the
granularity of a service, which could be used as a guide for the process.
Initiation and
Design of services
and service
Service operation
and management
+ + +
Service inventory
Business process
Fig.1. Generic systems development process for the implementation of SOA.
Service inventory
Scope definition
Completion of the
criteria catalog
Analysis of
Aggregation of
Fig.2. Overview of the service inventory process.
Nevertheless, the service inventory process is not only an academic concept. In
cooperation with a German IT consulting firm we developed an Excel based criteria
catalog containing 28 questions, which can be mapped to the seven service aspects. We
further integrated the service model of the firm, which classifies services into four cate-
gories. As a further enhancement of the generic process and criteria catalog, we created
examples for the evaluation of the criteria to allow a quick access to the approach. Fi-
nally, we estimated the time needed for the completion of every single criterion in order
to bundle the criteria into three preconfigured tests of different duration. Currently, the
approach is used in first SOA projects.
4.4 Service Inventory Process by Means of an Example
In this section, we want to give an example of the service inventory process. In the
first phase of our example, the objective of the service inventory is set to a check of
service reusability. Due to this fact, the criteria of the catalog are the most important,
i.e., receive the highest weights, which are related to the service aspect of reusability. A
single critical deviation of a criterion related to reusability leads to an “orange” rating
of the service, classifying it as only usable with restrictions. More than one critical
deviation will lead to a “red” rating and therefore to the exclusion of the service from the
Table 2. Phases of the generic systems development process for the implementation of SOA.
Phase Description
Initiation and planning In this initial phase, problems with respect to the business and its pro-
cesses are identified. The identification as well as the following sketch-
ing of a solution based on SOA is done on a high level, which is not
sufficient for an implementation. If in this phase the decision is made to
start a SOA-based project, further scoping and resource planning has to
be carried out, e.g., staffing, budgeting, or the planning of milestones.
Analysis Subsequent to the initiation and planning phase, the business needs and
processing requirements as well as the as-is situation of both the business
processes and the underlying enterprise architecture have to be examined
in detail during the analysis phase. In this phase, a service inventory has
to be performed to get an overview of services already in use, which
could be integrated into the solution.
Design of services and
service compositions
Based on the results of the analysis, we now can design services and
compositions of services in order to implement the needed business pro-
cesses. During this phase, not only new services have to be designed.
Moreover, the focus of a service-oriented approach is on the reuse of ex-
isting services. Both the existing and new services are combined in the
form of service compositions, i.e., parts lists forming blueprints of the
business processes to be implemented.
Implementation The blueprints and designs of business processes, service compositions,
and services from the last phase are implemented in this phase. The
implementation is realized on different levels of abstraction. Services
are implemented for example using traditional programming languages
and Web Service technology. Furthermore, service compositions also
have to be implemented in a format, which is machine-readable and -
interpretable. For this purpose, higher level composition languages are
used, e.g., the Business Process Execution Language (BPEL) in the Web
Service domain [12]. Service implementations and execution plans of
business processes based on services, which can be processed by busi-
ness process engines, are the outcome of this phase.
Service operation and
As the last phase of the generic systems development process for the
implementation of SOA, we describe the service operation and manage-
ment phase. This phase contains aspects of both a systems development
process and a service lifecycle model. In this phase, the set of services
implementing business functionalities is executed. The monitoring and
measurement of the execution often results in a need for improvement
and optimization of the developed system, so that additional iterations of
the systems development process have to be performed.
SOA. In the next phase, the adapted criteria catalog is completed based on a review of
the given documentation. The following questions are examples of criteria with respect
to the reusability of a service:
Does the documentation provide information about the data types and formats used
to invoke the service?
Table 3. Phases of the service inventory process.
Phase Description
Scope definition In this initial phase, the aims and objectives of the service inventory have
to be defined depending on the current situation of the enterprise. There-
fore, the scope of the service inventory has to be set, e.g., what services
have to be assessed and what amount of time is available for the service
inventory. Furthermore, the properties of a service, which are needed to
fulfill the goals of the targeted project, have to be specified in terms of
the seven service aspects. In addition, the aspects have to be weighted
among each other with respect to their relevance for the project and de-
viations from the targeted state have to be defined. Finally, it has to be
specified how many deviations of what severity lead to negative rating of
the service for the project (“definition of materiality”).
Completion of the crite-
ria catalog
Based on the scope of the service inventory, in this phase the questions in
the criteria catalog have to be completed during a review of the documen-
tation, an interview, or a walkthrough. The criteria catalog is completed
per single service.
Analysis of deviations In this phase, the deviations detected in the previous phase have to be
analyzed with respect to their severity. The deviations are classified into
the three types “minimal”, “moderate”, and “critical”, based on the defi-
nitions provided in the initial phase.
Aggregation of findings In the final phase of the service inventory process, the results of the pre-
vious phases have to be aggregated for every single service. The result
of this phase is a statement about the usefulness of the service for the
project and its ability to be integrated in the SOA. There are three pos-
sible outcomes of the service inventory process for every single service
in scope, which are classified into “green” (“service is useable without
restriction”), “orange” (“service is useable, but with restrictions”), and
“red” (“service is not useable” or “not a service”).
Does the description of the service provide mapping information of the service
functionality to the classification framework used by the enterprise?
Subsequent to the completion of the criteria catalog, the deviations detected in the pre-
vious step have to be analyzed in detail during the third phase. In our example, the non-
existence of the documentation of both data types and format for the service invocation
is classified as critical. Finally, the singular ratings of the service have to be aggregated.
One single critical rating results in an overall classification of the service as “usable, but
with restrictions” (“orange”), because of the lack of adequate documentation for data
types and formats is easily remediable.
The service inventory process is documented in a dedicated format, containing in-
formation about the assessed services, the scope of the service inventory, the auditor
performing the service inventory, the findings as well as the time needed for the ser-
vice inventory. Based on the documented amount of time needed for both the service
inventory process and single criteria, the service inventory process can be customized
in order to fit the needs with respect to the time restrictions of the project.
5 Conclusion and Outlook
In this paper, we presented an approach to the analysis and evaluation of an enterprise
service ecosystem, which is called service inventory. The service inventory is not a new
systems development methodology but an enhancement of existing approaches with a
strong emphasis on the current situation of an enterprise planning to implement a SOA.
Our approach details the phases of vendor specific processes coping with the analysis
and integration of existing services. All of the vendor specific processes address existing
services, but they do not address how to analyze and evaluate them with respect to their
potential use for the SOA implementation project. Based on the generic character of our
approach it is highly adaptable to the needs of an individual enterprise.
In the future, we have to specify and formalize the phases of both the generic pro-
cess and the service inventory process in more detail, whereas the differentiation of the
phases in both processes will not be changed. Additionally, the service aspects, which
are the foundation of the service inventory process, will be improved further with re-
spect to recommendations for the individual service aspects. For this, we are currently
preparing a multi-participant case study to evaluate best practices for service granu-
larity in different industries. Of further importance is also the specification of services
itself. We will evaluate existing specification frameworks for the description of services
in order to integrate such a framework into our approach. Additionally, we plan to inte-
grate our criteria catalog as well as the process into a web-based application in order to
support the service inventory process.
The work is supported in part by the E-Finance Lab e.V., Frankfurt am Main, Germany.
1. Krafzig, D., Banke, K., and Slama, D.: Enterprise SOA: Service-Oriented Architecture Best
Practices, Prentice Hall, Upper Saddle River, USA, 2005.
2. Papazoglou, M. P.: Service-Oriented Computing: Concepts, Characteristics and Directions,
4th International Conference on Web Information Systems Engineering (WISE 2003), IEEE,
Rome, Italy, 2003, pp. 3-12.
3. Repp, N., Berbner, R., Heckmann, O., and Steinmetz, R.: A Cross-Layer Approach to Per-
formance Monitoring of Web Services, ECOWS 2006 Workshop on Emerging Web Services
Technology, IEEE, Zurich, Switzerland, 2006: CEUR Workshop Proceedings, vol. 234, ISSN
4. Berbner, R., Grollius, T., Repp, N., Heckmann, O., Ortner, E., and Steinmetz, R.: An ap-
proach for the Management of Service-oriented Architecture (SOA) based Application Sys-
tems, Enterprise Modeling and Information Systems Architectures (EMISA 2005), Klagen-
furt, Austria, 2005, pp. 208-221.
5. Berbner, R., Heckmann, O., and Steinmetz, R.: An Architecture for a QoS driven compo-
sition of Web Service based Workflows, Networking and Electronic Commerce Research
Conference (NAEC 2005), Riva Del Garda, Italy, 2005.
6. Erl, T.: Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall,
Upper Saddle River, USA, 2005.
7. Voß, M., Hess, A., and Humm, B.: Towards a Framework for Large Scale Quality Architec-
ture, 2nd International Conference on the Quality of Software Architectures (QoSA 2006),
asteras, Sweden, 2006: Internal Report 2006-10, Universit
at Karlsruhe, ISSN 1432-7864.
8. Ackermann, J., Brinkop, F., Conrad, S., Fettke, P., Frick, A., Glistau, E., Jaekel, H., Kot-
lar, O., Loos, P., Mrech, H., Ortner, E., Overhage, S., Raape, U., Sahm, S., Schmietendorf,
A., Teschke, T., and Turowski, K.: Standardized Specification of Business Components,
Gesellschaft f
ur Informatik (German Informatics Society), Working group 5.10.3, Augsburg,
Germany, 2002:, accessed at 2007-04-22.
9. Whitten, J. L., Bentley, L. D., and Dittman, K.: Systems Analysis and Design Methods, 6/e,
McGraw-Hill, Columbus, USA, 2004.
10. Singh, S., and Kotze, P.: An Overview of Systems Design and Development Methodologies
with Regard to the Involvement of Users and other Stakeholders, Annual Research Confer-
ence of the South African Institute of Computer Scientists and Information Technologists on
Enablement through Technology (SAICSIT 2003), South Africa, 2003, pp. 37–47.
11. Object Management Group - Business Process Management Initiative: BPMN 1.0, Fi-
nal Adopted Specification, February 6, 2006: Final
Adopted BPMN 1-0 Spec 06-02-01.pdf, accessed at 2007-06-07.
12. Organization for the Advancement of Structured Information Standards: Web Services
Business Process Execution Language Version 2.0, Committee Draft, May 17, 2006:
May17.htm, accessed at 2007-06-07.