Modelling Service Level Agreements for Business Process Outsourcing Services

Modelling Service Level Agreements for Business Process Outsourcing Services? Adela del–Río–Ortega, Antonio Manuel Gutiérrez, Amador Durán, Manuel Resinas, and Antonio Ruiz–Cortés Universidad de Sevilla, Spain {adeladelrio,amgutierrez,amador,resinas,aruiz}@us.es Abstract. Many proposals to model service level agreements (SLAs) have been1 elaborated in order to automate different stages of the service lifecycle such as2 monitoring, implementation or deployment. All of them have been designed for3 computational services and are not well–suited for other types of services such4 as business process outsourcing (BPO) services. However, BPO services sup-5 ported by process–aware information systems could also benefit from modelling6 SLAs in tasks such as performance monitoring, human resource assignment or7 process configuration. In this paper, we identify the requirements for modelling8 such SLAs and detail how they can be faced by combining techniques used to9 model computational SLAs, business processes, and process performance indi-10 cators. Furthermore, our approach has been validated through the modelling of11 several real BPO SLAs.12 1 Introduction13 Service level agreements (SLAs) have been used by many proposals in the last decade14 to automate different stages of the service lifecycle, using a formal definition of the15 different parts of an SLA such as service level objectives (SLOs), penalties, or met-16 rics, to automate their negotiation [1], the provisioning and enforcement of SLA–based17 services [2], the monitoring and explanation of SLA runtime violations [3], or the pre-18 diction of such violations [4]. What all of these proposals have in common is that most19 of them have been designed for computational services. Therefore, they are aimed at en-20 hancing software that supports the execution of computational services such as network21 monitors, virtualisation software, or application servers with SLA–aware capabilities.22 On the other hand, business process outsourcing (BPO) services are non–computatio-23 nal services such as logistics, supply–chain, or IT delivery services, that are based on the24 provisioning of business processes as services, providing partial or full business process25 outsourcing. Like computational services, their execution is regulated by SLAs and sup-26 ported by specific software [5,6]. In this case, since BPO services are process–oriented,27 the software that supports them is usually a process–aware information systems (PAIS)28 such as ERPs, CRMs, or business process management systems (BPMSs). However,29 ?This work has been partially supported by the European Commission (FEDER), the Spanish and the Andalusian R&D&I programmes (grants TIN2012–32273 (TAPAS), TIC–5906 (THEOS) and COPAS (P12–TIC-1867)) 2 unlike computational services, there is little work related to the extension of PAIS with30 SLA–aware capabilities to support BPO services.31 A PAIS with SLA–aware capabilities, i.e. an SLA–aware PAIS, is a PAIS that uses32 explicit definitions of SLAs to enable or improve the automation of certain tasks related33 to both the SLAs and their fulfilment such as performance monitoring, human resource34 assignment or process configuration [7]. For instance, an SLA–aware PAIS could be35 automatically instrumented according to the metrics defined in the SLA so that when36 there is a risk of not meeting an SLO, an alert is raised allowing the human actors37 involved in the process to take measures to mitigate the risk. Another example could be38 the automated configuration of the process, e.g. removing or adding activities, executed39 by the SLA–aware PAIS depending on the conditions of the SLA agreed with the client.40 Apart from the benefits derived from the automation of these tasks, the need for a41 SLA–aware PAIS becomes more critical in a business–process–as–a–service (BPaaS)42 scenario. A BPaaS is a new category of cloud–delivered service, which, according to43 Gartner [8], can be defined as “the delivery of BPO services that are sourced from44 the cloud and constructed for multitenancy. Services are often automated, and where45 human process actors are required, there is no overtly dedicated labour pool per client.46 The pricing models are consumption–based or subscription–based commercial terms.47 As a cloud service, the BPaaS model is accessed via Internet–based technologies.” In48 this setting, the conditions of the SLA agreed with each client may vary. Therefore, it49 is crucial for the PAIS that supports the BPaaS to behave according to the SLA agreed50 with the client. An example could be the prioritisation of the execution of tasks for those51 clients whose SLAs have bigger penalties if they are not met.52 In this paper, we focus on the formalization of BPO SLAs as a first step to enable53 such SLA–aware PAIS. To this end, after analysing the modelling requirements of such54 SLAs, four main aspects involved in their formalization have been identified, namely: 1)55 the description of the business process provided by the service; 2) the SLOs guaranteed56 by the SLA; 3) the penalties and rewards that apply if guarantees are not fulfilled; and 4)57 the definition of the metrics used in these guarantees. Then, we detail how these aspects58 can be formalized by means of generic models for the definition of computational SLAs59 and techniques used to model process performance indicators. Furthermore, we have60 validated our approach through the modelling of several real BPO SLAs.61 The remainder of the paper is structured as follows. In Section 2, a running example62 is introduced. Section 3 details the four elements that must be formalized in SLAs for63 BPO services and Section 4 shows how they can be modelled using WS–Agreement.64 Next, Section 5 reports on how the running example can be formalized using our pro-65 posal and discusses some limitations identified during the definition of the SLA metrics.66 Section 6 reports on work related to the definition of SLAs for BPO services. Finally,67 conclusions are detailed in Section 7.68 2 Running Example69 Let us take one of the BPO SLAs to which our approach has been applied as running70 example throughout this paper. The SLA takes place in the context of the definition of71 statements of technical requirements (SoTRs) of a public company of the Andalusian72 3 Autonoumous Government, from now on Andalusian Public Company, APC for short.73 SoTRs are described in natural language and include information about the services74 required as well as their SLA. Although the running example includes one service only,75 further information on this or the rest of services, as well as for further application76 scenarios, is available at http://www.isa.us.es/ppinot/caise2015.77 The SoTR of this example is defined for the Technical Field Support for the Deploy-78 ment of the Corporative Telecommunication Network of the Andalusian Autonomous79 Government. It is presented in a 72–page document written in natural language includ-80 ing the SLAs defined for five of the required services, namely: 1) field interventions;81 2) incidents; 3) network maintenance; 4) installations and wiring; and 5) logistics. In82 particular, we focus on the field interventions (FI) service.83 From a high–level perspective, the FI service can be defined as follows: the APC re-84 quires an FI, which can have different levels of severity, from the contractor staff. Then,85 the contractor plans the FI and performs it at headquarters. In some cases, it is necessary86 for the contractor to provide some required documentation and, if such documentation87 is considered incomplete or inadequate by the APC, it needs to be resubmitted by the88 contractor until it fulfils the APC’s quality requirements.89 For this service, the SoTR document presents the following information: 1) the committed times by the contractor (see Table 1); 2) the general objective defined for FIs —the SLO of the SLA— represented as AFIP >95%, where the AFIP (accomplished FIs percentage) metric is defined as: AFIP =# accomplished FIs # FIs ⇥100 and 3), the penalties applied in case the SLO is not accomplished (see Table 2). These90 penalties are defined over the monthly billing by the contractor for the FI service. In91 addition, the SoTR presents the following definitions for the referred times in Table 1:92 Response Time Elapsed time between the notification of the FI request to the contrac-93 tor and its planning, including resources assignment, i.e. technicians.94 Presence Time Elapsed time between resource (technician) assignment and the begin-95 ning of the FI, i.e. technician arrival.96 Resolution Time Elapsed time between the technician arrival and the end and closure97 of the FI.98 Documentation Time If documentation, i.e. reports, is required, it is defined as the99 elapsed time between the end and closure of the FI and documentation submission.100 Table 1. Committed times by the contractor (in hours) for the FI Service SLA Criticality Level Response Time Presence Time Resolution Time Document. Time Timetable Calendar Critical 0.5 4 2 4 8:00 – 20:00 Local High 2 8 4 12 8:00 – 20:00 Local Mild 5 30 6 24 8:00 – 20:00 Local Low 5 60 8 48 8:00 – 20:00 Local 4 Table 2. Penalties definition (in monthly billing percentage) for the FI Service SLA AFIP Penalty 94% AFIP <95% -1% 93% AFIP <94% -2% 92% AFIP <93% -3% 91% AFIP <92% -4% 90% AFIP <91% -5% AFIP <90% -10% If the APC considers such documentation as incomplete or inadequate, it will be101 returned to the contractor and documentation time is again activated and computed.102 3 Requirements for Modelling SLAs of BPO Services103 After a study of the state of the art in SLAs for both computational and non–computatio-104 nal services, and the analysis of more than 20 different BPO SLAs developed by 4 dif-105 ferent organisations, some of the requirements for modelling BPO SLAs in the context106 of SLA–aware PAIS have been identified. As a result, we conclude that four elements107 must be formalized in SLAs for BPO services, namely: 1) the business process; 2) the108 metrics used in the SLA; 3) the SLOs guaranteed by the SLA; and 4) the penalties and109 rewards that apply if guarantees are not fulfilled. Next we describe each of them.110 3.1 Business process111 An SLA is always related to one or more specific services. The way such services must112 be provided is usually defined by describing the underpinning business process, and113 this is often done in natural language. Consequently, the formalization of SLAs for114 BPO services requires the formalization of the business process itself. Note that it is not115 required for the SLA to detail the low level business process that will be enacted by the116 provider’s PAIS since most SLAs do not delve into that level of detail and just focus117 on main activities and the consumer–provider interaction (cf. Fig 1 for the high–level118 business process of the running example). However, it should be possible to link this119 higher level business process to the lower level business process enacted by the PAIS.120 3.2 SLA metrics121 These are the metrics that need to be computed so that the fulfilment of the SLA can122 be evaluated. For instance, in the running example, response time,presence time, or123 AFIP are examples of such metrics. The mechanism used to define these metrics must124 have two main features. On the one hand, it must be expressive, i.e. it must allow the125 definition of a wide variety of metrics. On the other hand, it must be traceable with126 5 Contractor APC FI requested FI request Plan FI Perform FI FI documentation required? Create and submit FI documentation Documentation Accepted Correction required FI closed no FI documentation Correction request FI documentation acceptation Fig. 1. BPMN model of Field Intervention (FI) service the business process so that it enables their automated computation. In addition, it is127 convenient that the metrics are defined in a declarative way because it reduces the gap128 between the SLA defined in natural language and the formalised SLA and decouples129 the definition of the metric from its computation.130 3.3 Service Level Objectives (SLOs)131 These are the assertions over the aforementioned metrics that are guaranteed by the132 SLA and, hence, must be fulfilled during the execution of the service. For instance, the133 running example defines AFIP >95% as an SLO for AFIP metric of the FI service.134 In general, SLOs can be defined as mathematical constraints over one or more SLA135 metrics.136 3.4 Penalties and rewards137 They are compensations that are applied when the SLO is not fulfilled or is improved,138 respectively. An example is shown in Table 2, which depicts the penalties that apply for139 the FI Service SLA in our running example. The specification of penalties and rewards140 require the definition of a mathematical function, whose domain is one or more SLA141 metrics and whose range is a real number representing the penalty or reward in terms142 of a percentage over the price paid for the service in a time period.143 From these requirements, we conclude that the structure of SLAs for BPO services144 is very similar to the structure of SLAs defined for computational services. For in-145 stance, Amazon EC2 SLA1also includes a definition of the service; some metrics like146 the monthly uptime percentage (MUP); an SLO, which is called service commitment,147 defined as MUP 99.95%; and a penalty based on the MUP and defined in terms of148 a percentage over the price paid in the last month. Furthermore, the definition of SLOs149 and penalties and rewards can also be done in the same manner.150 1http://aws.amazon.com/ec2/sla/ 6 In contrast, the description of the service and the definition of the SLA metrics of151 BPO SLAs and computational SLAs present significant differences. The main reason is152 that, unlike computational services, BPO services are process–aware and, hence, their153 description and their SLA metrics are based on that process.154 4 Modelling SLAs for BPO Services155 Based on the requirements described in the previous section, and on the similarities and156 differences between BPO SLAs and computational SLAs, we propose modelling the157 latter SLAs by combining the agreement structure and mechanisms for the definition158 of SLOs, penalties, and rewards that have been already proposed for computational159 SLAs, with notations used to model processes and Process Performance Indicators160 (PPIs), such as [9,10,11,12,13]. PPIs are quantifiable metrics that allow the efficiency161 and effectiveness of business processes to be evaluated; they can be measured directly162 by data that is generated within the process flow and are aimed at the process controlling163 and continuous optimization [14].164 Specifically, in this paper we propose using WS–Agreement [15] as the agreement165 structure; BPMN as the language to model business processes; PPINOT [13] as the166 mechanism to model PPIs; the predicate language defined in iAgree [16] to specify167 SLOs, and the compensation functions introduced in [17] to model penalties and re-168 wards. These proposals have been chosen because of two reasons. Firstly, they are169 amongst the most expressive proposals of their kind, which is necessary to model the170 different scenarios that appear in BPO SLAs. Secondly, they have a formal founda-171 tion that enables the development of advanced tooling support that can be reused in a172 SLA–aware PAIS environments.173 In the following, we introduce the basic structure of an SLA in WS–Agreement and174 then, we detail how it can be used together with other languages and models to define a175 BPO SLA. Furthermore, we also provide more details about the aforementioned models176 and the tooling support that has been developed for them.177 4.1 WS–Agreement in a nutshell178 WS–Agreement is a specification that describes computational service agreements be-179 tween different parties. It defines both a protocol and an agreement document meta-180 model in the form of XML schema [15]. According to this metamodel, an agreement181 is composed of an optional name, a context and a set of terms. The context section182 provides information about participants in the agreement (i.e. service provider and con-183 sumer) and agreement’s lifetime. The terms section describes the agreement itself, in-184 cluding service terms and guarantee terms.185 Figure 2 shows the overall structure of a WS–Agreement document using iAgree186 syntax [16], which is designed for making WS–Agreement documents more human–187 readable and compact than with the original XML syntax. All examples included in this188 paper are defined using iAgree.189 Service terms describe the provided service, and are classified in service description190 terms,service properties and service references. Service description terms (lines 9–10)191 7 1Agreement Example version 1 2Provider as Responder 3Metrics 4ServiceCreditMeasure: Percentage 5AvailabilityMeasure: Percentage 6CostMeasure: Integer 7AgreementTerms 8Service Example @ http://mycloud.com/service.wsdl 9DescriptionTerms 10 Cost : CostMeasure = 10 11 MonitorableProperties 12 Availability : AvailabilityMeasure 13 GuaranteeTerms 14 G1: Provider guarantees 15 Availability > 99 16 with monthly penalty of 17 ServiceCredit : ServiceCreditMeasure = 25 18 if Availability 99 19 EndAgreement Fig. 2. Computational SLA in WS–Agreement using iAgree syntax describe the features of the service that will be provided under the agreement. They192 identify the service itself, so there is no reason to monitor them along service lifecycle.193 Service properties (lines 11–12) are the set of monitorable variables relevant to the194 agreement, for which a name and a metric are defined. Finally, service references (line195 8) point to an electronic service using endpoints references.196 Guarantee terms (lines 13–18) define SLOs that the obligated party must fulfil to-197 gether with the corresponding penalties and rewards. An SLO in WS–Agreement is an198 assertion over monitorable properties that must be fulfilled during the execution of the199 service. SLOs can be guarded by a qualifying condition (QC), which indicates a pre-200 condition to apply the constraint in the SLO. Both SLOs and QCs are expressed using201 any suitable user–defined assertion language. penalties and rewards.202 4.2 Materialising BPO SLAs with WS–Agreement203 WS–Agreement leaves consciously undefined the languages for the specification of ser-204 vice description terms, SLOs, or QCs. This flexibility makes WS–Agreement a good205 choice for modelling BPO SLAs since it allows embedding any kind of model in its206 terms. In this paper, we propose the following WS–Agreement Configuration [16] for207 defining BPO SLAs:208 Service Description Terms In BPO services, this description can be provided in terms209 of the underpinning business process. In this paper we use the BPMN (Business Process210 Model and Notation) standard since it is a well–known standard widely used in both211 industry and academy.212 Service Properties In BPO services, these metrics can be specified using a PPI–213 oriented approach. In this paper, we have chosen PPINOT [13] because of its expres-214 siveness and its traceability with BPMN models. Furthermore, PPINOT has been used215 8 at the core of a software tool called the PPINOT Tool Suite [18], which includes the216 definition of PPIs using either a graphical or a template–based textual notation [19],217 their automated analysis at design–time, and their automated computation based on the218 instrumentation of open source BPMSs.219 Specifically, metrics are defined using PPINOT measure definitions. As described220 in [13], they can be classified into three main categories depending on the number of221 process instances involved and the nature of the measure: base measures, aggregated222 measures, and derived measures.223 Base measures They are obtained directly from a single process instance and do not224 require any other measure to be computed. Aspects that can be measured include:225 1) the duration between two time instants (time measures); 2) the number of times226 something happens (count measures); 3) the fulfilment of certain condition in both227 running or finished process instances (condition measures); and 4) the value of a228 certain part of a data object (data measures).229 Aggregated measures Sometimes, it is interesting not only knowing the value of a230 measure for a single process instance (base measures) but an aggregation of the231 values corresponding to the multiple instances of a process. For these cases, aggre-232 gated measures are used, together with an aggregation function such as average,233 maximum, etc.234 Derived measures They are defined as functions of other measures. Depending on235 whether the derivation function is defined over single or multi–instance measures,236 derived measures are classified accordingly as derived single–instance measures or237 derived multi–instance measures (see [13] for details).238 Guarantee Terms To define SLOs, we use the predicate language defined in iAgree239 [16], which includes relational, logical and common arithmetic operators. Apart from240 a concrete syntax, iAgree also provides semantics to define SLOs expressions as logic241 constraints, which enable the automation of analysis operations on SLAs such as de-242 tecting conflicts within an agreement document [16] or explaining SLA violations at243 run–time [3]. Concerning penalties and rewards, they are defined using iAgree syntax244 as well together with the notion of compensation functions defined in [17].245 5 Applicability of our approach246 In order to validate the applicability of our approach, we have used it to model the247 SLAs of 9 different services designed by 3 different organisations. In the following,248 we show how WS–Agreement and PPINOT can be used to model the running example249 and then, discuss the limitations we have found and how they can be solved. The re-250 maining SLAs that have been modelled are available at http://www.isa.us.es/251 ppinot/caise2015.252 5.1 SLA for the running example253 Figure 3 shows an excerpt of the SLA for the running example, in which the three254 elements of the BPO SLA are specified as follows.255 9 1Agreement FI_Service_SLA version 1 2Provider Corporate as Responder; 3Metrics for FI_Service: 4ResponseTime: LinearTimeMeasure 5from event FI requested is triggered 6to activity Plan FI becomes active 7considering only working hours and local calendar 8PresenceTime: LinearTimeMeasure ... 9ResolutionTime: LinearTimeMeasure ... 10 DocumentationTime: CyclicTimeMeasure aggregation Sum 11 from activity Create and submit doc becomes active 12 to activity Create and submit FI documentation becomes completed 13 considering only working hours and local calendar 14 CLevel: DataMeasure criticalityLevel of Intervention 15 AFI_Measure: AggregatedMeasure with function sum 16 aggregates DerivedMeasure with function A & B & C & D where 17 A: DerivedMeasure with function 18 CLevel = critical => ResponseTime < 0.5 & PresenceTime <4& 19 ResolutionTime <2 &DocumentationTime <4 20 B: DerivedMeasure with function 21 CLevel = high => ResponseTime <2&PresenceTime <8& 22 ResolutionTime <4&DocumentationTime < 12 23 C: DerivedMeasure with function 24 CLevel = mild => ResponseTime <5&PresenceTime < 30 & 25 ResolutionTime <6&DocumentationTime < 24 26 D: DerivedMeasure with function 27 CLevel = low => ResponseTime <5&PresenceTime < 60 & 28 ResolutionTime <8&DocumentationTime < 48 29 FI_Measure: AggregatedMeasure with function sum 30 aggregates CountMeasure when event FI closed is triggered 31 AFIP_Measure: DerivedMeasure with function ( AFI_Measure / FI_Measure ) *100 32 33 AgreementTerms 34 Service FI_Service 35 process: 36 Contractor APC FI requested FI request Plan FI Perform FI FI documentation required? Create and submit FI documentation Documentation Accepted Correction required FI closed no FI documentation Correction request FI documentation acceptation 37 MonitorableProperties 38 AFIP: AFIP_Measure 39 Guarantee Terms 40 G1: Provider guarantees AFIP > 95% 41 with monthly penalty 42 of Penalty = 95 - AFIP if 90% AFIP < 95% 43 of Penalty = 10 if AFIP < 90% 44 ... Fig. 3. Excerpt of the FI service SLA in iAgree syntax