service integration requirements for outsourced services ... · -service integration in it...

-Service Integration in IT multisourcing- 1

Service integration requirements for

outsourced services in IT multisourcing

S.A.G. Surie

Faculty of Technology, Policy Analysis and Management Delft University of Technology

May 2007

Abstract In the past few years, a new trend has been evolving in the sourcing of IT activities: IT multisourcing. By contracting several service providers, outsourcing companies can efficiently select the “best-of-breed” in the market, reducing service provider dependency and with that increasing their flexibility. IT multisourcing offers many potential benefits, including better use of core competencies, less-lock-in and spread of risks. However, multisourcing also brings along several challenges. One of the most important challenges is ensuring that the multisourced services are effectively integrated with each other, as to ensure proper end-service delivery. In this paper, a research has been performed on the service integration requirements for outsourced services in a multisourced environment. It is pointed out that, to ensure service integration, the services’ interfaces will have to be standardized on three areas: Enterprise architecture, Multisourcing governance and Service management processes. As a result, a list of 44 service integration requirements has been drawn up, indicating that, despite its potential benefits, IT multisourcing will need a considerable amount of preparation and effort to deliver success. Keywords: IT multisourcing, service integration, service interface, Enterprise architecture, multisourcing governance and service management processes Copyright © 2007 - All rights reserved. No part of this publication may be reproduced, stored in a retrieval system of any nature, or transmitted in any form or by any means, electronic, mechanical, now known or hereafter invented, including photocopying or recording, without prior written permission of the author. The author is responsible for the content of this article.


Introduction To increase the advantages of sourcing IT activities to external service providers, a new trend has been evolving: IT multisourcing. Multisourcing can be seen as the disciplined provisioning and blending of business and IT services from the optimal set of internal and external providers in the pursuit of business goals (Scardino, 2006). By contracting several service providers, outsourcing companies can efficiently select the “best-of-breed” in the market, reducing service provider dependency and with that increasing their flexibility. Multisourcing can deliver significant advantages, including better use of core competencies, less-lock-in and spread of risks. Companies that effectively multisource will be agile and able to grow, scale and change without the burden of capital investment (Cohen and Young, 2006). However, effectively multisourcing brings along several challenges, including: coordinating service management processes, obtaining a clear separation of services, coordinating innovation, determining liability, and avoiding rivalry between service providers. It can be posed that the overall challenge for a multisourced environment is to realize cross-provider partnering (Albert, 2006), also denominated as service integration. Taking the viewpoints of SUN (2002) and Pindus et al. (2000) into account, we define service integration as the controlled collaboration of self contained business process-, application-, or infrastructure components within a company and between service providers, with the objective to ensure seamless service delivery. The objective of this paper is to answer the following research question: “What are the service integration requirements for outsourced services in a multisourced environment?” Answering this question will bring insight in the issues that will arise when engaging in IT multisourcing relationships and help identify practical measures to deal with these issues. The outline of our analysis will be as follows. First, we will perform analysis on the subject of service integration. Then, we will draw up a service integration model. Accordingly, we will use this model to derive the requirements for integrating outsourced services in a multisourced environment.

Problem exploration In IT multisourcing, interfaces will need to be built by each service provider to connect its service to a client-organization’s system. Cantrell (2002) points out that differences in customization of functions, set-ups of data structures, and upgrade versions between firms might cause significant integration problems, often requiring integration interfaces to be changed every time one of the applications is changed. When taking a view upon the literature, we found that effective service integration will require the standardization of service interfaces. Cox (2006) argues that interface standardization increases flexibility and improves end-to-end delivery. Ross and Westerman (2003) state that standardized service interfaces facilitate the possibility of switching between service providers. This statement can be directly connected to one of the principles of IT multisourcing, namely being able to select the “best-of-breed” service provider when desired. The question, of course, is how to describe these standardized interfaces. In his work on service definitions, Delen (2005) describes the term sourceable unit; an IT activity defined by the client-organization (i.e. the outsourcing company) that can be outsourced to a service provider. Sourceable units must be a packet of processes of which the following interface building blocks are known: (1) inputs, (2) outputs, (3) resources and (4) methods for reporting.


As service integration requires standardized interfaces, we propose that these building blocks will have to be standardized. Figure 1 illustrates how sourceable units can be integrated through their interfaces.

Sourceable Unit (business process/

application/

infrastructure)

Interface- Inputs

- Outputs

- Resources

- Methods

for reporting

Service Integration


application/

infrastructure)

Interface- Inputs

- Outputs

- Resources

- Methods

for reporting

Figure 1: Integration between sourceable units through their interfaces. Each interface is described through its inputs, outputs, resources and methods for reporting

