Keywords

1 Introduction

The enterprise architecture seeks to bring together the Information Technologies (it) layer and the business layer in organizations [1]. This requires an alignment of the vision, the strategy and the business processes of an organization with its Information System (is) supporting its business activities. In this paper, we focus on organizations creating and selling it services, whether it is a company or an internal it department of a company whose the core business is not selling it services. Of course, this narrow the scope covered regarding the business layer. This decision is motivated by the fact that many it organizations aim at becoming service-oriented, i.e., applying service-oriented approaches both at the it and business layers [2, 3]. They are called service-oriented organizations by Gartner [4].

Regarding the architecture of their is, several it organizations follow the service-oriented paradigm. The latter is “a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.” [5]. It leads to the implementation of Service-oriented Systems (sos). An sos combines the computational means to manage distributed and independent software functionalities named services which perform the functionalities required by the stakeholders [6]. The creation and the management of an sos require to follow a Service-oriented Software Engineering (sose) model. As with the Traditional Software Engineering (tse), sose is the application of a systematic and structured approach to the analysis, the design, the conception, the implementation, the operation and the maintenance of soss. Unlike tse, sose has to organize the creation, the publication, the discovery, the composition, the evaluation and the monitoring of services [7]. However, “the existing sose methodologies focus mainly on the design and analysis part of the sose process, but pay little or not sufficient attention to the constructing, delivering and management part” [8]. This lack of organizational models for the management of the sos creation is also underlined in [9]: its authors claim for more abstractions and management methods during the implementation and the composition of services. Therefore, aligning the sos creation with the management of the it organization using this sos becomes one key issue.

In the literature, some works tackle this problem by focusing on the company governance aspects. The governance has to ensure that the stakeholders’ point of view is taken into account to determine the organization vision and objectives, which are then monitored and measured [10]. At a lower level in the organization, the management refers to the planning, the building and the monitoring of the activities which should be aligned with the vision and the enterprise objectives set by the governance [10]. Although the organization governance is needed, a process alignment at the management level should help the it teams and leaders in charge of the sos implementation to coordinate their work with the rest of the it organization and its processes, and conversely.

In order to reach this objective, we identify and analyse the relations between the steps of a detailed version of the Papazoglou’s service-oriented design and development methodology [11] –we name it the detailed service-oriented design and development methodology (dsddm)– with the itil v.3 processes. itil v.3 is an Information Technology Service Management (itsm) framework composed of organizational best practices for providing it services. The result of this work is an alignment between the business layer of an it organization –represented by the itil v.3 best practices– and its it layer managing an sos –corresponding to dsddm. This work also contributes to solve an issue left open in itil v.3 [12, Sect. 3.10]: How to integrate the itil framework with a service implementation methodology? This paper details how the itil v.3 framework can be aligned with a service implementation model which can be used to create and to compose services in an sos.

The rest of this paper is organized as follows. Firstly, the lack of relations between itil v.3 and the service creation in an sos is analysed in Sect. 2 (in which we also discuss the related work). Then, in Sect. 3, the service-oriented design and development methodology of Papazoglou is detailed in order to become its detailed version abbreviated by dsddm. This enables to align the dsddm steps with the itil v.3 processes (Sect. 4). The conclusion and future work end this paper (Sect. 5). Note that this publication is a shortened version of our work; see the technical paper [13] for a more complete and detail version of this paper.

2 An Analysis of the Current Identified Relations Between Service Implementation Methodologies and ITIL v.\(3\)

In this section, we first describe itil v.3 and the reference service-oriented design and development methodology (Sect. 2.1). Then, we pinpoint some of the issues coming from the lack of identified relations between them (Sect. 2.2). We finally analyse the related work in order to discuss the already proposed relations in the literature (Sect. 2.3).

Fig. 1.
figure 1

itil v.3 life cycle (based on an official illustration of itil [14])

Full size image

2.1 A Brief Introduction to ITIL v.\(3\) and to the Reference Service-Oriented Design and Development Methodology

The third version of itil, which has been revised in \(2011\), is the organizational framework used in the scope of this work. It is indeed one of the most used itsm framework in the it industry [15]. An itsm framework provides best practices and recommendations to manage organizations providing it services. One of the main itil objectives is to integrate the requirements of the customers and the users into many activities of it organizations. The latter have to provide value to these customers and users in their own business processes.

