Methods for Service Identification: A Criteria-based

Literature Review

René Boerner and Matthias Goeken

Frankfurt School of Finance & Management

Sonnemannstrasse 9-11, 60314 Frankfurt am Main, Germany

Abstract. Business-driven identification of services is a precondition for a suc-

cessful implementation of service-oriented architectures (SOA). This paper

compares existing identification methods retrieved from related work and dis-

cusses the shortcomings. Finally, it proposes a process-oriented method of ser-

vice identification. This approach incorporates the business point of view, stra-

tegic and economic aspects as well as technical feasibility.

1 Service Identification

Service-orientation is a fundamentally new paradigm for the design of enterprise ar-

chitectures which spread substantially in the last couple of years (e.g. in the financial

services sector [1]). A growing number of authors have been looking at the identifica-

tion of services that are at the heart of service-oriented architectures (SOA). However,

there is lack of common understanding of what services are and which goals are to be

achieved. Due to this, existing approaches for service identification differ significant-

ly from one another. In section 2 this article presents a framework of several criteria

in order to compare various methods of service identification found in related litera-

ture. Strengths and weaknesses of existing approaches are discussed in section 3.

Based on the findings, requirements of a new methodology to identify services from a

business point of view are presented in section 4.

2 Comparison Criteria

In order to compare the approaches for the identification of services, a catalogue con-

sisting of several criteria is applied to give an overview of approaches currently dis-

cussed in related literature. Some criteria have already been used by other researchers;

others have been added by the author to complement the existing ones. For a better

understanding the criteria have been divided into six groups.

• Basic characteristics

• Business aspects

• Technical aspects

• Economic aspects

Boerner R. and Goeken M. (2009).

Methods for Service Identiﬁcation: A Criteria-based Literature Review.

In Proceedings of the 7th International Workshop on Modelling, Simulation, Veriﬁcation and Validation of Enterprise Information Systems, pages 76-84

DOI: 10.5220/0002193500760084

 SciTePress

• Method-engineering elements

• Principles of design science research

All criteria will be discussed in detail in the following sections.

2.1 Basic Characteristics

First, the basic principles of service-oriented architectures (SOA) are discussed. The

industry sector is important to understand the background of the approaches dis-

cussed. Identified similarities and differences might be grounded in the industry sec-

tor in which they are applied. There might be reasons why certain approaches are used

in one industry but not in others. Maybe some elements can be transferred successful-

ly from one industry sector to another. The understanding of services differs tremend-

ously among the approaches. Some consider a service comprehensively, i.e. it

represents a complete business process. On the other extreme authors tend to a

workflow-oriented view in which a (fully automated) service represents a single task.

However, all authors use a service hierarchy. This classification usually consists of

two or three levels [2, 3]. The differentiation of basic services and composed services

is a common feature although there are differences in detail. The right choice of gra-

nularity within an SOA is both critical and extremely difficult. In the following, gra-

nularity shall describe the functional scope of a service. Obviously, there is no silver

bullet for the right granularity. Fine-grained services can easily be reused in different

contexts (i.e. for many processes) but this can lead to higher complexity when orches-

trating the huge number of services. Coarse-grained services are able to fulfill more

complex tasks but they are less flexible and harder to reuse.

The underlying SOA paradigm affects the identification and specification of ser-

vices. It represents the idea of what an SOA actually is and what it can deliver. The

direction of the analysis (i.e. bottom-up or top-down) has an important effect on the

specification of services and is therefore another criterion. The authors use a range of

tools that can be subsumed into business process modeling (BPM), process decompo-

sition, domain decomposition, asset analysis and portfolio management [3]. Depend-

ing on the focus of the respective approach types of categorization vary. Whereas

technically-driven approaches categorize e.g. by implementation strategy, business-

driven approaches might differentiate by service consumer type (i.e. internal or exter-

nal).

2.2 Business Aspects

The business aspects are the second set of criteria to be discussed. First, consideration

of strategic aspects is very important because implementation of an SOA is not done

for its own sake but seeks tangible benefits for the company. Although the strategic

relevance might be less critical for the identification of services itself, it is crucial for

their design and subsequent sourcing strategies. A categorization by Allen therefore

differentiates between three types of services. Commodity services are stable, suffi-

