I've been busy for the last few weeks - but I thought I'd post more on the "as a service" field and annoy Robert "r0ml" Lefkowitz (a wonderful and talented person) by introducing more acronyms.
Now "as a Service" or "X as a Service" (XaaS as it's often called) is fundamentally about creating a SEP (someone else's problem) boundary. In homage to Douglas Adams, by SEP, I mean the outsourcing of a client responsibility to the provider - in terms of a service, what was once done by a client is now done by the vendor ... it's someone else's problem ... though to be safe, assume it will fail and plan accordingly.
I normally talk about a narrow range of these services, however for the purposes of this post I'll extend up and down the XaaS "stack" to show the concept. This isn't about payment or worth mechanisms (utility or subscription or otherwise) - I'll deal with those another day.
To begin with I thought I'd outline the "stack" and then in a series of posts go through each level in some more detail. These concepts are framed from the viewpoint of cost of doing business activities (CODB) and not competitive advantage or transition.
The "stack", at this moment in time, can roughly be broken into :-
- BaaS - Business as a Service
- OaaS - Organisation as a Service
- PaaS - Process as a Service
- DaaS - Data as a Service
- SaaS - Software as a Service
- FaaS - Framework as a Service
- HaaS - Hardware as a Service
- IaaS - Infrastructure as a Service.
- NaaS - Nothing as a Service (the default position).
The use of these services at any level, for any particular instance, changes the SEP boundary - that which was the responsibility of the customer now becomes the responsibility of the provider.
At the top level of the stack, Business as a Service - the provider is responsible for the business, its organisation (marketing, operations, facilities management, manufacture etc), processes, the data it uses, any software etc. The customer's activities include initial funding and the desire to do something and their main responsibility is for the choice of vendor. This is the concept of virtual businesses, niche or otherwise and is something which I discussed at length with Matt Webb and Suw Charman, sometime last year. Though none truly exist in the space today, it has analogies to the VC market and is worth just noting as a concept.
Next there is Organisation as a Service - with the provider offering a complete organisational function for the business such as marketing, manufacturing, HR, legal, facilities, supply & distribution, finance etc. There are a few examples of these outsourced arrangements.
Process as a Service covers a finer structure, whether it's a marketing programme, translation, lead management, customer support, design, advertising, strategy, manufacture, governance, market analysis, recruitment, billing or payroll etc. Here we start to see a larger number of companies set up to deal with such arrangements either within discrete parts of the organisational structure or as a whole. There are the first signs of utility or subscription models for payment. This process area, often a mix of interrelated internal and external processes, given meaning through the organisational structure, is the remit of business process management. The use of external services is commonly known as BPO (business process outsourcing).
Data as a Service means simply the provision of data. The customer is concerned about the business, its organisation, its processes and how internal data combines with vendor provided data. The provider of such a service is concerned about providing the data and any application, framework or supporting hardware. An obvious example of this today includes business and analyst reports. I specifically call it data rather than information - as data is only given meaning through relational connections within the context of a business.
Software as a Service is a relatively new field (and more aptly called Application as a Service). The customer is concerned about the business, its organisation, its processes and its data. The provider of such a service is concerned about providing the application for the data, the framework the application runs on and the hardware that support this (e.g. SalesForce).
This extends further into Framework as a Service (e.g. Bungee Labs) where the customer is concerned about their code and data whilst the provider takes care of the rest.
Then we have Hardware as a Service (e.g. Amazon EC2) where the customer is concerned with their code, data, frameworks, network configuration, operating environment etc and the provider is concerned with virtual machines or storage etc.
Then we have Hardware as a Service (e.g. Amazon EC2) where the customer is concerned with their code, data, frameworks, network configuration, operating environment etc and the provider is concerned with virtual machines or storage etc.
Infrastructure as a Service means simply space and basic infrastructure (such as power, air con, telco etc) which there are countless examples of hosting companies offering this.
Now most of the time this is a pick and mix exercise. Most companies rent infrastructure or at least some element of it and in many cases infrastructure is provided on a utility basis. Some companies have moved higher up the stack and started to shift the CODB-like activities in discrete areas to other providers. The reason for this is that all of these activities are common and suffer from issues of scaling, resilience, availability, management, operations, investment etc and are more economically provided by larger scale specialists.
Now this "stack" is not a fixed model - in my view it's temporal. Over time I expect that SaaS, FaaS and HaaS will all be considered infrastructural services in much the same way that power, water and telco have. However for the purposes of this discussion it is useful to separate them out.
Also this stack isn't just related to the use of digital information. Manufacture is a process which at its core turns data and raw materials into a product (inputs to outputs). The use of rapid manufacturing techniques, on demand manufacture and fabrication technologies are likely to make significant changes in this area and lead to commoditisation of the manufacturing process - another topic, another day.
The key issue to bring up at this point is the concept of portability between service providers or fungibility of any particular service at any level of this stack. I describe this idea as "fungitility". Robert would be proud of me or maybe not.
Fungitility
Fungitility
Adjective
From the Latin fungi 'perform, enjoy' and utilitas 'usefulness'
The freedom and portability to move from one service provider (including internally) to another without hindrance (including excessive cost, time or effort), without boundaries and predicated on the existence of an equivalent service or services.
Whilst there are obvious cost benefits to moving CODB activities to a larger scale specialised provider, there is a risk associated with a lack of fungitility. Having supply and distribution or your CRM service or your governance processes locked into one provider can create significant risks should the provider either change pricing, personnel or even suffer a major outage of some form.
Fungitility reduces this risk and it is why open, free and common standards provided by multiple common resource or service providers are essential.
Before I go, I want to re-emphasise this is only to do with common or ubiquitous types of necessary activities and processes. This is only to do with CODB, which should be focused on cost and fungitility. The ideas of Taylorism are only applicable to commonly repeated activities and at a service provider level this means ubiquitous within the industry.
A novel and new activity, a potential source of competitive advantage (CA), may make efficient use of some CODB-like activities. It might even be a commonly repeated activity within an organisation - however by its very nature it is not suited for a service provider. It is neither ubiquitous nor necessary (in the short term). For such activities I would promote the use of worth based and VC-like techniques.
From the Latin fungi 'perform, enjoy' and utilitas 'usefulness'
The freedom and portability to move from one service provider (including internally) to another without hindrance (including excessive cost, time or effort), without boundaries and predicated on the existence of an equivalent service or services.
Whilst there are obvious cost benefits to moving CODB activities to a larger scale specialised provider, there is a risk associated with a lack of fungitility. Having supply and distribution or your CRM service or your governance processes locked into one provider can create significant risks should the provider either change pricing, personnel or even suffer a major outage of some form.
Fungitility reduces this risk and it is why open, free and common standards provided by multiple common resource or service providers are essential.
Before I go, I want to re-emphasise this is only to do with common or ubiquitous types of necessary activities and processes. This is only to do with CODB, which should be focused on cost and fungitility. The ideas of Taylorism are only applicable to commonly repeated activities and at a service provider level this means ubiquitous within the industry.
A novel and new activity, a potential source of competitive advantage (CA), may make efficient use of some CODB-like activities. It might even be a commonly repeated activity within an organisation - however by its very nature it is not suited for a service provider. It is neither ubiquitous nor necessary (in the short term). For such activities I would promote the use of worth based and VC-like techniques.
I've now outlined the topic, created my new word - and so I'll deal with each section of the "stack" in detail over the next few posts.
[Amendment, June 2008: I never found the time to do this. If you want to know more on my views then there are videos of my presentation from OSCON in 2007.]
[Amendement, April 2014: The *aaS terms have changed since this was written, HaaS became IaaS, FaaS became PaaS and there's more confusion than ever].