[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] definition of 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 http://www.sla-zone.co.uk/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.
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 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
On Jan 23, 2007, at 10:23 AM, Jeffrey A. Estefan wrote:
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508