Think about the last time you were in a foreign country and didn’t speak the native language. It’s exhausting and frustrating to not be able to express even the simplest of ideas without resorting to excessive hand-waving or Englishification. Complex thoughts are usually deconstructed into simple caveman-esque noun + verb combinations. While the general intention can be clear, the nuance that accompanies the intention is often lost in translation.
I see the same frustration today with sourcing buyers who want to engage as-a-service (XaaS) providers. Although many of these initial conversations go well, just as many start out as if the parties were speaking two different languages. This is especially pronounced if IT is the buyer or is engaged in the buying process. In my experience, these conversations often devolve into “they don’t know what they are talking about” when, in fact, both sides are quite savvy in their specific area of expertise.
This expertise is often very different, and has very different motivations.
ITIL: aligning and controlling services-based work
ITIL was developed based on the idea that internal IT needed a framework to improve quality and financial responsibility of the services it was providing back to the business. As ITIL adoption grew, service providers recognized the need to adopt the ITIL framework as a way for them to not only improve quality and financial responsibility internally, but also extend this rigor to their customers. ITIL became the de facto “handshake” that services providers and services buyers use to communicate across the entire IT landscape — from operational areas such as incident and problem to more strategic areas such as service portfolio management and demand management. While there are often differences in “dialect” that can be sorted as part of a services transition, the underlying language is the same.
We’ll call this language “ITIL-ish.” ITIL-ish is focused on defining a standard framework to align and control the risks inherent in the technology. ITIL-ish discussions are usually focused on creating business alignment, increasing governance, and reducing unproductive and costly overruns in IT services (of which there are many).
APIs: exploiting new opportunity inherent in platforms and data
Web APIs (or web services) were developed based on the idea of exposing business functionality to developers over the Internet via a defined contract. APIs expose the functionality without exposing the underlying implementation of the functionality, making it easy for developers to “subscribe” to capabilities and data they would otherwise have had to build themselves.
Web services have exploded over the past five years and have turbocharged the growth of the cloud by serving as the “glue” between remote cloud services. Web-based APIs have become the new de facto “handshake” that cloud-native XaaS providers use to expose their business functionality to users. While this handshake most often takes place in consumer applications like Google, Facebook and Twitter, the use of more business-focused APIs is growing at an astounding rate: Salesforce generates nearly half of its revenue through its APIs; Amazon S3 storage service houses more than 1 trillion objects, a majority of which were added via the AWS API; Workday allows users, with the click of a button, to expose their reports as a RESTful web services.
API-ish is a language spoken by developers. It’s focused on exposing a framework to exploit functionality and data inherent in the platform. In the enterprise, API discussions are often focused on creating new business models and unlocking what was once closed to employees, customers and partners.
Lost in translation
Up until fairly recently, the ITIL and API worlds coexisted peacefully, mainly because neither side was even aware of each other’s existence. However, that has changed, and changed in a big way, with the massive wave of adoption of software- and infrastructure-as-a-service within the enterprise over the past 36 months.
For the most part, when IT services buyers encounter a XaaS provider, they expect that provider to speak ITIL-ish. When that doesn’t happen, the provider often is dismissed out of hand. However, when the XaaS provider speaks API-ish to business unit leaders or developers, it’s a revelation for the buyer: “Finally someone in technology understands what I’m saying.” These conversations progress, and all the while IT systems administrators and sourcing managers, those most likely to speak ITIL-ish, are left out in the cold.
However, it’s these folks that XaaS providers most often encounter after they’ve been vetted by business buyers. This is where the language barrier is most pronounced, and where the hand waving usually begins.
IT services buyers expect to hear from their providers how those providers are going to align and control services to reduce risk and cost, while XaaS providers want to talk about how they can leverage their platform to create opportunities to drive revenue growth or eliminate internal barriers to said growth.
The tricky part is figuring who speaks what language. In general, the following holds true:
- Outsourcing providers are fluent in ITIL-ish.
- Born-on-the-web XaaS providers are fluent in API-ish.
- Traditional software providers don’t really speak either language well yet, but are learning both as they transform to delivering their software as a service over the Internet.
An important note: XaaS providers may actually be quite savvy ITIL practitioners internally, but if they are, this fluency is not exposed to customers, as the internal operations of XaaS providers is generally a black box to buyers. Web-based APIs are the way these providers expose their services to their buyers.
A path forward
So, what’s a buyer to do given that we’re in a time and place where two important internal constituents, both with valid and important points of view, speak two different languages?
Understand and accept that API-based XaaS adoption will continue at a torrid pace, and yet ITIL-based managed services buying will continue as well, albeit at a slower pace. The two will co-exist for many years to come. The key is having a framework to determine which delivery model is appropriate for which business process or application.
Some processes may warrant a direct relationship with an XaaS provider. In those cases, you’ll need business- and developer-focused subject-matter experts who can speak in API terms.
An example is enabling developers to work with Amazon, Google and Twitter’s APIs to enable rapid prototyping of customer-facing mobile applications. In this scenario however, IT, procurement and legal need to be willing to accept more risk given that nearly all API-enabled platforms are multi-tenant, shared platforms, thereby reducing the leverage buyers have to change the behavior the supplier. However, the payoff of enabling the democratization of IT can be substantial, so this model should not be dismissed out of hand simply because these providers won’t agree to sign your master services agreement. There are ways to manage risk while still exploiting these services.
Some processes may warrant a XaaS solution but need a light layer of ITIL-based managed services on top, while capitalizing on the underlying platform APIs. An example here could be using Microsoft 365 for collaboration services, but hiring a third party to take care of routine ITIL-based Exchange administration responsibilities. Developers can tap into Microsoft’s API framework for custom collaboration applications using their API language skills, while IT administrators can work with Microsoft, using their ITIL language skills (which Microsoft is still learning, by the way).
And, finally, some processes may warrant a completely outsourced relationship where all responsibility is transferred to the supplier. This conversation would take place almost exclusively in ITIL-ish, because limited platform-based services are likely to be involved in the transition. These conversations should be managed by those that speak ITIL fluently, as this is how the provider will communicate as well.
Are APIs the new ITIL?
Providers are going to continue to aggressively drive towards standardized, multi-tenant web based services supported by increasing layers of technology automation over human-based services. More platform-based services means more APIs to expose and exploit the platform. This is simply where the world is headed — labor arbitrage based services have peaked. Platform-based automation is upon us, so in some ways, you can argue that yes, APIs are becoming the new ITIL.
Will APIs negate the need for ITIL? Absolutely not. In some ways, you could argue that the need for ITIL will increase as buyers continue to slice up traditional technology towers using out-tasking. These “micro” services need to be evaluated, sourced, orchestrated and governed, all of which result in more of a need for an overarching framework to pull them all together into a cohesive whole.
My recommendation: become bilingual.