What’s in a Service Level Agreement? March 17, 2009Posted by CK in IT, Research.
Tags: eContracting, QoS, Service Level Agreements, SLAs
add a comment
Here’s a link to a short post I wrote for the site of the project I am working on. Comments are welcome 😉
On the real-world infeasibility of fully-automated SLAs June 30, 2008Posted by CK in Design, IT, Research.
Tags: Service Level Agreements, SLAs
add a comment
In the last few years I have been involved, to a certain extent, in digital service ecosystems and e-contracting frameworks. In other words, automated Service Level Agreement (SLA) management. In this sense, management includes things such as planning, optimization, negotiation, provisioning, discovery, monitoring, reacting on exceptions, re-planning/re-negotiation/re-provisioning, and so on, and so forth.
Although in general this seems to be feasible from a technical point of view (despite all the theoretical problems, which are always affected by the business reality as well), it is clear that human intervention and ratification will always be needed. It is not possible for managers to accept that a machine is making decisions that have a direct financial impact (good or bad), even if theory says these decisions have solid footing. Another problem has to do with the very definition of rules to express what is binding to the parties involved and what are the penalties depending on the exceptions. Coming up with the sheer terminology for a task like this is a huge thing by itself. The real-world (i.e. non-digital) legal system took hundreds of years to establish the relevant nomenclature for business law, and I guess there are still significant gaps (becoming larger as the world and business itself changes). Forming digital representations of real-world terminology and metrics which sometimes are abstract enough to require arbitration in court, is a very challenging task; Persuading managers to accept systems that make use of them, is probably impossible.
Then comes the issue of trust and (trusted) 3rd parties. A non-automated, static (i.e. manually managed) SLA for digital services is easier, in the sense that the parties involved agree a priori on the tools, metrics and exact numbers to use for the specific use case. Although it might be possible to define a one-fits-all referee for generic SLA compliance monitoring, it still looks like the average manager does not accept the jurisdiction of an external monitoring entity for making financial decisions that affect his/her business.
Then there are also the reflections of (technical) negotiation issues onto automated, dynamic SLAs. The network is an unreliable medium for transferring information. Message queues are useful, but they only guarantee delivery of a message; they cannot do anything about totally dumb agents which assume that sending a message means the other end received it immediately or almost immediately. Truth is, the message might be received with a significant delay; by that time, the agreement offer or the agreement document itself may be useless for the receiving party. After all, automated SLAs are build for a highly dynamic world of services, where the landscape changes from one minute to the next. Timestamping is not a solution, but we do have GPS after all, so it can be mitigated to some extent.
The above are only some of the problems, just to point out that direct application of real-world contracts on the digital world is not straight-forward. The last word must always belong to a manager, just like the real world. At least for the time being, noone accepts that this last word belongs to a computer system. It makes sense, but it is still a pity.