ciently established services every market player must have. They are suitable for out-

sourcing and standardization. Territory services are fairly wide-spread but less stable

and usually represent business rules. Value-added services constitute the special value

of a company’s product or service in the market, i.e. a company’s core competence. It

is this highly innovative service that gives distinction to the company [4].

Both laws and regulations as well as internal rules often limit a service’s suitabili-

ty for outsourcing. Thus, the governance of services – well integrated into a compa-

ny’s IT governance framework - including legal compliance, internal policies and

service level agreements (SLA) has to be taken into account when services are identi-

fied and specified afterwards. SOAs are frequently mentioned as means for standardi-

zation and an increase of flexibility without noticing the ambivalence of these goals.

Most approaches only implicitly hint at which goal should be achieved. Another crite-

rion is the object supported by the service. This may be a complete value creating

process as well as one single task, i.e. a step in a workflow. Consideration of the SOA

lifecycle shall ensure the sustained maintenance of identified and implemented servic-

es as well as the intake of new services. In order to identify redundant services, exist-

ing ones have to be checked for functional similarity.

2.3 Technical Aspects

The way services are controlled belongs to the technical aspects of services. Basical-

ly, there is a differentiation between orchestration and choreography of services [5].

Some authors argue that orchestration implies a central instance that coordinates all

activities of a process [3]. The result of orchestrated services can itself be described as

a service. Choreography then means that services are called by other services and

there is not one steering unit. The sequence of services involved in a process is not

stored as metadata. However, authors such as Alonso et al. [6] talk about “distributed

orchestration” that does not imply a centralized coordinating instance. In this sense,

choreography deals with the specification of service coordination protocols. In the

following, methods for service identification will be compared on the basis of the

former mentioned definition.

Customer interaction is taken into account in different degrees by the approaches

presented. As far as services (and not tangible products) are concerned, the inclusion

of the external factor “customer” is essential. The same holds true for employee inte-

raction because it sets certain limits for standardization, automization and outsourc-

ing. Several IT criteria are especially important for the specification of previously

identified services. Thus, they are part of most of the presented approaches. The call

frequency of a service hints at its application. A high frequency can on the one hand

point to a service with a small scope of functionality that can therefore be used flexi-

bly in many business processes. On the other hand a sufficient standardization of

coarser grained services could be a reason for a high call frequency as well.

2.4 Economic Aspects

Value creation is the added value created through deployment of a service. The cus-

tomer has to be willing to pay for the result of a process, i.e. services should always

increase the value of a product. The degree of value creation depends on an effective

and efficient combination and coordination of resources [7] and is subject to an SOA

controlling. This could be implemented e.g. through a balanced scorecard [8]. Main-

tenance and operation costs correlate strongly with the complexity of an IT infra-

structure. An SOA can lead to a significant reduction of complexity. Moreover, well-

defined functions and interfaces contribute to the robustness of IT systems which in

turn lowers operation costs.

An intake of new services into the IT landscape of a company causes only little

testing effort for new functionality. Only interfaces of the newly implemented service

have to be tested because interactions of other services are untouched. Implementa-

tion of an SOA decreases vendor dependency because such an architecture is platform

independent. Firstly, this leads to immediate savings because the purchase of licenses

may be unnecessary when open source products can be used. Secondly, a lock in ef-

fect is avoided so the company is not bound to a vendor because of prohibitively high

swapping costs. Thirdly, web services can flexibly be used and increase the agility of

business processes. These web services can be purchased ad hoc from the cheapest

provider respectively.

Flexible orchestration of services enables a demand-oriented quality of service

level for products. Customers receive exactly the quality they request. Thus, customer

satisfaction is increased at the same time. This kind of orchestration allows for an in-

dividualization of products that leads to competitive advantages and thus is another

economic aspect. Specialization on core competencies plays an ever bigger role in to-

day’s competitive environment [9]. Identified service candidates can be classified on

the basis of their strategic importance. This leads to implications for further sourcing

decisions.

The product range can be widened by quickly recombining services on the basis

of existing core competencies and significantly enhance the time-to-market. Original-

ly internal services can be offered in the marketplace after being identified as services

with such potential. The acquisition of service users generates even more economies

of scale and leads to decreasing costs per unit. This, in turn, can boost the market