itil v.3 is structured into five phases: Service Strategy [14], Service Design [12], Service Transition [16], Service Operation [17] and Continual Service Improvement [18]. Each of these phases is composed of processes –the latter are written down and associated to their phases in Fig. 1. For more information on itil v.3, see [12, 14, 16–18] or the technical paper [13]. itil recommends, i.a., “that business processes and solutions should be designed and developed using a service-oriented architecture approach” [12, Sect. 3.10]. However, the relations between itil and a service implementation methodology are not detailed nor identified in the official itil publications. Some initiatives in the scientific literature address both the service-oriented paradigm and itil, but they mainly discuss the governance issue. In the scope of this work, we only focus on the management level.

Concerning the sose methodology, we refer to the one of Papazoglou called the service-oriented design and development methodology [11]. The main reason of this choice lies in its good evaluations compared to similar initiatives [8]. This methodology is his answer to the need for specific tools and methods taking into account the distinctive features of the service-oriented computing. The phases proposed are the Planning, the Analysis & Design, the Construction & Testing, the Provisioning, the Deployment and the Execution & Monitoring. For more information on this methodology, see [11] or the technical paper [13].

The Papazoglou’s methodology is mainly composed of guidelines to specify, build and compose the services. One of the primary objectives is to support dynamic business processes with an is. However, current companies also require a global view on the management of their services, i.e., they want to adopt an itsm framework [19] such as itil. While the service-oriented design and development methodology is more about the implementation of services, the reusability and the composability, itil focuses on the organizational processes to follow in order to deliver value to the customers and users of services by applying a proper service delivery and support. Even though the service-oriented paradigm and itil seem to be complementary in an organization, the combined use of itil and the service-oriented design and development methodology raises several problems and issues. The main ones are discussed hereafter in Sect. 2.2. Then, this paper brings some solutions in Sect. 4.

2.2 Main Issues When Comparing ITIL v.3 and the Service-Oriented Design and Development Methodology

The first issue is related to the service notion which is differently comprehended. In itil, a service, called an it service, is defined as the “means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks” [14]. Although the definition of the service concept in the service-oriented paradigm varies somewhat, the one proposed by Papazoglou is often cited: a service “is a self-describing, self-contained software module available via a network [...] which completes tasks, solves problems, or conducts transactions on behalf of a user or application. [...] Services constitute a distributed computer infrastructure made up of many different interacting application modules trying to communicate [...] to virtually form a single logical system” [20, Chap. 1]. Other concepts share the same problem such as the notion of sla. This will be discussed in Sect. 4.

A second observation concerns the lack of understanding between the management of organizations and the technical teams in charge of the it. From one side, itil helps to establish, structure and improve the management of organizations. From the other side, the service-oriented paradigm mainly focuses on the is structure and its technical management. Both of these two layers recommend to adopt a service-orientation. However, how to combine them in order to create a full service-orientation in organizations is not clear [21]. As an example, we can mention the notion of service registry in an sos, and the notion of service portfolio and service catalogue in itil. How to associate these related notions in order to use them as a whole in the organization? A second example lies in the possible confusion between the notion of service design package in itil and the notion of service description used in the service-oriented computing.

Thirdly, the service life cycle has a different structure. In itil, the Continual Service Improvement phase organizes the improvement of the service solutions and processes based on, i.a., the changing and new business needs. In an sos, the service monitoring phase focuses on the quality measurement of the service characteristics [11]. Therefore, using itil to manage the services of an sos should help to improve the services by taking into account the new and changing business requirements.

2.3 Related Work

In the literature, the relations proposed between itil and the service-oriented paradigm are often based on the organizational concepts of itil, and on the sos concepts and implementation steps. First initiatives combining the sos with management practices and organizational aspects focus on sose (see [22] for more details). In the scope of this work, we only consider the relations established at a management level between itil best practices and sos implementation activities of it organizations.

In [1], the authors propose a meta model of an enterprise service based on the service concept of itil v.2 and of the service-oriented paradigm. They do not tackle the possible relations between the itil processes and the activities of the sos implementation and composition. Other works such as [23] use itil v.3 concepts to build a service-oriented and organizational framework. But they do not align the processes of itil with processes or activities of an sos implementation and composition methodology.

In [24], the author favours the use of an soa integrated with itil in order to improve the agility of it in organizations. This integration helps to relate the management of it service with their supportive technical layers, which are assimilated to the soa components. They use the second version of itil –the third one was not yet finished when the work has been published. Most of the itil v.2 processes are related to the soa concepts. A particular attention is paid to the cmdb management and the operational activities, i.e., the management of the services configuration, the incidents, the requests and the problems. A second work shares a similar objective, i.e., improving the it agility by combining an soa and itil [25]. Its authors claim for a clear distinction between the soa concepts and the itil concepts, although they underline some connections between these two organizational domains.

