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.