share through decreasing prices for the service. The necessary scalability is another

strength of SOAs. Due to its agility and flexibility SOAs can react quickly to chang-

ing customer requirements.

2.5 Method Engineering and Principles of Design Science Research

The task of method engineering is to guide the development of such methods in order

to guarantee a high quality. The most popular approaches in this field identify activi-

ties, roles, results, techniques and the sequence of activities as important components

of methods. Thus, a further set of criteria looks at how far these five components of

method engineering are incorporated into existing methods of service identification.

For the evaluation of these components a 5-level Likert scale that ranges from “--“

(not fulfilled) via “-“, “o“ and “+“ to “++“ (completely fulfilled) is applied.

The same scale is used to evaluate the application of Hevner et al.’s principles of

design science research [10]. Documentation, research rigor and evaluation are the

three principles discussed here. The documentation has to ensure that results are

communicated both technology-oriented as well as management-oriented. Research

rigor corresponds to the applied research methodologies (e.g. a sound literature

study). Evaluation is ought to guarantee quality and usability of the newly created me-

thod.

3 Strengths and Weaknesses of Existing Approaches

The methods found in related literature differ considerably in their methodological

approach. Advantages and disadvantages as well as a possible usability for an ade-

quate and process-oriented service identification are subject to discussion in the fol-

lowing.

Table 1 compares the five approaches presented above and facilitates the criteria

explained in section two. The most comprehensive understanding of services can be

found in Böhmann & Krcmar’s [11] approach. Their services (modules) represent

complete packages of service products offered to customers. Klose et al. [12] and Ar-

sanjani et al. [5] look at process chunks with a smaller scope of functionality. Still,

these chunks implement a complete and self-contained business functionality. The

change from an object-oriented view to a service-oriented view that is postulated by

many authors (e.g. [5]) is not to be found in Winkler’s approach [13]. Kohlmann &

Alt’s services support business processes, too. However, the scope of their services

differs significantly as far as functionality is concerned. Thus, a three level hierarchy

of basis services, composed services and process services is used to classify the types

of services. Whereas Böhmann & Krcmar do without any hierarchy, all other authors

use a two level structure.

Granularity of services differs immensely among the compared methods. Klose et

al. describe mainly composed services. Böhmann & Krcmar and Arsanjani et al. ra-

ther look at more encompassing process services. On the contrary, Winkler uses very

fine grained, elemental services and thus is fairly close to an object-oriented ap-

proach. Kohlmann & Alt vary the granularity of services depending on the situation.

The SOA paradigm of all five methods is an architectural concept. Actually, an inter-

pretation of SOA as middleware (e.g. only to integrate legacy systems) makes no

sense in the context of business-driven service identification. The direction of the

analysis is usually hybrid, i.e. a top-down approach (which is the focus) is comple-

mented by a bottom-up analysis of existing infrastructure. Only Winkler solely uses a

top-down approach. The most common tools that are used are BPM and domain de-

composition. Different types of categorization are facilitated to classify services in

various dimensions. Particularly Arsanjani et al. look at services from different points

of view. The role within a business model distinguishes basic services from process

services. Consumer type categorizes services in internally used ones and those (also)

used by partners and customers. The implementation strategy marks composed ser-

vices or externally sourced ones. The consumer type is a focus in Klose et al.’s and

Böhmann & Krcmar’s approaches because customer integration and interaction are

crucial. Only Klose et al. fail to discuss implementation strategies.

A consideration of strategic aspects is omitted from Winkler’s method. Klose et

al. rarely mention these aspects. Still, their thoughts on line of visibility and line of in-

teraction somehow hint at a link to strategic aspects. Arsanjani et al. advocate the use

of reference models and best practices obtained from peer groups. They consider the

sourcing potential of identified service candidates. Böhmann & Krcmar examine

strategic implications of an SOA and belonging services in much more detail. Threats

and opportunities as well as sourcing strategies are part of their identification method.

Similarly, Kohlmann & Alt discuss these strategies as well as cuts in processes in in-

ter-organizational networks. Legal compliance plays a role when customer data is af-

fected. Klose et al. deal with the sensitivity of such data when it comes to the line

Table 1. Comparison of service identification methods.

Klose et al. (2007)