It can be concluded from Figure 1 that service integration actually implies the integration of sourceable units. The focus of our analysis will thus be to describe standardized sourceable unit interfaces through Delen’s (2005) building blocks and translate these descriptions into an exhaustive set of requirements, which will accordingly ensure the integration of sourceable units. 1

Insights gained from interviews To obtain insight in the definition of sourceable unit interfaces, we performed several interviews with client-organizations, service providers and sourcing advisory firms (For a complete overview of the findings done in these interviews, see Surie, 2007). In these interviews, we discussed and identified issues that should be taken into account for service integration in IT multisourcing. All interviewees acknowledged that it would be desirable to standardize service interfaces in multisourced environment. Moreover, we identified three research areas that would play an essential role for service integration in IT multisourcing:

Enterprise architecture: the multisourced environment typically lacks transparency; both clients and service providers miss the ability to maintain a clear overview of interdependencies between the different IT activities. A properly defined enterprise architecture can help establish the desired structure in the multisourced environment. Moreover, enterprise architecture helps define security and ensure continuity.

Multisourcing Governance: governance implies the assignment of roles and responsibilities for all decisions regarding the use and management of internally and externally provided resources and services (Cohen and Young, 2006). Governance in IT multisourcing supports the proper deployment of sourcing contracts, control over service providers, centralized management, and service coordination.

Service Management Processes: In an outsourcing relationship, the service should be expressed in terms that the client-organization understands and can see value (Mingay, 2006). Particularly in the multisourced environment, a collaborative approach is required.

1 In this paper, we will use the both the terms sourceable unit and service. A sourceable unit should be seen as an individual object, whereas a service belongs to a service provider. In essence, both terms have the same meaning.


This implies that the service management processes that cross the boundaries between the client and its service providers should be clearly defined. Examples of service management processes are availability management, continuity management, change management and service level management.

Research Model We concluded from the interviews that to achieve standardized interfaces, further analysis should be performed on the three research areas. Accordingly, we updated Figure 1 and drew up the service integration model, see Figure 2. The model illustrates that, to ensure the integration of sourceable units (e.g. service integration), interface descriptions should be defined through the three research areas: Enterprise architecture, Multisourcing governance and Service management processes.

En

terp

rise

arc

hite

ctu

re

Mu

ltiso

urc

ing

Go

ve

rna

nc

e

Se

rvic

e M

an

ag

em

en

t

Pro

ce

ss

es


application/

infrastructure)

Interface- Inputs

- Outputs

- Resources

- Methods

for reporting

En

terp

rise

arc

hite

ctu

re

Mu

ltiso

urc

ing

Go

ve

rna

nc

e

Se

rvic

e M

an

ag

em

en

t

Pro

ce

ss

es

Service Integration


application/

infrastructure)

Interface- Inputs

- Outputs

- Resources

- Methods

for reporting

Figure 2: Service integration model: the integration of sourceable units through the standardized interfaces, described through Enterprise architecture, Multisourcing governance and Service management processes

Research approach It can be concluded from the Figure 2 that the starting point of our analysis is to identify service interface descriptions on each research area. To bring structure in these descriptions, we will use the client-service provider interaction classes identified by Kern and Wilcocks (2000) (see Table 1);

Product and Service exchange: describes the characteristics of the service and the methods and/or standards used to facilitate interaction between services.

Financial exchange: describes monetary transactions. Service enforcement and monitoring: describes how service levels should be defined and

can be monitored accordingly. Communication and information exchange: describes the methods, formats and/or

protocols used for services to communicate and/or exchange information. Investments in people and expertise: describes the competencies the users of the service

must have. Shared, adapted and reinforced vision: describes generic rules on methods, standards, and

formats used in the multisourced environment.


However, the standardized service interface descriptions will only describe the “object” sourceable unit. To ensure service integration in IT multisourcing, we will also have to understand the interactions occurring between the standardized sourceable units in a multisourced environment. Therefore, we analyzed the implications of the aforementioned research areas on a multisourced environment and accordingly derive the desired service integration requirements. The analyses on the three research areas therefore included the following steps:

1. Identification of standardized service interface descriptions from the specific research area perspective

2. Implications of the research area on a multisourced environment 3. Identification of research area-specific service integration requirements for outsourced

services in a multisourced environment

Inputs Outputs Resources Methods for reporting

Product and service exchange

[Enterprise architecture-, Multisourcing governance- and Service management process-interface descriptions]

Financial exchange

Service enforcement and monitoring

Communication and information exchange

Investments in people and expertise

Shared, adapted and reinforced vision

