I wrote a piece last week in Business Cloud 9 (http://www.businesscloud9.com/content/ibm-and-collective-capitalism/5770) about IBM, cloud-delivered services, and collective capitalism. It raises, I feel, an important sense of direction in the way service vendors need to configure themselves if they are to meet users’ needs.
And half the problem here is that very phrase, users’ needs’. I remain convinced that are large number of the traditional vendors of IT and services feel that their established business model – they come up with new gizmos, and new packaging for old gizmos, and the users will try to work out how to get the best they can out of it – can continue to work in the cloud. But the users’ now need something very different.
Indeed, it is fair to say that the majority of users don’t yet realise quite what it means for them to be operating in a service- delivery model. For example, even the now old adage about utility computing – it will mean having data and processing on tap just like mains electricity – in fact misses the point. What do the end users really want? They don’t actually want electricity on tap. They want, for example, entertainment, clean clothes, or hot food.
In each case, reliable electricity supply is the essential underpinning (and OK, with food especially it can equally be gas, but walk with me through the analogy). But the service they require is not even the TV, or the washing machine, or the oven; it is the ability to get from point A – bored stiff, in dirty clothes and eating a bit of cold lettuce – to point B where they are eating a properly cooked steak, while wearing a clean shirt and watching their favourite film.
This is also an excellent example of why services – in their broadest sense – are also driven by the need for collective capitalism. And this is true even when the members of the collective don’t even know that they are members. This little scenario of a user service’ (let’s call it A Good Evening In’) involves not just the provision of electricity but also the manufacture of a TV and broadcast medium, a farmer growing beef cattle and a good butcher, the manufacture of a washing machine (plus the essential washing powder…..oh, and a water supply system as well), several clothing manufacturers, and the producers of excellent cinematic entertainment.
That, you might say, is all blindingly obvious. But now map it onto the way that the majority of the IT vendors go about their business. “We make the best electricity you can buy” is still the extent of vision for the majority of them. What you do with it, is entirely down to you.
So the IBM example of collective capitalism is a rather neat example of a vendor discovering just what is being sold, and a bunch of users discovering what constitutes the actual service they require.
The scenario is fairly straight forward. There is a large construction project, larger and more complex than any one civil engineering company can take on. A consortium of companies comes together to combine their expertise and resources.
So far, so straight forward.
But consortia like this always sink into a morass of political in-fighting over the essential management infrastructures, such as which company gets to host the IT resources, how much the others pay for this privilege, how do they engineer the necessary integration between different IT infrastructures and, probably most difficult, which company owns the data and IP afterwards.
Here the cloud has an obvious advantage. It can be such a clear patch of neutral’ territory where all of them can pitch camp equally; where the resources can be specified in response to project requirements rather than the resources the lead partner has available can devote to it, and costs can be shared. Data can be stored neutrally and, if necessary, completely destroyed at the end of a project. Also, any arguments about IP ownership could be resolved by having an audit trail of which company uploaded what to the common pool.
And that last element gives a hint of where this then heads. The service’ required obviously starts to involve more than just the provision of IT flexible, scalable resources. What then if the service provider, which is itself an amalgam of individual tools, utilities and applications from a broad spread of vendors (as well as its own resources and contributions) has the expertise to predict and provision the Rumsfeld’ services – the ones the users don’t yet know they should know they need.
IBM, like several others, does have an important component in the cloud mix here: an extensive experience in running large, complex projects. From this can be drawn expertise that can be packaged up and offered as services to those businesses that don’t know they need them.
And to extend the Rumsfeld model to the full, it can also be of great benefit where smaller, less experienced businesses don’t know that they don’t know this stuff and are consequently scared of getting into partnerships with the big players for fear of being stripped of their IP etc.
Yet users are going to need the right mix of services, from a wide range of different providers, available to them as a unified collective, which then has the entirely honourable aim of turning an honest penny or two from the transaction. From that the users can then build their own collectives to deliver to their customers the projects or services they have contracted for.
In a world of increasing collective capitalism, therefore, cloud infrastructures can provide the neutral territory where the partners in the collective can operate clearly and openly, with scalable resources and good cost management on tap. But they will also need access to the resources of expertise and tools that help them through the Rumsfeld Quagmire’, getting permanently sucked down into solving operational and management questions they didn’t know they didn’t know, and probably won’t learn to understand without a good deal of pain.