Compared to [24, 25], our work goes one step further by aligning the steps of a service-oriented design and development methodology and the itil processes. Of course, the scope of our work is narrowed since we only focus on the creation and composition of services. The operational management of the built services is left for future work. A third work is very close to this idea. In [26], the authors describe the technical platform used by ibm to manage the services in an sos. They clearly refer to itil best practices and principles. Of course, the use of the alignment between the sos components and itil is only possible if the ibm software tools are purchased. Moreover, these relations are not publicly described neither justified.

Other works propose to associate the service-oriented paradigm with an organizational framework which is not itil. For instance, Li et al. design a high level organizational framework and structure which are then compared and aligned to the soa implementation [27]. They consider that the soa is a mirror of real organizations. This choice is motivated by the need for a technology independent framework. We meet this requirement by using itil as the reference organizational framework which is independent of any specific technologies. The detailed description of itil is an advantage compared to the use of a high level and less described organizational framework. A second example is the Service-Oriented Analysis and Design method (soad) [28]. The authors cover the business and organizational layers in their model, but without reference to a detailed organizational framework.

Fig. 2.
figure 2

Illustration of the detailed service-oriented design and development methodology

Full size image

3 Foundations of the Detailed Service-Oriented Design and Development Methodology

In this section, we first detail the steps of the service-oriented design and development methodology in order to align them with the itil v.3 processes (the dsddm is depicted in Fig. 2). To do this, we use the structure of the Spiral Model [29, 30]. This model helps to answer the two following questions: What are the objectives and the output of the current stage? and After this stage, what should we do? It does not aim at explaining how each stage can be completed. itil v.3 solves this issue once the alignment described. The structure of the Spiral Model used is close to the initial model proposed by Boehm [29] and the revised version [30]. Nevertheless, we lightly adapt it for the service-oriented paradigm –the flexibility was one of its main strengths [30]. The structure used is composed of five parts numbered with Roman numerals (see Fig. 2). Note, before the beginning of each cycle, its planning is always carried out by placing the tasks on a timeline, identifying the resources and then allocating them to the tasks.

  1. I

    People identification & communication: The steps included in this part focus on the stakeholders. The latter are first identified. Based on an efficient communication framework, they are kept informed about the progress of the projects.

  2. II

    Determining objectives, alternatives & constraints: This section facilitates the establishment of the vision and the direction of the project by determining the objectives, scope and constraints of the project. It also helps to solve design conflicts after their communication to the stakeholders.

  3. III

    Risks analysis: This part focuses on the risk management. Once the vision determined and the choices made, their underlying risks are identified and analyzed. A good risks management will help to achieve the steps of the next section.

  4. IV

    s o s conception & development: The steps of this section help to define, design and implement the services.

  5. V

    Solution evaluation & verification: This fifth and last section includes the steps related to the output evaluation of each cycle.

4 Alignment of the DSDDM Steps with the ITIL v.\(3\) Processes

The detailed model of Papazoglou’s methodology –abbreviated by dsddm– is the process leading to the analysis, the design, the implementation and the composition of services. It is depicted in Fig. 2. This model should be covered for each required business service –a business service is a logical part of an sos aligned on an activity of a business process which represents some required business functionalities [31]. In the scope this work, another important concept is the notion of infrastructure service. It is defined as a container associated with the service management and monitoring infrastructure that encapsulates computational resources [31]. Once combined, these infrastructure services can provide the business functionalities required by the stakeholders. In itil, the notion of it service –defined in Sect. 2.2– is close to the notion of business service. Indeed, supporting the functionalities of the business processes should provide some value to the stakeholders by facilitating their business outcomes. Moreover, the use of a service provided by an sos allows the transfer of some costs and risks from the stakeholders to the technical staff maintaining the sos. In the definition of an it service, the term “means” refers to, i.a., the infrastructure services supporting the business service. We recommend to only use the notion of it service and infrastructure service given that the notion of business service is redundant with the notion of it service.

Table 1. Alignment of the first dsddm cycle with itil v. \(3\)
Full size table
Table 2. Alignment of the second dsddm cycle with itil v. \(3\)
Full size table
Table 3. Alignment of the third dsddm cycle with itil v. \(3\)
Full size table

The next three sections (Sects. 4.1 to 4.3) respectively detail the first, the second and the third cycle of the dsddm spiral model –illustrated in Fig. 2– along with the justified relations of each dsddm step with the corresponding itil v.3 processes. Tables 1, 2 and 3 summarize this alignment.