Table 1: Service interface description framework; structuring inputs, outputs, resources and methods for reporting under the six interaction classes (as identified by Kern and Wilcocks, 2000)

Results In this section, the results of our analyses on the three research areas will be presented.

Enterprise architecture In the definition on service integration provided in the introduction, it was pointed out that sourced IT activities should be self contained. To incorporate self-containment in a client-organization’s enterprise architecture, many authors urge for the establishment of a so-called Service Oriented Architecture (SOA) (Gagnon et al., 2005; McGoveran, 2006; Al-Ghaiati, 2006). Using standardized interfaces for services, a SOA defines a methodology for the use and re-use of applications and business processes (Durvasula, 2006). Accordingly, the client-organization does not need to know what happens in his service providers’ underlying applications or infrastructure, only the service interface is relevant. Hence, SOA has been used to define enterprise architecture interface descriptions. Subsequently, we analyzed the implications of enterprise architecture on a multisourced environment. Accordingly, the following enterprise architecture requirements have been identified (for the complete analysis see Surie, 2007):

R1. Infrastructure components should comply with continuity and reliability prescriptions: if changes in the infrastructure are necessary, the infrastructure should be able to adapt. In other words, the infrastructure should be able to cope with malfunctions or failure of sourceable units. Continuity implies that the IT infrastructure will be able to deal with such disturbances, and that the end service delivery is guaranteed. This asks for a certain level of reliability to be incorporated in the multisourced infrastructure. In line with a service oriented design, the first requirement for infrastructure integration is that continuity and reliability should be guaranteed (Morgan Chambers, personal interview; Chang et al., 2006).

R2. Infrastructure components should comply with security prescriptions: all infrastructure linked to the multisourced environment will have to interact in a secure manner. This implies that device- and software load authentication should be in place. Accordingly, identity, access,


and trust mechanisms within and across corporate boundaries should be installed (Burnap et al., 2005).

R3. Infrastructure should contain a provisioning mechanism: it should be possible to install and remove sourced infrastructure units from the entire (multisourced) architecture. Preferably, the multisourced infrastructure incorporates a provisioning mechanism, implicating that the client-organization can orchestrate infrastructure coordination through the ability to realign compute, network, and storage resources as needed (Chang et al., 2006). This will offer the desired transparency, helping the client-organization maintain a clear overview of all connected devices.

R4. Construction of an infrastructure aggregation and abstraction repository: this repository forms the information foundation of a service oriented infrastructure (Durvasula, 2006). It provides the ability to store and retrieve the abstracted infrastructure service configurations and –interdependencies.

R5. Introduction of infrastructure-asset identifiers: asset identifiers provide a dependable way to remotely and uniquely identify and catalog physical infrastructure resources attached to a multisourced environment (Durvasula, 2006).

R6. Applications should be compatible: As application integration includes event-based information workflow to manage the exchange of data (Zeldin, 1999), the challenge of application integration is to be able to share data and processes without requiring radical changes to the applications or data structures (Linthicum; 2001). In other words, applications should be compatible within in a multisourced environment. In a SOA, this is described as “loose coupling”: the independence of service logic, requiring awareness of each other, but offering the possibility to evolve independently.

R7. Data duplication- and inconsistency should be avoided: Although each software package can be very well suited for supporting a specific business unit, integrating the different stand-alone applications could cause problems. The main reason for this is that each application looks only after its own data storage and business rules, resulting in a state of huge data duplication and severe risks for data inconsistency on a company-wide level (Lemahieu et al., 2000). For effective service integration, such data duplication should be avoided.

R8. Applications should guarantee agility: Agility implies the ability of the client-organization to respond quickly to demands or opportunities (Erl, 2005). Incorporating agility within applications gives the client-organization the possibility to change between service providers when desired.

R9. Applications should guarantee extensibility: In line with a SOA, application integration should include the possibility to add or remove services when desired (Erl, 2005).

R10. Applications should guarantee security: as applications are likely to use confidential data from the client-organization, all forms of application integration should ensure that the required level of security is maintained (Papazoglou, 2003).

R11. Applications developers should store and retrieve their data in standardized formats: to ensure that application development takes place in an orderly fashion, it will be desirable for the client-organization to oblige his application developers to store all development data into one centralized repository, so that it will be possible to maintain a complete and transparent overview of all application development (Manes, 2003).

R12. Business processes should include an orchestration mechanism: Business process integration will require the underlying applications and infrastructure to be configured in such a way that they can work together. In line with the Service Oriented Architecture, agreements will have to be made on business process interface standards. This will require efficient orchestration capabilities from the client-side (Erl, 2005; Papazoglou, 2003).

