Development as contract/SLA management

I’ve just heard an interesting opinion, one which I wholeheartedly agree with, from Andrew White (GM and EVP – Americas, for the SaaS-based EasyVista Service Management platform). Andrew thinks that developing IT services for the business is increasingly a matter of managing contracts and SLAs (Service Level Agreements), rather than managing technology or writing code. Increasingly, we will give our technology to expert professionals to manage and buy it back as hybrid technology services (probably defaulting to cloud platforms but with an on-premise option available when required by regulation or justified by the business). When you buy technology services, they will (or should) come with appropriate contractual obligations and SLAs for security, business continuity, elasticity and so on.

The problem, of course, is that the people in many current organisations responsible for technology understand the computer science well-enough (and you do need someone able to ask the hard questions of your service providers) but don’t understand negotiating SLAs and contracts. The last time there was a serious AWS (Amazon Web Services) outage, for example, it seemed to me that Amazon had defined its SLAs fairly well and delivered to them; but that some customers, who apparently lost their business systems for an unacceptable period, hadn’t read or didn’t understand the SLAs they’d signed up for. You think that Amazon should have made sure that its customers had done their ‘due diligence’? Well, only if its customers had paid for a bit more than just access to cheap technology.

‘Technology as a Service’ can deliver as much governance, business continuity and service level assurance as you want, but this needs to be agreed as part of service acquisition; and an SLA guaranteeing 24×7 availability, say, will cost more than one just promising ‘best efforts’ at 24×7 service availability, not counting planned downtime. If the only consideration for service acquisition is initial cost, you will probably find that you also acquire expensive risk management issues, later on. The value of technology as a service lies in increased business agility, because, with an appropriate contract, services can be turned on or off as and when they are needed; and better governance, because negotiating an SLA concentrates the mind on important questions (which people often overlook for an in-house managed, on-premise solution). Get the service governance and SLAs right and a hybrid services solution will probably be cheaper than an a conventional in-house managed, on-premises solution—but if you just think about costs, you probably won’t get the service governance and the SLAs right.

What I’m really saying here, is that operating in the services world needs a certain level of business maturity in the organisation, across both IT and the business. Andrew says that, in the last couple of years, he has seen this level of maturity being achieved more widely; and I confess that this rather surprised me. Digging deeper, however, it seems that EasyVista is effectively focused on about 11k potential Enterprise customers it identifies (in USA and EMEA) as needing EasyVista’s solutions. I can see these as being increasingly mature—but the majority of UK plc’s aggregated commercial value, for instance, actually resides with the SMB (small/medium business) sector and I doubt if maturity is as common there (on the other hand maturity is less necessary in a small company where everyone knows everyone else).

That all said, I don’t see maturity as a yes/no thing—it’s a continuing process-improvement journey, and I’m sure that SMBs, and the less mature enterprises could benefit from studying ITSM good practice—there is a lot to be learned from ITIL service management even, as long as you can abstract to the model behind the current practices, where necessary. There is an interesting Agile ITSM case study here. This is an independent study of the implementation of Easyvista by Domtar, which moved from developing 90% of its ITSM systems using external consultants (with 10% of development in-house) to a state where 90%–95% is ‘configured’ (not ‘developed’) in-house (although 5%–10%, where appropriate, is still developed externally).

Well, I’m not surprised that the new approach is cheaper (I can remember working with external consultants; and the governance of what you get and the standards used can be as big an issue as the cost). Even so, I think that a quote from Bob Stambaugh (Manager, IT Service and Asset Management at Domtar in the USA) highlights the true value of the services-based (SaaS) approach: “This technology has given us the flexibility to do everything we ever wanted. It is not perfect and like most things probably never will be. However, it has allowed us to reshape the way we deliver some of our IT services. It has allowed us to integrate a new way of doing things (SLA, Service Catalogue) that we thought would be impossible with our old tool. For the first time we are able to shape the tool to our process and not the other way around”.

Of course, Service Delivery has been a bit of a fashion mantra recently, but it is sometimes seen as just a technology thing. In reality, it’s a business-led approach to managing the well-governed delivery of (increasingly) automated business outcomes. You need to get the organisation’s culture right (and remove IT and business silos) before adoption of service-based approaches will be successful; and visibility and transparency are important. Andrew points out that “if those pesky AWS servers are on a credit card, perhaps the credit card should be a Configuration Item; and you can then use configuration management rigour and Change Advisory Boards to manage the cloud estate, so as to orchestrate a single ‘digital business’; instead of a fragmented collection of disjointed processes”. And, more, remember that no contract or set of SLAs can never define service delivery completely—the customer organisation needs a good cultural match with its service providers and needs to build long-term relationships with its providers; as well as to formulate and manage its contracts and SLAs well.