In contrast to the customer, the service provider
needs to understand the technical aspects of the ser-
vice. In order to decide how to deploy provision and
manage the service, the provider needs to consider
two things: the terms of the SLA and his BLOs.
From this he can derive the policies that are used to
manage the service. These policies will form part of
a policy-based management framework that uses
event-condition-action type policies (Sacks et al
2003). Events originating from the service that need
to be passed to the customer must cross the border
between technical and business perspective at the
service provider. To ensure that the customer under-
stands the event, it must be placed into context. This
context is encapsulated within the SLA and therefore
events have to flow across the service provider’s
business space before they are passed on to the cus-
tomer.
As all management activity of the service is hid-
den from the customer how can the customer be con-
fident that the service provider is not violating the
SLA terms? To answer this it is important to under-
stand the SLA content.
A common error is too complex an SLA as dis-
cussed in (Twing 2005).
“Poorly structured SLAs can lead to interesting,
problematic and unintended results. One common
mistake is to create too many SLAs. This can dilute
the effect of the critical few drivers that most affect
the business.”
We therefore believe that the terms in a SLA
need to be set in a business level language describ-
ing performance level guarantees that are directly
linked to BLOs. Many of these will be perceivable
by the customer during service consumption, but
some may not. One way of solving this would mean
to give the customer access to technical detail. We
strongly believe that this should be avoided, as pro-
viders need to maintain the flexibility to provide
services dynamically and efficiently utilise their
infrastructure. Both of these are vital to ensure the
provider has a viable business model. We believe
that the customer needs to trust the service provider
to be willing to enter a business relationship. Our
proposed solution draws on existing industry prac-
tice of a rigorous auditing process.
By describing and offering services in business
language it is easier to compare service functional-
ity, especially for non-technical users. This compa-
rability enables customers to “shop around” for best
offers on similar services.
If the service consumer has the desire and tech-
nical understanding to set requirements against the
technical performance of the service, those require-
ments can be expressed in more technical terminol-
ogy. However, the provider may impose extra condi-
tions. As the provider has to give up some flexibil-
ity, it will cost more to provide the service. Secondly
the provider might not provide an open view to the
management information of his services but instead
may filter the events passed on to the customer to
maintain confidentiality. For example, the mere ex-
istence of an event may already disclose sensitive
information to competitors.
SLAs will be used to manage the risk and expec-
tations of both parties. They will become increas-
ingly important if a market is to develop.
4 CURRENT SLA
SPECIFICATIONS
Within the GRID research community a number of
efforts have been made to define the structure and
content of SLAs. The two leading efforts within the
web service community are WSLA (Ludwig 2003)
and WS-Agreement (Global Grid Forum 2004).
While each of the two incorporates some useful and
necessary features of a SLA, neither of them ex-
presses all that needs to be in a SLA.
Another interesting approach to create precise
SLAs is SLAng (Lamanna et al 2003 & Skene et al
2004). A SLA in SLAng describes the two involved
parties and the responsibilities of service consumer
and provider. SLAng is designed for a specific sce-
nario and contains fairly rich detail of the service
and how it is run.
We believe the focus of a SLA needs to be the
business objectives of the consumer.
The currently proposed SLA structures, WSLA,
WS-Agreement and SLAng, are all too focused on
the technical aspects of a service and do not attempt
to cover the service’s business aspects. We believe
SLAs should also contain non-functional terms.
These are important to build the business relation-
ship with the customers and provide a differentiating
factor between service providers.
The EU IST 6
th
Framework project NextGRID
contains work in the area of SLAs. The current focus
in NextGRID is on creating a representation of
SLAs that contains both functional and non-
functional terms.
THE INCREASING ROLE OF SERVICE LEVEL AGREEMENTS IN B2B SYSTEMS
125