R13. Business process providers should utilize a centralized repository: In line with the SOA paradigm, Li (2004) urges for all business process-relevant information to be shared in a


collaborated repository. In such a repository, business process interdependencies as well as data on the underlying applications and infrastructure can be found.

R14. Business processes should guarantee agility: Similar to application integration, incorporating agility within multisourced business process gives the client-organization the possibility to change between service providers when desired.

R15. Business processes should guarantee security: Similar to the first two forms of intraconnection, security will have to be ensured within business process integration. As multiple underlying applications and infrastructure will have to work together in the multisourced environment, the client-organization’s security policy should be clearly defined (Papazoglou, 2003).

R16. Applications and -infrastructure should guarantee interoperatibility: identifies the set of infrastructure services that are to be leveraged in a standard way. Applications and Infrastructure should be able to effectively work together in different multisourcing scenarios. To concede to this need, interoperatibility will be necessary (The Open Group, 2006).

R17. Business processes and applications should guarantee portability: implies the identification of a set of services that are to be made available in a standard way. It should be possible to move applications to from one business process to another without requiring any changes. When connecting business processes and applications, portability will have to be ensured (The Open Group, 2006).

R18. Elimination of one-on-one dependencies between sourceable units: In accordance with the SOI, it should be able for the underlying infrastructure to handle multiple applications from different origin (Chang et al., 2006). Correspondingly, it should be possible to add multiple devices to one application. In other words, one-to-one dependencies between business processes, applications and infrastructure should be eliminated (Erl, 2005).

R19. Establishment of an infrastructure management protocol: this set of protocols enables the upper-layer business or system management applications to interact with underlying resources. This management protocol specification defines the details of the resource object handlers that manage the interaction with business processes and applications (Durvasula, 2006).

Table 2 provides an overview of the enterprise architecture service interface descriptions and enterprise architecture service integration requirements.

Service interface descriptions Requirements

Input Output Resources Methods for reporting

PRODUCT AND SERVICE EXCHANGE

Service standards Semantics

Service name Service version Service functionality description Service type Service owner Design time semantics Functionality taxonomies Authorization procedures

Enterprise Service Bus Business Process Management

- R6 - Applications should use compatible standards across the multisourced environment

R9 - Applications should guarantee extensibility

R16 - Applications and -infrastructure should guarantee interoperatibility

R17 - Business processes and applications should incorporate portability

FINANCIAL EXCHANGE

- - - - -


SERVICE ENFORCEMENT AND MONITORING

Monitoring prescriptions Service Level Agreements Availability Security constraints

Changes in functionality

-

- R1 - Infrastructure components should comply with continuity and reliability prescriptions

R2 - Infrastructure components should comply with security prescriptions

R8 - Applications should guarantee agility

R10 - Applications should guarantee security

R14 - Business processes should guarantee agility

R15 - Business processes should guarantee security

COMMUNICATION AND INFORMATION EXCHANGE

Messaging protocols Message transformation standards Routing configuration

Approval workflows

- - R19 - Establishment of an infrastructure management protocol

INVESTMENTS IN PEOPLE AND EXPERTISE

- - - - -

SHARED, ADAPTED AND REINFORCED VISION

- Dependency mapping Synchronization with other repositories Approval workflows Federation and partitioning of repositories

Service Registry Service Repository Shared data service

- R3 - Infrastructure should contain a provisioning mechanism

R4 - Construction of an infrastructure aggregation and abstraction repository

R5 - Introduction of infrastructure-asset identifiers

R7 - Data duplication- and inconsistency should be avoided

R11 - Applications developers should store and retrieve their data in standardized formats

R12 - Business processes should include an orchestration mechanism

R13 - Business process providers should utilize a centralized repository

R18 - Elimination of one-on-one dependencies between sourceable units

Table 2: Enterprise architecture service interface descriptions and enterprise architecture service integration requirements

Multisourcing Governance To identify governance interface descriptions, we applied the COBIT framework (IT Governance institute, 2005). The choice for this framework was made as it combines several other existing governance frameworks (such as ISO 17799, ISO 9001, CMM and PRINCE2) and has therefore


become widely accepted. We concluded that, for effective governance of multisourced relationships, emphasis should be drawn upon the arrangements set in the multisourced environment. These arrangements need not only be set between the client-organization and its service providers, but also between the service providers themselves. Moreover, it should be possible to measure the performance of these arrangements. Arrangements between the client-organization and the service provider are typically set up in so-called Service Level Agreements (SLAs) (Quint, 2005). To set arrangements between service providers several authors urge for the application of Operating Level Agreements (OLAs) (Bhattacharyya and Bhuwen, 2006; Albert, 2006; Longwood et al., 2005). To achieve uniform deployment of SLAs and OLAs across the multisourced environment, the following multisourcing governance requirements have been identified (for the complete analysis see Surie, 2007):

