that are not measurable. This also applies to all
policies/contracts. Looking at the measurables in the
configurables. The configurations are applied to
devices and services during the course of execution.
defined in the SLA. The underlying mechanisms that
services. As for those things that are not measurable
the case of a breach of the terms of the SLA.
policies are just policies and not configurables.
safe with classifying that as part of the SLA.
Still chewing on SLA.
Jeff - was the Duke work done with SOA in mind or a
more general idea
for IT delivery? The Wikipedia article also seems
to indicate the
general IT case:
Service Level Agreement (SLA) is that part of a
service contract in
which a certain level of service is agreed upon. An
SLA is therefore
not a type of service contract, but a rather a part
of a service
contract. A service contract can contain zero, one,
or more SLAs. A
contract containing SLAs is usually referred to as a
In practice, the term SLA is sometimes used
incorrectly in the
context of contracted delivery time (of the service)
The discussion of SLA seems to assume there is no
-- in our case, no service description.
Let's look at the list Danny provided (from
index.htm) because that seems (overly) exhaustive.
Definition of Services - while we haven't finished
details, this is definitely service description.
recently seen this become another phrase for
than the idea of description-driven development (I
tell you want I
want and you agree to build it), is there a
rationale for capturing
what were supposed to be requirements vs. what the
Problem Management - this is briefly the "process to
resolve unplanned incidents". This needs more
thought on how it
relates to SLA. My initial thoughts are:
1. Some handling of faults are based in the
messages dropped in transport) and need to be
resolved at that
level. The power utility does not give me detailed
of how they will
handle downed transmission lines.
2. The more endpoint related remedies seem to be the
lawyers. To a certain extent, this is where the
UDDI model has run
into problems because businesses don't get things
from other business
without laying some groundwork for the business
Someone will have to figure what this means in the
because everything will grind to a halt if we have
to wait for the
lawyers for every new service interaction.
So let's assume there are some standard answers here
and those are
either embedded in the cloud, referenced as part of
policies, or agreed to and incorporated into the
Performance Management - Briefly, this "deals with
measuring service level performance". I don't think
this can be done
without reference to some form of NetOps (network
operations) or ESM
(enterprise service management) that will be the
recognized agent to
collect metrics. It does not make sense to demand
things that can't
Customer Duties and Responsibilities - see Problem
Management, item 2.
Warranties and Remedies - definitely see Problem
Management, item 2.
Third party claims
Remedies for breaches
Information Security Policies
Security Audit and Internal Audit
Disaster Recovery - see Problem Management, item 1.
Termination - if the relationship has the unit of
then termination is simply no more interactions.
Beyond that, see
Problem Management, item 2.
So, it would appear that
- most of these items relate to policy and, as
appropriate, should be
referenced in the "policy section" of the service
- things specific to a particular set of
participants would be
captured in the SLA, but don't overload this to
include all contract law
- things needing to be measured can be part of SLA
but they should
coordinate with what can be measured
- things that are clearly description and are
relevant to any
interaction no matter who are the participants
should captured in the
On Jan 23, 2007, at 10:23 AM, Jeffrey A. Estefan
This is certainly relevant to our service
description and service
management models. I mentioned SLAs in passing in
the service mgmt
model but did not explicitly define it. Recommend
adopted defn simple and consistent with our scope
example, the Wikipedia defn for SLA). The
important point being
that the SLA is "part" of the service contract and
not a "type" of
service contract. It's also important to
differentiate SLAs from
OLAs and a decent distinction is captured at
Bored stiff? Loosen up...
Download and play hundreds of games for free on Yahoo! Games.