Fig. 3.
figure 3

Alignment between the first dsddm cycle and the itil v. \(3\) processes

Full size image

4.1 Description and Alignment of the First DSDDM Cycle

The first dsddm cycle focuses on the analysis of the business environment –i.e., the analysis of the stakeholders, their requirements, the business risks and the business constraints– that the future it service will support. Its alignment with itil v.3 is summarized in Table 1 and illustrated in Fig. 3. The illustrations of the alignment of the two other dsddm cycles with itil v.3 processes are available in [13] or by sending an email to the first author.

Before the first step numbered 1.1, the whole cycle is organized, i.e., planning and structuring the tasks, allocating the resources needed and monitoring the achievement of each step (see “Management of the next cycle plan” in Fig. 2). Regarding the alignment with itil v.3, this planning work has to be achieved in accordance with the company strategy (defined thanks to the itil v.3 process 1.a stm). These activities leading to the description of the business functionalities of the future service are detailed hereafter.

1.1 Identify stakeholders and their business environment: This step aims at having a first contact with the stakeholders once they are identified (related to 1.e brm). One of the key aspects to analyse is their business context in order to understand what their job is and how they work (related to 1.d dem and 1.e brm).

1.2 Identify the stakeholders’ objectives, their business needs and business constraints: This step helps to clarify the business environment of the stakeholders as well as their requirements and business constraints (related to 1.e brm). The identification and the analysis of the business constraints should help to design a feasible service solution which complies with the strategy of the service provider (related to 1.a stm).

1.3 Identify and evaluate the business risks: This step focuses on the analysis of the risks due to the future use of an it service and its possible consequences on the business processes, including the financial considerations (related to 1.b spm and 1.c fin).

1.4 Describe the business functionalities to support: Based on the stakeholders’ objectives, the business constraints and the business risks analysis (managed by the process 1.b spm), this step leads to the business design of the future service (related to 1.d dem).

1.5 Evaluate the business functionalities towards the business needs and constraints, and the s o s principles: This step ends the first dsddm cycle. The quality of the it service specifications is evaluated by comparing the specifications of the it service with the business needs expressed by the stakeholders (related to 1.b spm) and the sos principles (managed by the process 1.a stm).

4.2 Description and Alignment of the Second DSDDM Cycle

The second cycle focuses on the analysis of the technical alternatives that match the business functionalities described and validated during the first cycle. This consists in analyzing the implementation alternatives and the risks of these alternatives, and in specifying the future service. Its alignment with itil v.3 is summarized in Table 2. Note, in case of service reuse –i.e., the business needs can already be satisfied by an existing (composed) service–, a part of the second and the third cycle is skipped. Indeed, the flow to follow between the steps \(2.3\) and \(2.4\) depends on the alternative chosen: reused service or new service implementation (see Fig. 2).

First of all, the activities of the second cycle are organized based on the results obtained at the end of the first cycle. This lies in planning and structuring the tasks, allocating the resources and monitoring the achievement of each step. The itil process 2.a des is in charge of the organization of the service design activities which lead to the creation of the service design package. These activities are detailed hereafter.

2.1 Communicate the description of the business functionalities to the stakeholders: The evaluation achieved during the step \(1.5\) as well as the specifications of the future service are communicated to the stakeholders, including the it staff (related to 1.e brm).

2.2 Find and evaluate the alternatives (reuse, build or transform from a legacy application): Based on the exchanged information during the previous step, the possible solutions are considered (related to 2.b sca). They are three alternatives: (i) service reuse –an existing service will be used; it can be provided by the existing sos or by an external service provider– (ii) building of the service from scratch –the service functionalities will be built from scratch, and/or existing services will be composed to support the functionalities needed to provide the it service specifications– or (iii) building of the service from a legacy application –the legacy software component will be encapsulated.

2.3 Identify and evaluate the technical risks: This step aims at identifying and evaluating the risks raised by the alternative previously chosen. These risks are associated to the existing iss, the other ongoing implementation projects and the other existing services in use (related to 2.d avm, 2.e cap, 2.f sco and 2.g ism). This technical risk analysis completes the business risk analysis carried out during step 1.3.

2.4 Specify the infrastructure service: The analysts have to specify the it service functionality(ies) in order to implement the corresponding infrastructure service during the subsequent steps (related to 2.d avm, 2.e cap, 2.f sco, 2.g ism and 2.h sup).

2.5 Check the infrastructure service specifications towards the described business functionalities and the s o s principles: During this step, the specifications of the infrastructure service are compared to the it service description (related to 2.c slm).