R20. Establishment of multisourcing rules across the multisourced environment by the client: in line with handling multiple stakeholders in a network (Ostrom et al., 1991) the client-organization will have to install clear rules in the multisourced environment to ensure that all parties in the multisourced environment confine to their tasks.

R21. Establishment of Operating Level Agreements by client and service providers: service providers will have to set mutual agreements as to ensure proper end-service delivery. These agreements are typically referred to as Operating Level Agreements (Albert, 2005; Longwood et al., 2005).

R22. Establishment of Service Level Agreements by client and service providers: the client-organization will have to set agreements with his service providers to measure the individual and/or end service delivery. SLAS should be uniformly defined.

R23. Allocation of responsibilities for the client and service providers: every party in the multisourced environment should know exactly what its responsibilities are (Cantrell, 2002). Responsibilities should be included in OLAs (Albert, 2005).

R24. The client-organization should establish operating procedures and collaboration principles: ensure that the desired coordination and collaboration in the multisourced requirement is obtained. According to Longwood et al. (2005), these procedures and principles include: a statement of overall objectives for the service providers to meet business needs, a summary of the client-organization’s values, a statement of common principles being agreed to by all parties addressing collaboration and introduction of innovation, a process definition of the service delivery value chain for the services covered in the OLA, an outline of mechanisms for addressing cross-boundary issues, an outline of related problem and change management processes

R25. The client-organization should utilize uniform measurement methods: the client-organization should be able to measure success or failure of resulting relationships and monitor key end-to-end service levels to achieve (Longwood et al., 2005). This can be achieved through uniformly quantifying Service Level Agreements (SLAs) and Operating Level Agreements (OLAs) over the entire multisourced environment.

R26. The service delivery should be adequately documented: to ensure proper measurement and collaboration, all agreements will have to be clearly documented. This will bring support in the allocation of resources, improve transparency and can be used to resolve disputes (Gallivan and Oh, 1999; White, 2004).

R27. The client should implement standardized communication methods within the multisourced environment: as a multisourced environment can result in a complex web of dependencies. It will be desirable to set agreements on communication to ensure the required service provider coordination (Gallivan and Oh, 1999). Therefore, formal communication standards should be set up (Cohen and Young, 2006), including communication protocols, scheduled meetings with and between service providers, and communication specialists.


R28. Clear rules setting on integrated service delivery payments: a clear demarcation of services through arrangements and performance should include a transparent and clear payment system.

Table 3 provides an overview of the governance service interface descriptions and multisourcing governance service integration requirements.

Service interface descriptions Requirements Input Output Resources Methods for reporting


Documented system owners Security incident definition Contractual Arrangements Third-party relationship management requirements

Knowledge transfer requirements for solutions implementation Disaster service data including roles and responsibilities Backup storage Updated IT service portfolio Changes in service delivery

People Information Applications infrastructure

Contract review reports R23 - Allocation of responsibilities for the client and service providers

FINANCIAL EXCHANGE

IT budgets IT financials


- R28 - Clear rules setting on integrated service delivery payments


Service Level Agreements Operating Level Agreements Quality improvement actions Required changes Problem records Procurement decisions Physical environment requirements Known problems, errors and workarounds Operator instructions for data management Availability, continuity and recovery specification Risk assessment System monitoring requirements Disaster service requirements IT configuration Security specifications Security threats and vulnerabilities

Service Level Agreements Operating Level Agreements New/updated service properties Performance and capacity plan Required changes Contingency test results Criticality of IT configuration items Incident/disaster thresholds Incident tickets Error logs


User satisfaction reports Change status reports Process performance reports Incident reports

R22 - Establishment of Service Level Agreements by client and service providers

R21 - Establishment of Operating Level Agreements by client and service providers

R25 - The client-organization should utilize uniform measurement methods


Performance input to IT planning IT-related risk remedial action

- People Information Applications

- R26 - The service delivery should be adequate documented


plans Backup storage and protection plan Promotion to production and software release and distribution plans Project management guidelines and detailed project plans Business requirement feasibility study Required documentation updates

infrastructure R27 - The client should implement standardized communication methods within the multisourced environment


Business process, application and infrastructure knowledge User, operational, support, technical and administration manuals Business requirement feasibility study Specific training requirements on security awareness

Training materials User, operational, support, technical and administration manuals


- R24 - The client-organization should establish operating procedures and collaboration principles


IT project portfolio Service provider risks Service provider catalogue Assigned data classifications

