SLA’s and the Cloud – the risks and benefits of multi-tenanted solutions.

Service Level Agreements (SLAs)  are difficult to define in the cloud in part because areas of the infrastructure (in particular the internet connection) are outside of the scope of either customer or supplier. This leads to the challenge of presenting a contractual agreement for something which is only partly in the suppliers control. Further as the infrastructure is shared (multi-tenanted) SLA’s are more difficult to provide since they rest on capacity which must be shared.

The client using the Cloud is faced a challenge. Small new cloud SaaS providers, which are  increasing their business and attracting more clients to their multi-tenanted data-centre, are unlikely to provide usefully defined SLA for their services than that which a data-centre provider can offer where it controls all elements of the supplied infrastructure.  Why would they – their business is growing and an SLA is a huge risk (since it is multi-tenanted breach of one SLA is probably a breach of lots – the payout might seem small and poor to the client but is large for a SaaS provider!). Further with each new customer the demands on the data-centre, and hence risk,  increase. Hence the argument that as SaaS providers become successful the risk of SLAs being breached might increase.

There is however a counter-point to this growth risk though – as each new customer begins to use the SaaS they will undertake their own due-diligence  checks. Many will attempt to stress test the SaaS service. Some will want to try to hack the application. As the customer base grows (and moves towards blue-chip clients) the seriousness of this testing will increase – security demands in particular will be tested as bigger and bigger companies consider their services. This presents a considerable opportunity for the individual user. For with each new customer comes the benefit of increasing stress testing of the SaaS platform – and increasing development of skills within the SaaS provider. While the SLA may continue to be poor, the risk of failure of the data-centre may well diminish as the SaaS grows.

To invoke a contract is, in effect, a failure in a relationship – a breakdown in trust. Seldom does the invocation of a contract benefit either party. The aim of an SLA is thus not just to provide a contractual agreement but rather to set out the level of service on which the partnership between customer and supplier is based. In this way an SLA is about the expected quality demanded of the supplier and with the above model the expected quality may well increase with more customers – not decrease as is usually envisaged for cloud. SLA’s for cloud providers may well be trivial and poor, but the systemic risk of using Clouds is not as simplistic as is often argued.  While it is unsurprising that cloud suppliers offer poor SLA’s (it is not in their interest to do otherwise), it does not mean that the quality of service is, or will remain, poor.

So what should the client consider in looking at the SLA offering in terms of service quality?

1) How does the Cloud SaaS supplier manage its growth? The growth of a SaaS service means greater demand on the providers data-centre. Hence greater risk that the SLA’s will be breached for their multi-tenanted data-centre.

2) How open is the Cloud SaaS provider in allowing testing of its services by new customers?

3) How well does the Cloud SaaS provider’s strategic ambition for service quality align with your desires for service quality.

Obviously these questions are in addition to all the usual SLA questions.

IT departments as “outside”

Joe Peppard, in a recent EJIS paper (Peppard 2007), makes the point that utility computing (along with outsourcing and ASP) are premised on a gap between IT function and the customer/user. “They assume the user is the consumer of IT services, failing to acknowledge the value derived from IT is often not only co-created but context dependent” (ibid, p 338).

Joe suggest that this is founded upon the ontological position that “IT is an artefact that can be managed”, and subsequently that the value of IT is in its possession.  This leads to the obvious claim that rather than focusing on IT management, we should focus on delivery of value through IT. This brings our perspective of IT function (and of Cloud Computing within the enterprise) from the realm of cost-saving efficiencies (as Carr 2003 might suggest) to a focus on contextual practice – supporting work.  As Joe’s the article argues “to seek not to management IT per se, but to manage to generate value through IT”.

Carr’s (2003) argument is thus that the IT function is not needed since this is outsourced to the ASP/Cloud provider. But a more subtle point might be that it needs to instead be pervasive – IT installed within business functions (so as to better contextualise Cloud Services within business practices). While IT services prior to the Cloud increasingly focused on getting the “plumbing” of the organisation correct (i.e. ensuring the email worked, installing ERP, networking the systems), with the use of Cloud services their role must be focused on improving the integration of Cloud services into the work practices of users  - focusing on both social and technical practices which can be supported or enhanced through IT.

We remain fixated on the CIO and IT department as our focus for Cloud Computing.  This seems odd. For what if this role of contextualising IT is better suited to users (who are increasingly technologically proficient particularly around Cloud Services (e.g. SalesForce / GMail)). With the Cloud users are increasingly powerful actors able to engage with, and even procure, IT infrastructure for themselves. How this might influence the role of IT within the enterprise is far from clear but it will certainly lead to new battles and new challenges.

References:

Carr, N. (2003). “IT Doesn’t Matter.” Harvard Business Review: 41-49.

Peppard,J (2007) “The Conundrum of IT Management” European Journal of Information Systems (2007) 16, 336–345. doi:10.1057/palgrave.ejis.3000697