Why ITIL is not a great fit for SaaS?

"Maturity is a high price to pay for growing up". (Tom Stoppard)

Last week I visited a customer who is a global leader in their market and that had been gradually, over the past three years, transitioning their software to the Cloud. Ther have an impressive operation and reached a maturity level that required them to take the next step - they are hiring a ITIL consultant to help them formalize their operations. I congratulated them on their initiative, but I raised an eyebrow as well.

There are many IT System Management (ITSM) tools out there; some have been around for decades. Most are ITIL based, and since that is what is available, SaaS Operations managers will sometime use the ITIL-based tools that are available – This, of course, is the best case scenario, since many SaaS Ops are managed ad-hoc, with a mixture of documents,  tools, some homemade scripts and open source solutions.

STORM™ was conceived when following regular ITIL methodology just didn’t do the job. It was either too cumbersome, an overkill, or not accurate enough to cater for the SaaS Ops needs.

Initially, SasS Ops is similar to the IT department in many aspects:

Both teams are running the infrastructure, the applications and the service desk for ‘other’ users, writing scripts, configuring, monitoring, responding and in general, ‘keeping the lights on’.

But there are significant variations that make all the difference.

Quantity vs. Quality

The difference between the ratio "application/users" in the two entities is significant. In a typical enterprise there may be hundreds of applications being used simultaneously by hundreds or thousands of users. In a typical SaaS operation there is a single application, or a very small number of applications that are used by thousands, or tens, or hundreds of thousands of users. On top of that, there typically are a large number of environments and stacks that are being used in the enterprise – numerous kinds of databases, operating systems, middle-ware, network boxes, and functional servers. In the SaaS application environment there is usually a single kind of database, a single OS, a single type of application server, etc.

This distinction demands completely different types of staff, skill sets, tools etc. Whereas the Ops group of a SaaS company will know the application and environment intimately, there is no ability of the IT staff to become as familiar with the applications as they would like. They end up knowing a lot less about a lot more. The complexity of the enterprise environment is therefore a hundredfold less manageable.

And that does not even take into account the provisioning of a multitude of devices that IT is responsible for, including desktops, laptops, phones, printers, scanner, etc. taking even more attention from the application management.

The complexity of an enterprise IT environment might justify a CMDB, but that is an overkill for most SaaS operations that could be managed with a simpler Asset Management solution.

Know thy Customer

As mentioned, a SaaS company will deal with a user base that is one or two (or more) orders of magnitude larger than the IT department. Also, where as a SaaS company will have hundreds or thousands of customers, IT deals with at most ten to fifteen different entities within the organization, and perhaps a number of partners as well. 

Every SaaS company is bound by an SLA with all of its customers (some have more bite than others). The SLAs within the enterprise (if they exist at all) are much less binding than a legal document signed with an external entity, and there seems to be a lowered expectation as well as a more forgiving attitude towards the internal IT organization.  

Therefore, while it is becoming more common for SaaS companies to display a Status Page for the users to view the availability and performance of production systems, it is rather rare In IT organizations. 

Centrality of the Ops group.

In a well managed SaaS company, the Operations group is the hub of the activity. They should be communicating with all the organization’s entities (R&D, QA, Support, Professional Services, Finance, Product and Sales) as delivery partners, not as customers. In most business organizations, IT is treated as a necessary evil; as an internal service provider that is always behind schedule and delivering at low performance; it is rare when IT is viewed as a delivery partner.  Whereas the Ops group is expected to participate in weekly customer success meetings, that practice is virtually nonexistent in an enterprise IT organization.

The operations staff at a SaaS company have the ability to affect the product behavior and “serviceability” (and in some companies they actually are part of the MRD/PRD process), while the IT staff at the enterprise can bitch about the problems at best, but have no influence on what features will be included in the next version. 

For example, the application may be spewing out hundreds of Warning or Error messages that are completely cryptic. The SaaS Ops manager has a responsibility to sit with Engineering and map those messages to actionable items.  In the IT world, this is practically impossible for shrink-wrapped applications. 

Service continuity

In ITIL parlance, Service Continuity deals with the ability to provide minimal service levels, and is designed to support Business Continuity.

In the STORM™ methodology, SaaS Service Continuity plays a completely different role. It is designed to provide the continuation of the service to the customers even when the SaaS provider is no longer an existing entity. This could occur under positive circumstances, when the company is acquired by a larger company or under a dire situation, when the company goes under.

Since most SaaS companies are small, many of them with little or zero profitability, and the consolidation of Cloud providers is a daily occurrence, customers need assurances that their services and data will continue to be available – at least for a substantial period.  Therefore, issues such as Financial Viability, Technical Complexity, Operational Complexity, Escrow and Data portability play a significant role and are rarely the concern of corporate IT departments.

In Short

There are many other day to day factors that differentiate IT Ops from SaaS Ops; the above discussion pointed out some of them. ITIL provides an important, structured framework for any IT operations, and SaaS Ops managers will benefit from familiarizing themselves with the principles and the vocabulary. But ITIL is too complex, cumbersome and high level to be of a practical value to the average SaaS operation. 

STORM™ practices flattens and simplifies the ITIL structure, and provide a practical and specific guide for an efficient and effective SaaS Operation.