- - - R20 - Establishment of multisourcing rules across the multisourced environment by the client

Table 3: Governance service interface descriptions and multisourcing governance service integration requirements

Service management processes In his research on IT outsourcing relationship management, Bijmholt (2002) identified service process management interface descriptions for ITIL and ASL processes. The ITIL and ASL are service process management frameworks frequently applied in outsourcing relationships (also see Herwaarden et al., 2005). 2 3 Therefore, we used Bijmholt’s findings for our analysis. To make the translation from service process management interface descriptions to service process management requirements, it was necessary to understand the implications of integrating processes in a multisourced environment. As a process is an ongoing sequence of activities, we noted that a change and/or disturbance in a process in one sourceable unit will directly influence the processes of sourceable units it is integrated with. Therefore, we examined the implications of process changes and/or disturbances for every ITIL and ASL process. Accordingly, we identified the following service process management integration requirements:

R29. Establishment of uniform ITIL and ASL descriptions across the multisourced environment: ITIL and ASL processes should be uniformly described and quantified across the entire multisourced environment. This will help avoid undesired accumulations and pinpoint which sourceable unit is delivering a poor service.

2 For more information on the ASL framework see: http://www.aslfoundation.org 3 For more information on the ITIL framework see: http://www.ccta.co.uk


R30. Client expectations should be translated to service levels: service level management in a multisourced environment should provide a mechanism for setting clear expectations with the client-organization about the service being delivered and then measuring performance against these requirements.

R31. Standardized method for reporting and management across the multisourced environment: the method of reporting and management should be formalized over all parties involved.

R32. Adequate downtime measurement across the multisourced environment: to maintain a clear overview in the overall service availability, it should be possible to pinpoint which sourceable unit is delivering the lowest availability rate. This will require a proper measurement of downtimes, which can bring support to other service management processes, such as incident management, problem management and service level management.

R33. Prevention of interruptions across the multisourced environment: this requirement concerns preventing interruptions to IT services as well as recovering services after an interruption occurs.

R34. Incorporation of contingency plan: A contingency plan will be utilized in a time of disaster and/or protracted service outage to support the overall business process by ensuring that the required IT technical resources and services facilities can be recovered within the business timescales as agreed in pre-defined service levels.

R35. Establishment of parameters on service use: capacity management in a multisourced environment will require information about usage scenarios, patterns, and peak load characteristics of the service solution.

R36. Implementation of proper capacity planning mechanism: it should be possible for the client-organization to recognize the impact of changes on future capacity levels. Hence, the impact of new services should be reevaluated throughout the entire multisourced environment.

R37. Implementation of overall cost control mechanism: the client-organization should be able to identify all costs in the multisourced environment. This implies that it should be possible to perform analyses on single sourceable units as well as integrated sourceable units.

R38. Centralized service desk: to maintain a clear overview of services, the service desk should be established as a single point of contact between the users and provider of IT services.

R39. Clear taxonomy on incident management: because of this complexity caused by the required interaction with other service management processes and the need for clear communication on incidents, a clear incident taxonomy will have to be developed to facilitate incident management.

R40. Identification and documentation of errors across the multisourced environment: a key objective of problem management is to ensure stability for the IT infrastructure. Therefore, it should offer the ability to either create a workaround or initiate a request for change to resolve or eliminate the root cause of the problem.

R41. Information should be stored and retrieved in standardized formats: the information within the configured item should be held within a single repository and includes description, version, consistent components, relationships with other configured items, location/assignment, and current status

R42. Understanding of the impact of changes: a key requirement of the change management process is to ensure that all parties affected by a given change are aware of and understand the impact of the impending change. Changes are also rated in their impact and urgency, and ITIL provides an excellent process flow for processing changes of different levels of importance.

R43. Adequate resource planning and management: Release management should take a holistic view of a change to an IT service and ensures that all aspects of a release are considered together, both technical and non-technical. Therefore, resource planning and management


will be necessary to successfully package and distribute releases across the multisourced environment.

R44. Conversion of data to new application releases: the introduction of a new application release often brings with it changes to the production environment of the existing applications and infrastructure. Accordingly, conversions in the multisourced environment may be needed.

Table 4 provides an overview of the service process management interface descriptions and service process management integration requirements.

Service interface descriptions Requirements Input Output Resources Methods for reporting


Desired service portfolio Forecast on service purchase Need for new service Request for change in service Service level need Request for service delivery Acknowledgement delivery Incident report Acknowledgement problem solved Functionality need Further functionality specifications Changes in priorities Agreement on design specification

Service portfolio Impact analysis of service change Planning of service change Service change Planning of service delivery Service delivery Impact analysis change in functionality Planning of change in functionality Design documentation Changed functionality