Böhmann & Krcmar

(2005) Winkler (2007) Arsanjani et al. (2008) Kohlmann & Alt (2007)

Basic characteristics

Industry sector Production IT services Financial services Financial services Financial services

Understanding of

services

Business process

oriented

As module, very

comprehensive Object oriented

Business process

oriented

Business process

oriented

Service hierarchy

2 levels, elemental

and composed service Process service

2 levels, basic and

composed service

2 levels, elemental

and composed service

3 levels, process

service, rule service,

entity service

Granularity Middle Coarse Fine Coarse From coarse to fine

SOA pradigm

rchitectural concept

Direction of analysis Hybrid

Hybrid with bottom up

tendency Top down

Hybrid with top down

focus Hybrid

"Tools"

Decomposition of

business processes

(with BPM) and SOA

principles

sset analysis

Decomposition of

business processes

Goal service modeling,

domain

decomposition, asset

analysis BPM, asset analysis

Types of

categorization Consumer type

Consumer type,

implementation

strategy

Implementation

strategy

Business model role,

consumer type,

implementation

strategy

Role in business

model, implementation

strategy

Business aspects

Consideration of

strategic aspects

Line of interaction &

line of visibility

Threats and

opportunities of

modular service

architect., sourcing not considered

Reference models,

best practices,

sourcing strategies

Sourcing strategies,

inter-organizational

cuts

SOA governance

Legal requirements

concern. customer

data, internal policies

considered

Internal policies

considered, SLAs are

indiv. defined not considered

"Rules and policy

analysis" within

process modeling

Customer data

remains in own

company, naming of

services

Goal Flexibilization Flexibilization Standardization Flexibilization Not clear

Supported object Task Business process Task Task Business process

Functional similarity

Consideration of

industry standards Not considered Not considered

Self similar fractals,

industry standards

Functional and

semantic similarity

Technical aspects

Orchestration vs.

choreography Orchestration Orchestration Not clear Not clear Orchestration

Customer interaction

Line of interaction &

line of visibility

Customer specific

configuration, line of

visibility Not considered Not considered Not considered

Employee interaction

Automatic, dialogue,

manual Not considered Not considered Not considered Not considered

Criteria of information

technology

Design principles for

SOA

Reusability,

standardization,

independence

Reusability,

redundancy, frequency Reusability, flexibility Reusability

Call frequency

Not considered Not considered Calls per time Not considered Not considered

Economic aspects

Value creation, SOA

controlling Not considered Not considered Not considered Not considered Not considered

Maintenance and

operation costs Not considered

Utilization of common

resources Not considered

Elimination of

redundancies Not considered

Testing effort for new

functionality Not considered Not considered Not considered Not considered Not considered

Vendor dependency Not considered Not considered Not considered Not considered Not considered

Demand-oriented QoS

levels Not considered

Within performance

and design analysis Not considered Not considered Not considered

Customer satisfaction Not considered Not considered Not considered Not considered Not considered

Individualisation of

products/services Not considered

Included in goal

definition Not considered Reusable components Not considered

Specialisation in core

competences Not considered

External sourcing

options Not considered Not considered Sourcing models

Product range / Time-

to-Market Not considered

Included in goal

definition Not considered Not considered Not considered

Internal services for

external customers Not considered Not considered Not considered Not considered Not considered

Scalabilit

Not considered Not considered Not considered Not considered Not considered

Components of

method engineering

Activities ++ ++ ++ ++ +

(SOA-)Roles -- -- -- o --

Results +++++++

Techniques + o + ++ -

Sequence of activities Sequential Sequential Sequential Iterative, fractal

Sequential, iterative

where applicable

Principles of design

science research

Documentation+++++++o

Research rigour ++ ++ o - +

Method evaluation ++ ++ - + +

of visibility. Kohlmann & Alt also point out that customer data must remain within

the company while outsourcing processes. Internal policies are only incorporated by

Arsanjani et al. and Kohlmann & Alt. The latter for instance make the point of consis-

tent naming of service candidates. Solely Böhmann & Krcmar mention service level

agreements and stress the necessity of individual definitions.

Goal of the implementaion of an SOA in Winkler’s method is standardization. In

Kohlmann & Alt’s approach there is no clear goal to be identified. The other three