4.3 Description and Alignment of the Third DSDDM Cycle

The third cycle focuses on the implementation and the deployment of the specified infrastructure service, i.e., the evaluation of the technical choices, the management of the implementation and deployment risks, the coding of the service, the publication of its description and its orchestration. The alignment of the third dsddm cycle with itil v.3 is summarized in Table 3.

First of all, the activities of the third cycle are organized based on the results of the second cycle. This means planning and structuring the tasks, allocating the resources needed and monitoring the achievement of each next step. The itil process 3.a tps is in charge of this work, which is detailed in the rest of this section.

3.1 Communicate the infrastructure service specifications to developers: The validated specifications of the infrastructure service are communicated to the it staff in charge of its implementation and publication (related to 3.a tps).

3.2 Evaluate the technical implementation alternatives: The technical choices are made after their evaluation and comparison (related to 3.b cha, 3.c sac and 3.e svt). This step should also take into account the constraints due to the use of legacy software component(s) to build the new infrastructure service (related to 3.c sac).

3.3 Evaluate the risks due to the implementation and deployment of the new service: This step focuses on the identification and on the management of the technical risks raised by the implementation of a new service in the sos (related to 3.a tps and 3.f che).

3.4 Implement and/or compose the service and deploy it: During this step, the infrastructure service will be implemented according to its specifications (related to 3.b cha, 3.c sac and 3.f che). This new service is, eventually, composed with other existing services. Then, this new service is deployed (related to 3.d rdm).

3.5 Publish the description of the service in the registry: The functional and non-functional characteristics of the built service as well as its communication procedure are described (related to 2.c slm and 3.c sac). These documents are then published in a registry which enables the discovery of the new service (related to 2.b sca).

3.6 Orchestrate the service in the s o s according to its business function: This step consists of the orchestration of the new or reused service in order to integrate it in the existing composite application (related to 3.b cha and 3.c sac). If the composite application does not exist, it should be built. This possibility is not covered in this paper since it is not directly related to the service creation.

3.7 Evaluate the new service in its business environment and regarding the s o s principles: This last step focuses on the validation of the implemented service once orchestrated in its composite application (related to 3.e svt). This validation is based on the service built (or reused) compared to the underlying business processes and the sos principles.

4.4 Concluding Remarks on the Alignment of the DSDDM Steps with the ITIL v.\(3\) Processes

After the service implementation into the sos, the next stage is the service execution (see the end of the third cycle in Fig. 2). It corresponds to the use of the service functionalities. Note that the alignment of the service execution with the itil v.3 processes is not in the scope of this paper, although this issue deserves further investigations. The possible relations between the improvement of the created services and the Continual Service Improvement phase in itil are also out of the scope of this paper.

The last remark concerns the Knowledge management process (3.g kno) that supports all the dsddm steps detailed previously. Indeed, this process aims at sharing and providing the information and knowledge needed in the organization.

5 Conclusion and Future Work

A global service-orientation in it organizations requires a service-oriented management framework (such as itil v.3) and an sos. Although this kind of is structure is recommended in the itil official literature, the relations between the itil v.3 processes and the service implementation methodologies for creating the sos are not defined. In other words, the organizational processes of itil v.3 do not correspond to the activities of the existing models followed to implement and provision services in soss. This could lead to some problematic situations during the service implementation projects. For instance, several similar concepts have different names, or similar syntaxes are differently understood. We can also mention a service life cycle which is different in the current version of itil and in the existing sos implementation models.

In order to tackle this issue, we first detail and expand the Papazoglou’s service-oriented design and development methodology based on the structure of the Spiral Model. This work enabled to present the dsddm model. Then, we align it with the itil v.3 processes by identifying and describing their relations. This alignment is also shaped in three graphical illustrations, one by dsddm cycle. This work, associated with the illustrations of the proposed relations, should help the it staff and managers to organize their work, the communication and the exchange of information during the service implementation projects. Indeed, it clarifies the relations between the main itil v.3 concepts and those of the detailed service-oriented design and development methodology. It also detailed the interactions between the organization management activities and the service implementation and composition steps.

As part of our work, we shape a validation framework which can be used to generate hypotheses about the use of this work in a real environment (available in the technical paper [13]). Indeed, the current version of our work lacks of empirical validation. Once this exploratory study achieved, a second phase of the validation work should be the confirmation of these hypotheses. Of course, one of our future work is to achieve an exploratory study based on the validation framework proposed.

Another main future work lies in the analysis of the service execution and improvement steps in order to identify the possible relations between them and the itil v.3 processes and concepts.