- Test report Status report on change in functionality

R30 - Client expectations should be translated to service levels

R40 - Identification and documentation of errors across the multisourced environment

R42 - Understanding of the impact of changes

R43 - Adequate resource planning and management

R44 - Conversion of data to new application releases

FINANCIAL EXCHANGE

Financial conditions Budget Payment

Invoices Tariffs

Financial reports R37 - Implementation of overall cost control mechanism


Governance data Availability criteria Continuity criteria Vulnerability business processes Capacity policy Quality criteria Reporting need Complaints Authorization of changes Instruction for discharge

Quality planning Results of quality audits Service Level Agreement Capacity risks

- Availability reports Trend analysis service use Reports on measures for continuity Audit and review reports Reports on service levels

R31 - Standardized method for reporting and management across the multisourced environment

R32 - Adequate downtime measurement across the multisourced environment

R33 – Prevention of interruptions across the multisourced environment

R34 - Incorporation of contingency plan

R35 - Establishment of parameters on service use

R39 - Clear taxonomy on incident management


R41 - Information should be stored and retrieved in standardized formats


Status request Project planning Desired planning Instruction for change in functionality Test data and scenario's

- - - R29 - Establishment of uniform ITIL and ASL descriptions across the multisourced environment

R38 - Centralized service desk


- Available capacity and expertise

Audit and review reports R36 - Implementation of proper capacity planning mechanism


- - - - -

Table 4: Service process management interface descriptions and service process management integration requirements

Discussion In the analysis on service interface descriptions, we deliberately attempted to avoid overlap between the different research areas, as to maintain a clear overview. For example, we acknowledge that SOA performance can also be measured in terms of security, availability and reliability levels. To avoid overlap, performance measurement has now been placed under Multisourcing governance. Another example is the absence of resource descriptions under service process management. We decided that these are the same as for Multisourcing governance (People, Information, Applications, infrastructure), and have therefore not been taken up twice. Even so, several duplications can still be found within the different service interface descriptions provided in Tables 2, 3 and 4 (for example the establishment of Service Level Agreements, availability specifications and insights in service changes). We conclude that the three research areas should not be seen separately independently; meeting the identified service integration requirements will require an approach in which all requirements complement with each other. A limitation of this research can be found within the definition of service interfaces. The service interface descriptions presented in this research are fully based on Delen’s (2005) findings. In retrospect, we are not convinced that the incorporation of resources in service interface descriptions is necessary. In our opinion, the resources should be properly allocated within the sourceable unit itself (e.g. in the content). Moreover, the content of the sourceable unit should be structures in such a way that it can comply with the identified service interface descriptions. Therefore, we recommend that further research is conducted on the structure of the IT content within the sourceable unit/service. A second limitation is that the identified service integration requirements are largely based on theory. Although the identified requirements have been evaluated by the participants of the interviews (see Surie, 2007) and the applied frameworks have become widely accepted in IT environments, the impact of our requirements on real-life multisourcing scenarios will still have to be evaluated.


Therefore, evaluative research should be done on the performance of different multisourcing projects. This should point out if and to what extent the identified requirements were taken into account and had an impact on the quality of the end-service delivery. Furthermore, this research should point out if the client-organization is capable of obliging its service providers to comply with pre-defined standards. We recommend that design specifications be drawn up, as to translate the identified service integration requirements in an operational multisourcing design (also see Surie, 2007). Implementing an operational multisourcing design will require the client-organization to take a pro-active stance upon its service providers, as service delivery will have to occur through pre-defined, standardized service interfaces. The client-organization should properly instruct its sourcing management department how to deal with and what to require of the contracted service providers. This might imply radical organizational change within the client-organization; implementation of a Service Oriented Architecture or establishment of uniform ITIL and ASL descriptions across the multisourced environment can prove to be a complex affair. We conclude that, to ensure the success of IT multisourcing, effective service integration will be essential, but will also require a considerable amount of preparation and effort to deliver success. The extensive list of requirements provided in this research provides a useful frame of reference for all client-organizations considering and/or engaging in IT multisourcing.


