in one of the analysed BPO SLAs, where the number of incidents post production had to be obtained, and this metric required information from the incidents and the software delivery processes. Again, this metric cannot be modelled using current PPI modelling approaches, since a PPI focuses on just one process by definition.
These limitations could be easily addressed in PPINOT just by doing minor changes in its metamodel. Complex time metrics are supported just by defining filters over time measures, so that idle time, suspend time, calendars or timetables can be taken into account when computing the time for the measure; and by adding a new type of measure, time instant measure, that measures the date and time in which an event takes place instead of the duration between two events.
However, others are left as future work since they require more significant changes. The metrics that involve human resources can be partially addressed using an exten- sion to PPINOT to define resource–aware PPIs [43]. Finally, the metrics that involve different processes can be defined as a derived measure that relates measures in each process instance, but it is necessary to include information on how to correlate process instances when defining them, which is something that will be addressed in future work.
4.5.3
RQ3: Difficulties modelling SLAs
After modelling the iAgree documents and the 52 metrics with PPINOT, we found some limitations concerning the definition of metrics, whereas iAgree and the models used to define business processes, SLOs, penalties, and rewards proved to be capable to model all possible situations.
The application of the proposed approach for defining SLAs of BP services to real scenarios showed up that the parameterising of the guarantee has to be carefully anal- ysed. The scope has provided to be very useful in several SLAs, as SLOs are defined once but they are applied to multiple scopes. Specifically, when the domain of a pa- rameter is not completely known before defining the SLOs it would not be possible to define a single SLO for each parameter value (e.g.: Node variable in the example).
4.6
RELATED
WORK
Regarding the analysed proposals for the modelling of SLAs in chapter §3, we compare the proposals relevant for the modelling of SLAs for BPs. In Table §4.6, we compare the significant features in our scenario. That is, the set of attributes re- quired to model it. First, we identify if they provide a vocabulary for the modelling of non-computational services or just computational, including the description and also the performance metrics. Then, we check if they provide a template model, as WS-
Agreement, to derivate new SLAs from a template. We also evaluate if they define compensation functions to penalize or reward overfulfilling or overfulfilling of SLOs. And last, we check if they provide tooling to support the design and creation of such SLAs.
Among the analysed proposals, we have generic purpose proposals, together some of the domain specific ones. As specific domain proposals, we find Daly [34] et al. , which propose a simple SLA language for CRMs. They describe metrics as customer satisfaction or utility, as the relationship between accomplishment and customer sat- isfaction so they are ad-hoc defined for the proposed domain. Augenstin et al. [7] propose a language to describe logistic services. They mainly focus on functional as- pects. The performance quality is named, but no any attribute or related language is proposed. They propose to model service descriptions from a BPMN using a model to model transformation. Bar-Isaac et al. in [10] describe a business scenario with cost, customer expectations and reputation variables where reward function follows a non-monotonic behaviour (based on satisfying preferences from different customers). The domain is specific to the scenario proposed and it cannot be extended. Cardoso et al. [25] propose a description language for services that includes business charac- teristics together with technical or operational parameters. Unlike our proposal of managing a business process as a service to define their SLA, this work is focused on managing services including business perspective.
There are a number of proposals which are independent of the domain, but they do not address business processes or non-computational domains. These are SLA* [93], which is a domain independent language generalizing other specifications such as WS- Agreement, WSLA or WSDL. The document structure is similar to WS-Agreement and it can be extended with the requirements of each domain. However, as far as we know, there is not domain proposal to describe non-computational services. Rule-Based Ser- vice Level Agreement Language (RBSLA) [143] supports specific vocabularies defined externally. They provide an SLA document structure supporting guarantees with com- pensations but there is no proposal with a business domain vocabulary to validate the proposal. Forster et al. [63] propose a model for business processes and quality require- ments as temporal logics problems. However, they do not handle with other kind of measures and they do not provide a compensation language. Sauvé et al. [161] pro- pose a methodology to calculate SLO thresholds to sign IT services SLAs according to service function cost from a business perspective. However, this proposal is focused on the cloud domain and how the cloud performance metrics relates to business costs. Kieninger et al. [95] describe a categorization of IT services and outline a mechanism to obtain efficient SLOs for them. However, they do that in a conceptual level and do not detail how they can be formalised to enable their automated management. Therefore, the service description and SLOs are limited to the proposed services.
And among the proposals which specifically address business processes descrip- tion and metrics are Linked-USDL Agreement [70], which specifically addresses non- computational and computational domains. They use ontologies to describe service
4.6. RELATED WORK
Proposal BP Metrics GT Template Comp. Tooling
SLA* [93] [34]
x
x
X X X X Linked-USDL Agreement [70] X X X X Xx
CPPA [135] X X Xx
x
X RBSLA [143]x
x
x
Xx
X Daly [34]x
x
Xx
x
X Augenstin [7] Xx
Xx
x
X Nguyen [133] Xx
x
x
x
X Chau [29] X X Xx
x
X Forster et al. [63]x
x
Xx
x
x
Sauvé [161]x
x
Xx
x
x
Kieninger [95]x
x
Xx
x
x
Cardoso [25] Xx
x
x
x
X Bar-Isaac [10]x
x
x
x
Xx
Our Proposal X X X X X XTable 4.4: Metric definition models for BPs
and metrics together with constraints for the guarantees. However, the scenarios mod- elled are syntetic and they do not provide tooling support to monitor SLAs. Nguyen et al. [133] propose aligning the SLAs for the different services/tasks with different layers: business, people and technology. So they describe different categories for SLOs and for SLA in the different layers and check how they align with the other layers. However, they do not provide a generic language for service description in non compu- tational domains. Collaboration-Protocol Profile and Agreement Specification (CPPA) [135] (which was published in 2002), which complements ebXMLBP for commerce col- laboration. They focus on electronic collaboration so they provide a specific language for electronic tasks, such as document exchange protocol, message system, secure com- munications, etc. Chau et al. [29] propose to define performance metrics and goals based on business processes. they relates SLAs and business process artifacts where guarantees over the process are defined through process events.
The namely attributes in the table are: (i) BP, if the proposal enables to describe the non-computational services and business processes or it is related to a specific com- puter domain, (ii) Metrics if they provide performance generic metrics for non compu- tational services (if they are defined ad-hoc, we considered that they do not support non computational metrics), (iii) GT if they provide a language to describe guarantees over metrics in non computational services (iv) Template, if they consider the creation of SLAs derived from a Template, (v) Comp., if they provide compensations definitions and (vi) Tooling, if they provide tooling support to create SLAs.
As we can see in the comparison table, just some of the proposals provide a lan- guage to describe non-computational services or business processes and, amongst them, only three [70],[135],[29] provide a language to describe metrics over them. Further- more, almost none of the agreement models consider the definition of compensations.
Therefore, in summary, none of the proposals cover the required expressivity for our model, including service description, performance metrics and compensations, neither give support to the lifecycle.
4.7
SUMMARY
With this proposal, BP SLAs can be modelled by combining mechanisms for mod- elling computational SLAs with mechanisms to model business processes and PPIs.
Furthermore, our proposal to model SLAs combines well founded approaches and standards for modelling computational SLAs and PPIs. Specifically, we rely on WS- Agreement [6], which provides the general SLA structure, BPMN [138], which is used to model the business process related to the service, PPINOT [41], which allows the definition of metrics, and iAgree [126], which provides a language to define SLOs and penalties.
The application of the proposed approach to a number of real scenarios allowed us to conclude that our approach is able to model all possible situations in these sce- narios except for some identified limitations concerning the definition of SLA metrics. Some of them could be solved by applying minor changes to the PPINOT metamodel. However, other limitations require more significant changes that shall be carried out in future work.
5
M
ANAGEMENT OF
SLA-D
RIVEN
B
USINESS
P
ROCESSES
Never promise more than you can perform. Publilius Syrus ( 85 BC - 43 BC),
5.1
INTRODUCTION
In the previous chapter, we discussed the model to describe SLAs for Business Pro- cesses. There are a number of tools to support the execution of business process (or are aware of process flows). However, although some current existing PAISs (Pro- cess Aware Information Systems) support multiple customers (e.g. BonitaSoft1), they do not provide facilities to manage their SLAs as a first level citizen. In this chapter, we analyse how to provide automated support to the SLA lifecycle in PAISs. A PAIS with SLA–aware capabilities, i.e. a PAIS that manages explicit definitions of SLAs, can enable the sharing of monitoring mechanisms, process configuration [179] or optimise the management of shared resources used by different parties.
We focus on the late phases of the SLA lifecycle (described in Subsection §3.3.2) as the SLA creation phases have been deeply analysed by Resinas [153], Pablo Fernan- dez [60] and Muller [122]. Regarding these stages, after reviewing the scenarios, we analyse the impact of deployment of the SLA in order to describe how (i) configure the service according to the SLA and then we identify the requirements to (ii) monitor the accomplishment of SLA during the fulfillment phase. Then, we propose how to extend PAISs to support these operations through SLAs.
On the one side, regarding monitoring, we propose extend an SLA–aware system to instrument the monitoring of the metrics for different parties and SLAs. Doing so, we can provide different dashboards for each customer, aggregated stats for the system provider, or create alerts based on the accomplishment of the SLOs. On the other side, regarding configuration, we describe an architecture to extend a BPMS that configure the process execution to meet the SLA terms. We specifically consider BPMS platforms because the process execution depends on the supporting system. This architecture
ruled
by
Chapter 4
supported by
Governify
Business Process
PAIS
Formalization Monitoring Adapt Chapter 5 Chapter 6 iAgree SLA Governify
PAIS
Monitoring Adapt Chapter 5 Natural Language SLA Instance SLA Analysis Chapter 6 Instance SLA Instance SLA MonitoringFigure 5.1: Contributions background
has been developed as a prototype in Open Source BPMS Camunda. Other operations could be considered during the deployment and fulfillment phases, such as optimiza- tion, but it is out of the scope of the current dissertation, although some initial results are included in Appendix §B.
The contribution of this chapter regarding the dissertation is highlighted in Figure §5.1.
In the previous chapter, we focused on the formalisation of SLAs such as the one described in the STR document proposed by APC for IT maintenance outsourcing, that is then discussed with the potential contractors. As a result, the required performance goals (e.g. maximum times to solve different tasks) or the service execution options (e.g. executing documenting task or human assignments for certain tasks) are nego- tiated with each contractor and different agreement offers are proposed which result in different final agreements with each contractor (after the public contract tendering). The agreement offers have to be consistent with the STR, which means they should guarantee similar or even more restrictive performance terms but they can differ from one contractor to another. The required goals and related penalties are again depicted in Figures §5.1 and §5.2.
In this scenario, the APC provides different tools which act as PAIS to support the task execution for all the contractors and capture all the service relevant events (plan interventions, start of related tasks, ...). As the terms agreed with each contractor vary, when the SLAs are deployed, the supporting tools have to be aware to their different