methods clearly aim at a flexibilization. In the approaches by Böhmann & Krcmar

and Kohlmann & Alt business processes are the supported object. The other methods

tend to support tasks. Apart from Arsanjani et al., who present a fractal model for ser-

vice-oriented software development, the SOA lifecycle is ignored by other authors.

Functional similarities are not discussed by Böhmann & Krcmar and Winkler. In con-

trast, Kohlmann & Alt discuss not only functional but also semantic similarities. Ar-

sanjani et al. use the self-similarity of fractals for service-oriented software develop-

ment. Apart from Winkler and Arsanjani et al.’s methods that cannot be classified

unambiguously, all authors imply an orchestration of services by a central instance.

Customer interaction is a focus in Klose et al.’s and Böhmann & Krcmar’s approach

although the former originates from a production company. The huge importance of

the “customer factor” in service industries is not reflected at all in the three other ap-

proaches. Employee interaction is only discussed by Klose et al. They differentiate

between automated, semi-automated and manually conducted services. Looking at IT

criteria the nomination of reusability stands out in all approaches. This is not surpris-

ing considering the prominence of it in recent SOA literature. Klose et al. use a com-

prehensive catalogue of design principles of an SOA. Instead, only Winkler focuses

on the call frequency and redundancy.

The economic aspects of services are completely out of scope in Klose et al.’s and

Winkler’s approaches. With the notable exception of specialization on core compe-

tencies there is no discussion of economic aspects in Kohlmann & Alt’s method.

Maintenance and operation costs are addressed by Böhmann & Krcmar and Arsanjani

et al. The utilization of common resources through reduction of redundancies and

multiple calls by the implementation of services is brought forward in both approach-

es. The only authors considering a demand-oriented QoS level are Böhmann &

Krcmar with their performance and design analysis. This is plausible because their

stakeholder-based approach demands an integration of customers. Individualization of

products and services is supported by Böhmann & Krcmar’s modularization and by

the usage of reusable components (Arsanjani et al.). Specialization on core competen-

cies is also a postulation in Böhmann & Krcmar’s method. Within their goal defini-

tion they consider an increase of the product range and the time-to-market of new

products. All other economic aspects, namely value creation, testing effort for new

functionality, vendor dependency, customer satisfaction, internal services offered to

external customers, scalability and SOA controlling are not considered in any of the

approaches.

As far as components of method engineering are concerned all compared ap-

proaches do fairly well regarding the described activities. Results and techniques are

usually explained in a satisfactory way. Solely roles are not explained in any of the

approaches. Arsanjani et al. – who mention the components of method engineering

explicitly – hint at the existence of roles in their method but do without further detail-

ing. The sequence of activities is usually sequential. Kohlmann & Alt allow iteration

at certain points. Exceptionally, Arsanjani et al. present an iterative, fractal procedure.

Based on three selected guidelines for design science research [10] especially Klose

et al. and Böhmann & Krcmar excel with their methods. Both approaches comply en-

tirely with the guidelines concerning documentation, research rigor and evaluation.

Winkler particularly misses an evaluation of her method whereas a lack of research

rigor is the weakest point in Arsanjani et al.’s approach. Kohlmann & Alt show

weaknesses in both documentation and research rigor but have a clear advantage in

evaluation though.

4 Conclusions and Further Research: POSI – A Method for

Process-Oriented Service Identification

As shown in previous sections approaches for service identification differ in many

ways. However, a comparison on the basis of several criteria also identified commo-

nalities both in the existence and the absence of certain aspects. Because business-

driven service identification is crucial to a successful SOA implementation a new me-

thod for process-oriented service identification (POSI) has to use the strengths of the

compared methods and resolve relevant flaws. Thus, aspects that are vital for the de-

sign of POSI are to be discussed in the following.

Business processes identified by techniques such as BPM have to be the founda-

tion of the new method. However, no SOA project will create an IT infrastructure

from scratch. Therefore, given factors such as existing hardware and software have to

be considered. A top-down approach that identifies services with tools like BPM or

domain decomposition has to be complemented by a bottom-up analysis to guarantee

a successful technical implementation.

The method to be developed has to be configurable in so far that depending on the

user’s preferences either standardization or flexibilization are the focus of the identifi-