References Al-Ghaiati, F.M. (2006); "A Proposal for an Open Solution Business Process Integration and Management Implementation Framework" Alexandria University, Egypt Albert, G. (2006); "The Multisourcing Imperative" Global services media Bhattacharyya, N. and Bhuwen, A. (2006); "Can operational level agreements be the answer to multi-sourcing blues in the area of cross-vendor cooperation?" Setlabs briefings, vol.4, no. 2 Bijmholt, H.B. (2004); "Managen van IT-uitbestedingsrelaties, Beschrijving van de processen bij de afnemer van IT diensten" Master Thesis, Open Universiteit Nederland, Nieuwerkerk aan den IJssel, The Netherlands Burnap, P., Gray, A., Miles, J. and Randa, O.F (2005); "A Service Oriented Infrastructure to Facilitate Trust in Collaborative Working" School of Computer Science, Cardiff University, United Kingdom Cantrell, S (2002); "Integrating Outsourced Enterprise Solutions" Next Generation Enterprise Solutions, Institute for strategic change, Accenture Chang, M., Castro-Leon,E., Hahn-Steichen, J.H., He, J., Hobbs, J. and Yohanan, G. (2006);"Service Orchestration of Intel-Based Platforms Under a Service-Oriented Infrastructure" Intel technology journal, vol. 10, no. 4 Cohen, L. and Young, A. (2006); “Multisourcing” Harvard School Business Publishing, Boston, Massachusetts, USA Cox, R. (2006); "Building the Most Effective Team for Managing the Multisourced Environment" Gartner Outsourcing and IT services, London, United Kingdom Delen, G. (2005); “Decision- en controlfactoren voor IT-sourcing” Van Haren publishing, Zaltbommel, The Netherlands Durvasula, S. (2006); "Why Services-Oriented Architecture?" SOA Practitioners’ Guide Part 2 Erl, T. (2005); “ Service-Oriented Architecture” Pearson Education Inc., Indiana, USA Gallivan, M.J. and Oh, W. (1999); "Analyzing IT Outsourcing Relationships as Alliances among Multiple Clients and Vendors" Proceedings of the 32nd Hawaii Conference System Sciences, Hawaii, USA Herwaarden, H. Geddes, G. and Heuthorst, J. (2005): "The IPW Maturity Model and IPW" Quint Wellington Redwood white paper IT Governance Institute (2005); “Cobit 4.0” ISBN 1-933284-37-4, Illinois, USA Kern, T. and Willcocks, L. P. (2001); "The Relationship Advantage: Information Technologies, Sourcing, and Management". Oxford University Press, Oxford, United Kingdom Lemahieu, W., Snoeck, M. and Michiels, C. (2000); "An Enterprise Layer based Approach To Application Service Integration" Department of Applied Economic Sciences, Leuven, Belgium Li, X. (2004); “Business Process Integration” Fakultät Elektrotechnik, Informatik, Informationstechnik, Universität Stuttgart, Germany Linthicum, D.S. (2001); “Defining B2B Application Integration” Addison Westley Information technology services Longwood, J., Matlus, R.T., Maurer,W, and Underwood D. (2005); "Management Update: Use Multisource Operating-Level Agreements to Get Better Outcomes From Eservice providers" Gartner research Manes, A.T. (2003); "Web Services Registry: The Foundation for SOA Governance" Burton Group Research Report, Midvale, Utah, USA Mingay, J. (2006); Standardize Your Processes for Multisourcing Management” Gartner Outsourcing & IT Services Summit, London, United Kingdom


Ostrom, E. (1991); “Institutional Analysis of Common-Pool resources”, in Ostrom et al. Rules, games and common pool resources, University of Michigan, Michigan, USA Papazoglou, M.P. (2001); "Service-Oriented Computing: Concepts, Characteristics and Directions" Dept. of Information Systems and Management, Tilburg University, The Netherlands Pindus, N.R., Koralek, K., Martinson, F. and Trutko, J. (2000); "Coordination and Integration of Welfare and Workforce Development Systems," Washington, D.C.: Urban Institute, p. 4. Quint Wellington Redwood (2005); "The CIO role in the post-outsourcing era" Whitepaper Ross, J. and Westerman, G. (2003); “Architecting new outsourcing solutions: the promise of utility computing” MIT Sloan School of Management, Massachusetts, Cambridge Scardino, L. (2006); “Application outsourcing, current trends and future outlook” Gartner Outsourcing and IT services, London, United Kingdom SUN (2002); “Business process integration” SUN One architecture guide pp. 77-98 Surie, S.A.G. (2007); “Service integration in IT multisourcing” Master thesis, faculty of Technology Policy and Management, TU Delft, Delft, The Netherlands The Open Group (2006); “Foundation Architecture: Technical Reference Model” to be found on

http://www.opengroup.org/architecture/togaf8-doc/arch/chap20.html White, W. (2004); "IT governance and outsourcing" CGI whitepaper Zeldin, S. (1999); “Business Objects and Application Integration”, TSI Software

http://www.opengroup.org/architecture/togaf8-doc/arch/chap20.html

service integration requirements for outsourced services ... · -service integration in it...

Documents