Example of a Modeled Process

  The base of service level agreements design are customer processes which use and manage the service. The operation processes of the provider must fulfill the SLA, but their implementation is not an element of the SLA.

A resulting process model for a simplified example from the presented scenario is shown in figure . The example model is a part of the problem management class. It defines the process of fault identification, notification and resolution. The models of the complete process including cooperation during fault identification, documentation, prioritization, exception handling, escalation mechanisms, etc. would go beyond the scope of this paper. During identification of different activities the necessary resources and data must be defined which is also not detailed in this example.

[Fault Notification Process]Fault Notification Process   [r][width=10cm]bilder/example

A fault can be detected by both, customer and provider. Therefore, two initial processes exist. Depending on the party that detects the fault the process starts with the fault detection on the customer or the provider side.

If the customer detects a fault, the next activity is the notification of the provider. If the provider detects a fault the customer is notified by the customer notification process. The customer notification is modeled as a composite task because it is a basic process controlled by dynamic values like the message and the receiving role to adapt to the respective situation.

At this point the two paths join. The next activity is trouble ticket creation. Then, the concurrency construct models the fault resolution with regular feedback to the customer on the current state. The feedback path is an iteration construct monitoring the trouble ticket state. As long as it is open the notification process is repeated. The feedback interval is realized by a post-condition.

The fault resolution path starts with the fault identification activity. This activity is separated from the fault resolution because the customer usually wants feedback on the estimated duration and scope of the service malfunction as soon as possible which therefore is modeled explicitly by the customer notification process.

The identification and resolution activities by itself are of no interest to the customer, but the customer wants to define quality criteria on this activities. Therefore, they must be modeled. After the problem is solved the trouble ticket is closed which ends the feedback loop and the customer is notified of the resolution in the final customer notification process.

The resulting process model including the data and resource definitions is part of the service level agreement. In the next steps data and resources are mapped to properties, variables and interfaces. The necessary interfaces are easy to find because each domain boundary crossing is visible in the workflow graph. The only new interface added by this process is the fault notification interface which could be mapped to a telephone interface.

All requirements for the service level not expressed by now must be specified as constraints. For each combination of activities it is necessary to consider if there are important constraints which should be represented in the SLA. In the presented example process a constraint on the total time from trouble ticket creation to trouble ticket closing should be covered by a constraint. Additionally, to limit the amount of service failures, e.g. a constraint for the number of trouble tickets open simultaneously and in certain intervals is needed. Several other constraints are thinkable, too.