Continuing my quest to segment the cloud computing market, I’m now looking at the role a channel might play in cloud computing…
…and I’m struggling a little to map the traditional channel role onto cloud. But here are my current thoughts.
There are some obvious areas in the cloud taxonomy/segmentation that look like a good old fashioned software sales model. So first let’s start with my draft / work in progress taxonomy/segmentation to help anchor the discussions in something solid. BTW draft/work in progress means that it will change.
So the Cloud Software segment looks like a traditional software business. Using Brad Buck’s definition for this segment:
Cloud Software is off-the-shelf software that can be used to create an internal cloud or in some cases can be used to customise infrastructure services to mould a customer cloud solution.
Although Brad implies this, I’d extend that even further to say that cloud software will be the basis upon which infrastructure service providers build, host, manage, secure, monitor, etc. their own infrastructure services. So as this is real software being sold to real organisations the channel model I’ve come up with looks familar.
Software is sold to an organisation either directly or through some form of reseller/distribution channel. The end user IT organisation making the purchase either creates a cloud on their own premises for internal use (internal cloud) or a cloud service provider uses the cloud software to create a cloud service which is then made available to others.
Looking at the software services segment, the definition here is
Software services are applications or components that can be used as an end application or used as part of a custom solution
So we have packaged applications or application components of varying degrees of complexity made available to application users directly by the software services provider. Application builders will incorporate some of these software services into their own applications which are tailored and then made available to application users – thus forming one channel to market.
The draft channel model I see there is as shown below:
Here we see that the application user is the ultimate consumer of the software service and that they are likely to consume that directly via the software service provider or via a third party application builder that modifies and extends the software service.
Broadly similar to the platform as a service definition, this segment is defined here specifically as:
Platform services offer a ready built infrastructure and application framework than can be used for building and running applications.
Platform services provide the frameworks in which applications can be built, tested and run. The application user is ultimately the end consumer of the service but some form of application builder will have used the platform service to make the application available to the user as shown below:
There is an argument here that the strict consumer of the platform service is the application builder who then makes the application available to the application user as a software service model. I need to think about this a little more before I cast this section in stone.
Finally the infrastructure services segment is defined as:
Infrastructure services provide building blocks that can be moulded to run different application servers, packaged applications, grids, etc., which can be used to host applications.
These are basic data centre-like hardware, software and network elements that are provided as building blocks upon which software services and platform services can be deployed. In addition end user IT organisations also procure infrastructure services directly and then deploy their own software on to it, treating it as a virtual part of their own infrastructure.
This means that the channel model for infrastructure services looks like this:
Implied Channel Hierarchy
There is an implied channel hierarchy as shown in the diagram below but this is not always strictly followed. The diagram suggests that each level of service provider engages the services of the higher level service provider.
Whilst this certainly will be the deployment model for many cloud users it will not always be the the case. For example whilst it might make academic sense to assume that software services are built and made available using platform services which are then deployed in infrastructure services, in reality services at each level can be provisioned and delivered autonomously without the need for a relationship with providers at any of the other levels.
Well I can’t say that I’ve reached any sort of conclusion yet but I think getting these drafts down on paper has helped me think about the way that the IT industry’s traditional channel models will change over the coming years. I think it’s clear that we will either have less “middle-men” in our sales models or that the roles of these middle-men will change significantly as cloud computing becomes more prevalent.
OK, so back to the segmentation exercise. Next I need to decide on the candidate sub-segments within the major segments explored above. And then I need to decide on which vendors will appear in each of those sub-segments. Finally I need to decide which segments, sub-segments and vendors/providers will be the focus of our cloud computing REPAMA research. I’ll keep you posted on my progress.
The DRAFT Channel Models for Cloud Computing presentation from which the diagrams above have been extracted is shown below.