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
performance
contract.
In practice, the term SLA is sometimes used
incorrectly in the
context of contracted delivery time (of the service)
or performance.
The discussion of SLA seems to assume there is no
other description
-- 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
tackling the
details, this is definitely service description.
However, I've
recently seen this become another phrase for
requirements. Other
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
service actually
does?
Problem Management - this is briefly the "process to
handle and
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
infrastructure (e.g.
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
domain of
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
relationship.
Someone will have to figure what this means in the
SOA context
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
the service
policies, or agreed to and incorporated into the
execution context.
Performance Management - Briefly, this "deals with
monitoring and
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
be measured.
Customer Duties and Responsibilities - see Problem
Management, item 2.
Warranties and Remedies - definitely see Problem
Management, item 2.
Service quality
Indemnities
Third party claims
Remedies for breaches
Exclusions
Force majeure
Security
Information Security Policies
Security Audit and Internal Audit
Disaster Recovery - see Problem Management, item 1.
Termination - if the relationship has the unit of
per interaction,
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
description
- 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
service description
Comments?
Ken
On Jan 23, 2007, at 10:23 AM, Jeffrey A. Estefan
wrote:
Hey Ken,
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
keeping the
adopted defn simple and consistent with our scope
(see, for
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
http://
www.oit.duke.edu/oit/sla/index.html.
Cheers...
- JAE
____________________________________________________________________________________
Bored stiff? Loosen up...
Download and play hundreds of games for free on Yahoo! Games.