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-speciﬁc 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 speciﬁc systems development method-

ologies do not sufﬁciently 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

 SciTePress

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 ﬁnancial 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 fulﬁll the needs of a particular enterprise.

The rest of this paper is structured as follows. In the next section, we will pro-

vide deﬁnitions 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 Deﬁnitions

2.1 Services and Business Processes

As already discussed in the introduction, we deﬁne services as self-contained encap-

sulations of domain-speciﬁc 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 deﬁnition 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 deﬁnition 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 speciﬁcation of

business components by Ackermann et al. [8], as well as from our experience in SOA

projects.

Of further importance is the documentation of a service. It is the foundation for

all the aspects mentioned above - without a sufﬁciently 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

integrated.

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 speciﬁed 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 ﬁne granularity offer base functionalities useful in various

scenarios.

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-

ality.

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

exception.

Degree of coupling Speciﬁes 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 ﬂy 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 identiﬁable 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

knowledge.

4.1 Prerequisites for the Approach

In order to apply the phases of the service inventory process to a given situation, we

need a sufﬁciently 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 ﬁnance and telecommunications sector,

we observed that the following information about a service is usually available for an

assessment:

– 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.

– Classiﬁcation 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 ﬁrst present a generic systems de-

velopment process in which the service inventory can be integrated. For this purpose,

we analyzed different vendor speciﬁc 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 ﬁve core phases, which all are

sub-processes themselves (see Figure 1). For simpliﬁcation, 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

detail.

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

planning

Analysis

Design of services

and service

compositions

Implementation

Service operation

and management

+ + +

Analysis

Business

requirements

analysis

Service inventory

Business process

analysis

Fig.1. Generic systems development process for the implementation of SOA.

Service inventory

Scope deﬁnition

Completion of the

criteria catalog

Analysis of

deviations

Aggregation of

ﬁndings

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 ﬁrm 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 ﬁrm, which classiﬁes 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 preconﬁgured tests of different duration. Currently, the

approach is used in ﬁrst 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

ﬁrst 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 identiﬁed. The identiﬁcation as well as the following sketch-

ing of a solution based on SOA is done on a high level, which is not

sufﬁcient 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., stafﬁng, 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

management

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 deﬁnition In this initial phase, the aims and objectives of the service inventory have

to be deﬁned 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

fulﬁll the goals of the targeted project, have to be speciﬁed 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 deﬁned. Finally, it has to be

speciﬁed how many deviations of what severity lead to negative rating of

the service for the project (“deﬁnition 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 classiﬁed into

the three types “minimal”, “moderate”, and “critical”, based on the deﬁ-

nitions provided in the initial phase.

Aggregation of ﬁndings In the ﬁnal 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 classiﬁed 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 classiﬁcation 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 classiﬁed as critical. Finally, the singular ratings of the service have to be aggregated.

One single critical rating results in an overall classiﬁcation 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 ﬁndings 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 ﬁt 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 speciﬁc processes coping with the analysis

and integration of existing services. All of the vendor speciﬁc 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 speciﬁcation of services

itself. We will evaluate existing speciﬁcation 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.

Acknowledgements

The work is supported in part by the E-Finance Lab e.V., Frankfurt am Main, Germany.

References

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

1613-0073, http://ceur-ws.org/Vol-234/paper2.pdf.

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 Workﬂows, 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 Speciﬁcation of Business Components,

Gesellschaft f

ur Informatik (German Informatics Society), Working group 5.10.3, Augsburg,

Germany, 2002: http://www.fachkomponenten.de, 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 Speciﬁcation, February 6, 2006: http://www.bpmn.org/Documents/OMG 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:

http://www.oasis-open.org/committees/download.php/18714/wsbpel-speciﬁcation-draft-

May17.htm, accessed at 2007-06-07.