cation process. Especially the level of composed services is important in this context.

Basic services, e.g. retrieval or alteration of data, can only be subject to standardiza-

tion. In contrast, process services should be flexible in most cases. However, looking

at composed services the goal may differ case by case because the complexity of such

services varies depending on the situation.

Composed services will most likely be subject to sourcing decisions because nei-

ther whole process services (which constitute the existence of an enterprise) nor basic

services (that are too small) are suitable for outsourcing. Table 1 shows that economic

aspects in particular find little or none adherence in existing methods. For this reason,

POSI has to combine the identification of services with the consideration of these as-

pects. Especially functional similarities shall serve as a basis for identifying standar-

dization potentials. Subsequently, sourcing strategies can be evaluated.

Notably in the service sector the consideration of customer interaction at the run-

time of services is indispensable. A selection of critical factors of SOA design prin-

ciples that determine a high-quality service identification ensures the quality of the

method. Summing up, a new method for process-driven service identification has to

focus on the following aspects:

• Service identification based on BPM complemented by a bottom-up analysis

• Discovery of functional similarities to evaluate standardization potential

• Customer interaction

• Configuration regarding standardization and flexibilization

• Consideration of economic aspects

In order to comply with the formal requirements of method engineering, activities,

roles, results and techniques have to be documented. The striking absence of roles in

all presented methods is a major flaw. Experience shows that BPM is not always con-

ducted by business units but by IT departments. Consequently, a new method has to

manage rules explicitly. To meet academic standards, development of POSI will be

based on Hevner et al.’s principles of design science research.

References

1. Schulte, S., N. Repp, J. Eckert , R. Steinmetz: Service-oriented Architectures - Status Quo

and Prospects for the German Banking Industry. International journal of interoperability in

business information systems. Vol. 3 (2008) 9-31

2. Erl, T.: Service-Oriented Architecture - A Field Guide to Integrating XML and Web

Services. Prentice Hall, Upper Saddle River, NJ (2004)

3. Josuttis, N.: SOA in der Praxis - System-Design für verteilte Geschäftsprozesse. 1. ed.

dpunkt.verlag, Heidelberg (2008)

4. Allen, P.: Service Orientation: Winning Strategies and Best Practices. Cambridge

University Press, Cambridge (2006)

5. Arsanjani, A., S. Ghosh, A. Allam, T. Abdollah, S. Ganapathy , K. Holley: SOMA: A

method for developing service-oriented solutions. IMB Systems Journal. Vol. 47 (2008)

377-396

6. Alonso, G., F. Casati, H. Kuno , V. Machiraju: Web Services. Springer, Berlin, Heidelberg

(2004)

7. Roth, R.: Wertschöpfungsorientierter Serviceentwurf. In: SOA - Expertenwissen, G. Starke

and S. Tilkov, Editors, dpunkt.verlag: Heidelberg (2007) 87-109

8. Kaplan, R.S. , D.P. Norton: The Balanced Scorecard - Measures that Drive Performance.

Harvard Business Review. Vol. 70 (1992) 71-79

9. Prahalad, C.K. , G. Hamel: The Core Competence of the Corporation. Harvard Business

Review. Vol. 68 (1990) 79-91

10. Hevner, A.R., S.T. March, J. Park , S. Ram: Design Science In Information Systems

Research. MIS Quarterly. Vol. 28 (2004) 75-105

11. Böhmann, T. , H. Krcmar: Modularisierung: Grundlagen und Anwendung bei IT-

Dienstleistungen. In: Konzepte für das Service Engineering. Modularisierung,

Prozessgestaltung und Produktivitätsmanagement, T. Herrmann, U. Kleinbeck, and H.

Krcmar, Editors, Physica: Heidelberg (2005) 45-83

12. Klose, K., R. Knackstedt , D. Beverungen: Identification of Services - A Stakeholder-Based

Approach to SOA Development and Its Application in the Area of Production Planning. In:

ECIS'07: Proceedings of the 15th European Conference on Information Systems. St.

Gallen, Switzerland (2007)

13. Winkler, V.: Identifikation und Gestaltung von Services. Vorgehen und beispielhafte

Anwendung im Finanzdienstleistungsbereich. Wirtschaftsinformatik. Vol. 49 (2007) 257-

266