lustratus REPAMA

Posts Tagged ‘channel’

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.

Cloud Software

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.

Software Services

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.

Platform Services

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.

Infrastructure Services

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.

Conclusion

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.

I’d like to once again acknowledge the significant role that Brad Buck, Peter Laird and Christofer Hoff played in helping to form the ideas on market segmentation.

Danny Goodall

I’m continuing the REPAMA Segment Analysis Study into the Cloud Computing market attempting to arrive at a solid market segmentation and two things have become very clear.

Firstly, every vendor with a remotely related proposition appears to have added the word “cloud” to their product name, presumably in an attempt to bask in the reflected glory that cloud computing provides, perhaps in an effort to appease their investors. This means that there are a large number of vendors claiming to be part of specific segments that may or may not have legitimate claims. This makes the process I’m going through confusing and messy. And if I, as a marketing analyst am having problems, I wonder what sort of success a legitimate prospect would have in finding the product/service they need.

Secondly, the market is still in flux and as such nailing a clear segmentation down is, for some time, going to be like herding cats. This is a classic early market symptom where the market is currently led by vendors’ own ideas about what is needed and what is possible. Once the market starts to form properly and vendors align behind what their prospects and customers are actually buying, then the segmentation will become clearer.

But I have to start somewhere and the good news is that I’ve been corresponding with both Peter Laird of Tendril Inc. and Brad Buck of OpenCrowd and they both have given their blessing to this project and have offered to help if they can. Most importantly they are both happy for me to use their work on a cloud computing taxonomy/model, here and here, as a starting point for my cloud market segmentation.

One thing that I quickly realised was needed for my purposes was some form of professional services (human skills) offer. Plenty of large consultancies, smaller integrators and boutique IT shops offer consultancy services around cloud computing. Both Peter and Brad have rightly focussed on the categorisation of product capability and customer need in fleshing our “their” taxonomy. But to fully understand what propositions are being put together to service the cloud computing “need”, I must include cloud computing professional services.

So far I’ve identified the following list of services under the category of professional services. I suspect that it will grow some and be rationalised some before I finish.

• Strategy, planning and design
• Migration and implementation services
• Testing
• Security
• Cloud application design/porting
• Support services and training

I suspect that cloud application design/porting will be a relatively niche category for a while and that testing, security and support services may all become amalgamated as I carry on my research.

Another major category of cloud computing offer that has also presented itself is that of “Channel”. A number of organisations are white labelling, OEM’ing, reselling or otherwise fronting cloud vendors/service providers’ offerings. One concern that I have is that this sort of partnering is very common in hot early markets where one vendor with no cloud proposition hastily signs a partner agreement to simply tick a box. It does’t mean that either company will do any real business.  I’ll do some digging and and if it looks like a real enough category I’ll add it and blog on it soon.

Danny Goodall.