The abuse of innovation.

Innovation is a term which is widely abused and this abuse prevents us from seeing patterns in how business activities evolve.

It is difficult to see what changes when everything is called an innovation in the same manner that it's difficult to see the difference between commodification (assignment of economic value) vs commoditisation (shift from imperfect to perfect undifferentiated competition) because of the catch-all nature of the term commodification (i.e. it's used to mean both).

Take for example the utility provision of computing infrastructure (as per Amazon) - is it an innovation?

When it comes to computing infrastructure, the innovation of modern computing probably started with the Z3 in 1941. This act of innovation created an entirely new class of activity - computing infrastructure - which has evolved over time through various stages with custom built examples (LEO etc), products (IBM 650 and onwards) and eventually led to commodity and utility provision. For reference, the full cycle is innovation, custom built, product (with rental services) and commodity (with utility services).

Two things should be noted, firstly that the pathway of evolution is common for activities (and knowledge) though it's not a time based sequence. Secondly, the innovation of the Z3 created a new class of activity rather than evolved an existing class (as with the first phone, the first radio, the first ...)

When it comes to the shift from products to utility, this simply represents an evolution of an activity and not the creation of a new form i.e. infrastructure existed before Amazon. However, it is perfectly true to say that this evolution enables (through creative destruction) and accelerates (through componentisation) the innovation of higher order systems i.e. as infrastructure has evolved we've seen an explosion of innovation in big data, mash-ups etc. This is perfectly normal as commoditisation (the common term used to describe this evolution) creates a cycle with innovation.

So, we have a difference between innovation of a new activity and evolution of an existing activity - both of which we unfortunately call innovation.

To complicate matters there's also the consumer and provider perspective. Whilst electricity is a commodity provided through utility services to consumers, behind the interface (the plug) has been a world of innovation of novel activities (wind farms, solar power, geothermal etc) aiming to create some form of operational advantage. However, it is worth noting that this provider innovation doesn't suddenly turn a consumer commodity into an innovation.

Finally we have terms like sustaining and disruptive innovation. As an activity evolves, in many cases changes to the activity (such as feature differentiation in the product stage) are sustaining and occasionally they are disruptive.

When an activity evolves across a boundary i.e. shifts from products to utility services (as with cloud) then this shift is generally disruptive because the incumbents have huge inertia to the change caused by their past success in the previous stage of evolution (i.e. product or rental vendors).

So the pattern we have is :-

1. Innovation of a genuinely new activity which is distinct from the evolution it enables.
2. Evolution of an activity to custom-built, product (rental) to commodity (utility services). This process is commonly called commoditisation.
3. Sustaining changes dominating within domains (i.e. product)
4. Disruptive changes dominating between domains causing a discontinuity with the past (i.e. product to utility services)
5. Enablement and acceleration of the innovation of higher order systems through commoditisation of lower order subsystems (i.e. creative destruction and componentisation)
6. A difference between consumer and provider perspective.

Now, the problem with the abuse of the term innovation is we end up with :-

1. Breakthrough Innovation
2. Feature, Product and Service Innovation
3. Sustaining Innovation
4. Disruptive Innovation
5. Loads of Innovation (paradigm shift etc)
6. It's my product, of course it's an Innovation ...

We normally shorten this to Innovation, Innovation, Innovation, Innovation, Innovation and Innovation.

Or in other words Innovation.

You have no hope with spotting the pattern under such circumstances and it's no wonder that people get confused with this subject. This has severe impacts on management practices but that's a post for another day.

As for Amazon's EC2, it represents an evolution of an existing activity which is disruptive, will enable breakthrough innovation of higher order systems and for the provider has probably involved a mix of different types of innovative pursuits in operations.

I hate to give up on words, however "innovation" has become so widely abused as to be meaningless. For the future I'm tempted to use the word "Genesis" to describe the creation of a new activity and to put "innovation" in my book of pointless words along with "Cloud" etc.

Hosting Con Keynote

I was very fortunate to be asked to give the opening keynote at Hosting Con 2011 covering commoditisation, business evolution, leadership and what the various tactical plays in the cloud computing space mean to hosting companies. The audience was fantastic, I had a great time and despite using excessive numbers of slides, no-one was hurt in the process.

Continuing on the theme from my OSCON tutorial, I've uploaded a summary set of slides which are highly condensed but give a taster to what we covered.

Alas, there's no video and as per usual I'm six years into writing my book and around 30% of the way there. The subject matter keeps on giving me more areas of interest to explore, so don't hold your breath for me to finish any time soon.

Summary of Hosting Con 2011 keynote

View more presentations from swardley

OSCON Tutorial

I gave a three hour tutorial at OSCON on innovation, commoditisation, business evolution, organisation, leadership and various tactical plays in the cloud computing space. The talk was a blast, I really enjoyed it and judging by the feedback it hit some home runs with many of the audience.

However, the presentation is 1,041 slides long and so - I'm not uploading that or creating a video. Instead I've made a summary presentation which covers the main points.

Be warned, it's highly condensed.

Situation Normal Everything Must Change

View more presentations from swardley.

Is Microsoft's biggest enemy … Microsoft?

Last year at OSCON, I examined mechanisms by which a company could use technology evolution to disrupt an existing player with minimal fear of retaliation. To quote myself :-

"it's the incumbents existing model which will protect you"

This year at OSCON, I'll be giving a three hour tutorial which will explore the entire subject of organisational warfare in far more detail. To give a taster of what is to come, I thought I'd expand upon some of the reasonings behind the above statement.

Anyone who has been following my public presentations over the last seven years or has been exposed to my exploration of this subject over the last decade+ will be well versed in much of this practice. For those uninitiated in this field, I'll start with some basics.

All business activities evolve through a common lifecycle and Cloud Computing is simply an example of this. Unfortunately, whilst we know how things will change, we cannot say when. The pattern of evolution is independent of time which is why the lifecycle graphs that I use have no time axis. But then they could never have a time axis, the future is an information barrier we cannot see past.

Fortunately, there are also barriers to the process of evolution and these give us a sense of when things will happen. In order for an activity to evolve from the domain of products to that of utility services then the following four factors are required - concept, suitability, technology and change in attitude. These factors are our "clue" that change will happen.

So we can predict how things will change, just not when - at least not with any great accuracy.

As any business activity evolves along its lifecycle its characteristics change from more chaotic (e.g. appearance of constantly changing, highly uncertain) to more linear (e.g. appearance of being defined, predictable, measurable). Using this change of characteristics we can develop organisational models which cope with evolution. An example of this is the Innovate-Leverage-Commoditise (ILC) pattern which can be found with many cloud companies.

So we can predict what will happen and though we can't predict precisely when, we can design an organisation around evolution.

There are two tactical plays that I'd like to discuss which can be used in such an environment. The first is around creative leadership, think Steve Jobs' Apple. The other is around disruptive leadership for which the best example would probably be Amazon.

Amazon is a company which rarely seems to create a new activity but instead specialises in commoditising activities and disrupting existing players. Infrastructure existed before EC2, book distributors existed before Amazon.com and the paperback existed well before the kindle. Amazon is extremely good at the disruption game.

To illustrate this disruption play further, figure 1 provides a rough tactical map of Salesforce. Whilst the incumbents are firmly entrenched in the product world for provision of CRM (& sales automation), Salesforce has commoditised this activity through provision of a standardised service. It also appears to be operating an ILC pattern i.e. core services around which a growing ecosystem is used to encourage innovation and identify new successful patterns which are then subsequently commoditised to core services - hence innovate, leverage and commoditise. This model is little different from Amazon's play in the infrastructure space.

Figure 1 - Tactical Map of Salesforce (click on image for higher resolution)

On closer inspection, Salesforce seems to be doing more than just commoditisation with an ILC pattern, as can be clearly seen from Radian's 6 acquisition. They also seem to be operating a tower and moat strategy, i.e. creating a tower of revenue (the service) around which is built a moat devoid of differential value with high barriers to entry. When their competitors finally wake up and realise that the future world of CRM is in this service space, they'll discover a new player dominating this space who has not only removed many of the opportunities to differentiate (e.g. social CRM, mobile CRM) but built a large ecosystem that creates high rates of new innovation. This should be a fairly fatal combination.

But, how is Salesforce able to get away with this? Why was it that Amazon and not a hosting company created this future world of infrastructure provision? The answer would appear to be … inertia.

The existing players in the CRM world are stifled by their very own success in the product world. This past success creates an inertia barrier to change. Whilst the causes of the inertia barrier can be traced back to the early stages of a companies formation, by the time a company is of a reasonable size it is often embedded in the organisation, culture and reinforced by external financial markets. Figure 2 provides an overview of this.

Figure 2 - Causes of Inertia (click on image for higher resolution)

So, back to the question about Microsoft. Whilst Microsoft is now making some strong moves into the service world, the problem for MSFT is this space is being even more aggressively commoditised through open plays. Whether it's VMware's necessary play into open source platform with CloudFoundry or the Openstack attempt to out-commoditise Amazon's out-commoditising of the existing industry.

Both efforts attempt to exploit the natural end state for ubiquitous and well defined IT activities i.e. good enough components provided through a marketplace of providers based upon common open source reference models. Both efforts will seek to create higher order revenue streams such as assurance, exchange, marketplaces and brokers alongside the normal business of being a service provider. 

Whilst MSFT has made much of a fanfare about its recent moves into the cloud, it was a probably a significant internal battle for MSFT just to make the change from products to services. However, this new world is likely to be rapidly commoditised to marketplaces based around open source and hence the real question becomes whether MSFT will be able to make the further change necessary to survive in that world?

Microsoft's future business should be intertwined with open source in the domain of utility services. Unfortunately, the last group of people who are usually willing to accept such a change are those who have built careers in the previous domain e.g. products. The bad news for Microsoft is that group probably includes a large chunk of its own organisation. Hence Microsoft itself is probably its own greatest threat to future survival.

Or as the great Bill Gates once noted:-

"Success is a lousy teacher."

That's one of those basic lessons which often gets forgotten in business. In this world of competition, there are two fronts to fight on. The external front includes those competitors who attempt to either gain a creative leadership position or to disrupt your existing model. The other front is internal and against your own past success.

Which is why in my latest research I've been looking into the web 2.0 world to see if we can't find techniques, strategies and methods for managing IT and the business more effectively in a continually changing world. Of course, I already know that there exists significant competitive advantage in organisational design and the application of cybernetic management as was demonstrated through my successes, failures and experimentation with Fotango during '01-'07. The real question for me is how widespread have equivalent practices become and who is pushing the envelope with culture, organisation, ecosystems and a complex adaptive approach?

-- Update 25 August 2013

Some two and bit years later, the New York Times has published an article on "Needed at Microsoft: A Catch-Up Artist".  The article talks about how “Microsoft does have a financial problem, and it’s been the fear of losing those massive profits from Windows and Office” i.e. inertia and goes on to propose they need a catch-up artist. 

When I wrote the above post in July 2011, these concepts and how to play them had been well established for many years (I personally had used the inertia of competitors as an advantage in Fotango in 2005 and Canonical in 2008).  Inertia is of course, highly problematic if a change is unpredictable (e.g. a change in value networks such as cable versus hydraulic excavators) and this will often lead to what is called "Disruptive Innovation".  However, corporate inertia is more than solvable if you are aware that a highly predictable and inevitable change is going to hit you. 

What I've subsequently discovered is that most companies don't seem to be aware of highly predictable changes and are often disrupted by things which shouldn't disrupt them. Yes, these changes get lumbered under the term "Disruptive Innovation" but in reality they are a class of highly predictable changes which were defendable against.  Cloud computing is an example of this.

Being disrupted by cloud (something which was predicted back in 1966) and was screaming loud in terms of weak signals in the early to mid 2000s is pretty shocking.  This is an issue beyond inertia (and denial) and it is better described as corporate blindness. 

From my experience, corporate blindness is fairly rife. The impact can be reduced through mapping of a landscape or other mechanisms to improve situational awareness especially when combined with some understanding of economic play.  Whilst I like the NYT article, in today's competitive landscape just being aware of inertia and that your own success inhibits your future survival isn't going to enable you to compete against some of the tough players out there.

Oh, and don't get me started on OpenStack.

-- Update 12th February 2015

Microsoft seems to be really turning the corner, they've increasingly adopted a more open route and seem to be overcoming inertia. This is fabulous to see. They've a top notch CEO in Satya Nadella.

Tim Cook has done a tremendous job with Apple, rebalancing it to a more ecosystem focused future. Truly exceptional CEO in my book and up there with Jeff Bezos.

Oh, and don't get me started on OpenStack. What a wasted opportunity.

VMware as an acquisition target?

Back in 2009, I proposed that VMware (or more importantly its master EMC) would eventually divest itself of its virtualisation business. The reason for my thinking was as follows :-

1. Whilst the majority of VMware's revenue was based upon its virtualisation technology, this was an area that was ripe for disruption through two points of attack - open source systems such as KVM and the formation of marketplaces offering utility based virtual infrastructure. The latter almost certainly requires open source reference models to avoid issues around loss of strategic control and when combined with aggressive service competition around price, this doesn't leave much room for a license based proprietary technology.


2. A dominant position in the enterprise is no guarantee for future success - see Novell Netware and the IPX/SPX vs TCP/IP battle. Critical in such battles is the development of wide public ecosystems and inherently open source has a natural advantage. However, given the revenue position of VMware, it could not afford to undertake this route.


3. The obvious route for VMware would be to develop a platform play, most likely an open source route with an extensive range of value add services - from assurance to management. The current business would be used to fund the development of this approach until such time as the company could split into two parts - virtualisation & platform.


4. Given the likely growth of private clouds as a transitional model in the development of the cloud industry, VMware would position the virtualisation business in this space for a high value sale, benefiting from its strength in the enterprise. This is despite it being unlikely that VMware would become the defacto public standard, that the technology was likely to be disrupted, that hybrid clouds are a transitional strategy superseded by formation of competitive markets and that many "private clouds" would be little more than rebranded virtual data centres.


5. During this time, there would be signals of confusion over the VMware strategy precisely because it would be using a time limited cash cow to fund a new venture whilst preparing to jettison the cash cow prior to disruption.

Given the confusion over cloud, the often central (but ultimately misconceived) role that virtualisation is given in the industry, the generally disruptive effects of this change and the wealth of many competitors then in my opinion with luck, timing and good judgement a buyer could be found.

So, in my opinion:

• For VMware, it would mean creating a strong platform business funded by its current revenue stream before jettisoning the virtualisation business at high value prior to its disruption.


• For the buyer, it would mean ... whoops ... well that's capitalism for you. Next time, pay more attention.

Of course, this is just my opinion but I haven't changed my view over the years. I'm expecting to see an increasingly clear division within VMware between platform and virtualisation in the next year or so.

I'm hence curious to know what others think? Do you believe that VMware would sell its virtualisation business?

Deconstructing Gartner's Hype Cycle

This is a piece of work that I did many years ago but given my recent post on Lifecycle (nee evolution). I thought I'd revisit it. I will assume the reader is entirely familiar with the concepts of commoditisation.

In figure 1, I've taken part of the evolution curve and modeled onto it a differential benefit curve (differential value - cost of implementation). This latter curve shows how the benefit of an activity changes as it evolves from its early innovation (where it is a strain on company resources) to a late product stage where the activity is ubiquitous and of insignificant differential value between competitors.

Figure 1 - Lifecycle & Differential Benefit (click on image for higher resolution)

When a new activity appears, you often get whitepapers written about it. These are generally done at a time when the activity is showing a highly positive differential benefit. Obviously there is a delay between the collection of data, the publication of the whitepaper, a user reading the whitepaper, the decision to do something and then implementation of the activity.

By the time an activity is implemented, the actual differential benefit may be vastly different. This creates a delta for expectation i.e. a difference from what we thought we would get and what we got. Figure 2 provides a graphical notation of this.

Figure 2 - Delta in Expectation (click on image for higher resolution)

Modelling this delta, with an awful lot of assumptions, provides the expectation curve shown in figure 3. There are a complex set of assumptions and conditions around this, however for the purpose of this post then I'm happy to say this curve is somewhat valid ... caveat, caveat ... except where it's not :-)

For the sake of this post, let's just pretend it is. What the curve shows is the early stages start with low expectations (but possibly high hopes), expectations are then quickly exceeded and continuously rise to reach a plateau after which expectations rapidly become unfulfilled leading to a trough of disillusionment before eventually levelling.

Figure 3 - Expectation Curve (click on image for higher resolution)

This all sounds strangely familiar and so it should. The expectation curve quite neatly maps to Gartner's hype cycle - see figure 4. So, we have a potential basis for explaining the underlying forces behind the hype cycle except of course, we have all the assumptions and I'm talking about expectation and not visibility. I'm not even sure what visibility actually means but given it's a hype cycle, I'll assume high hopes (expectations) means high visibility. Clocking up another assumption here.

Figure 4 - Hype Cycle & Expectation Curve (click on image for higher resolution)

Does our new underlying "basis" of the hype cycle shed any new light on the subject? Well, yes. However before I show this, I'd like to examine the final stages of lifecycle.

The evolution of an activity from products to utility services invokes its own expectation curve not through differential value (the creation of a new activity) but operational efficiency (a more efficient means of providing an existing activity).

In figure 5, I've provided the later stages of lifecycle including the transition from products to utility services and modeled an operational benefit curve (operational efficiencies over competitors - cost) of a transition to utility services. Again, lots of assumptions.

Figure 5 - Lifecycle and Operational Benefit (click on image for higher resolution)

NB. this benefit curve is the same shape as the earlier differential curve being derived from the benefit created over competitors, number of competitors exploiting the change and a changing cost of implementation due to maturity. Hence the transition to utility services starts with a period of investment, a rapid benefit over competitors gained by those creating or exploiting such services and then a decline in benefit over competitors as more companies switch to a utility model.

The reason why I mention this, is that whilst Cloud Computing is all about volume operations for ubiquitous and well defined activities (i.e. use of computer resources in business) and is hence all about commodities, this transition will create a similar expectation curve around operational efficiency in much the same way that a genuine innovation creates an expectation curve around differential value. This is shown in figure 6, and the result is the same delta in expectation curve shown beforehand.

Figure 6 - Delta in Expectation (click on image for higher resolution)

Our first "insight" is Gartner's hype cycle tends to show both innovative activities and transitional effects on the same graph. We should be careful to distinguish between operational efficiency (doing the same thing better) and differential value (doing a new thing) lest we start to confuse Cloud Computing with Innovation.

Hence, in the following hype cycle I've highlighted several activities, including :-

• cloud computing: more efficient provision of the existing activity of "using computer resources in business"
• social network analysis: a relatively new activity and a potential differential

Figure 7 - Expectation and Hype Cycle (click on image for higher resolution)

Since we started with differential value or operational efficiency, we can now map "value" zones onto the hype cycle. I've done this below.

Figure 8 - Hype Cycle & Value Zones (click on image for higher resolution)

What this suggests is the early stages of the hype cycle has an increasing benefit. In the trough of disillusionment, there is still benefit to be gained but it's diminishing. However, in the slope of enlightenment and the plateau of productivity there is little or no differential or operational benefit over competitors since everyone else is doing it. That's our second "insight".

The lesson of this story has been known in military circles for a long time. An imperfect plan executed today is better than a perfect plan executed tomorrow i.e. if you wait until the activity can be easily and effectively implemented (the plateau of productivity), it'll provide little competitive benefit to you.

Fortune favours the brave.

[A final few comments]

To generate the expectation curve I had to create a model over time. This required lots of assumptions because the evolution (lifecycle) curve does not have a time axis (i.e. you can't predict when something will evolve). There are hence a couple of points I'd like to make clear.

1. You can't simply overlay the expectation curves of different activities on top of each other - i.e. the axis of time is different (some are stretched, some are shortened). Gartner's curve doesn't define its time axis and we can therefore assume they're referring to a general shape which appears over an undetermined length of time.
   
2. The Gartner curve specifically refers to the technology trigger. We can assume this is when the technology starts to spread and ignores any early stage effects (invention etc).
   
3. If the Gartner curve was based upon the measurement of some physical property, it would be possible to reverse the process i.e. from Gartner curve to expectation curve to evolution lifecyle and accurately state where an activity was along the uncertainty axis. By very definition this is impossible. I can currently only state where something was in the past once it has become a commodity. Hence I have to conclude that Gartner's curve is not based upon some external measurement of physical property but instead it is more likely by a process of expert review (i.e. averaging where forecasters think something is on the curve) or even more simply, analysts placing dots on the curve.
   
4. The Hype Cycle in its current form can have both novel activities and the evolution of the same activity to more commodity forms represented on the same position of the curve at different times i.e. a single activity may well go through the the peak of inflated expectations multiple times. In the first case, this will refer to the differential value of the novel activity but later on, the same activity will appear in the same position due to operational efficiency of a more commodity form. This occurs because the same activity can be given multiple different memes i.e. x86 architecture, client/server, hosting or cloud and whilst those memes are different, the underlying activity (i.e. provision of computing infrastructure) is the same. You cannot therefore use the Hype Cycle to determine evolution, notwithstanding the issue that it is time based and evolution cannot be measured over time (we have no crystal ball).
   
5. The expectation curve matches the Gartner curve in certain circumstances. I cannot conclude much about the Gartner curve other than to say that its shape appears to have some validity in specific circumstance and I can approximate the value zones where the curve does match. This doesn't say anything about where the dots are placed on the curve just that the rise of increasing then diminishing then plateau of negligible benefits seems broadly right. That up, down, almost flat shape seems to have merit.

-- Update 10th Feb 2015

This uses an old form of the evolution graph. I've subsequently refined the terms innovation, custom built, product and commodity to genesis, custom built, product (+rental), commodity (+utility). The problem was that whilst I used "innovation" to mean the first ever attempt to put an activity in practice, the common use of the word "innovation" (used liberally to mean genesis of something, feature differentiation of a product, introducing a utility model for an existing activity) made that meaningless. Hence, I changed to use "Genesis" to re-assert the point.

-- Update 7th Sept 2015

Gartner Hype cycles no longer use Visibility vs Time but instead Expectations vs Time. The "time" axis seems to be only a generic sense of travel as the items on the hype cycle are given times to reach the plateau e.g.

I have no idea why they've made this change. Obviously, I was using an expectation curve and so again I broadly agree with the shape. I'm somewhat concerned that the axis changed but the curve didn't but given that the dots are just aggregated opinion, I suspect the curve is just an opinion as well. This doesn't mean it's not useful, as long you keep in mind it's just opinion all the way down.

Top tips for start-ups

By popular request, here are Andrey Markov's top tips for startups, as derived from many leading VCs' posts on what makes a successful startup.

P.S. Before taking this seriously, please read the note at the end.

=== Start Text ===

Top Tips for 99% at least of small startups.

1. When seeking investment make the founder Geraldine Brooks.
2. You avoid firing people. But when you're not qualified, the end is the most important thing.
3. Embrace change. If you are offering to investors hold you pick the MP3 player space, all because you better be afraid as investors are lots of weakness.
4. Launch into something. Go ahead with this thing. You need to Google, and see the search terms accordingly.


5. Choose a way everyone knows what's the bat. Have the agility to further understand your team. Know when you need in three years and good long staff meetings that there is now a market.
6. Become an expert on revenue. It helps to deploy? Understand your product just as you reach them, and maybe also their business plan.
7. Get a stunning logo or generate feedback; that means engaging a small business advisors. Let your audience in the company, acknowledge them, but avoid defensive responses. Convince the angels of a sign of myself, will you be “Can everyone win this business?"
8. Good isn't working the performance. "There are the ship keeps moving forward. Otherwise, you'll soon be abroad when the good are offering to clear."
9. This may make it a Fortune 500 company, and former colleague told me on it. In most budding entrepreneurs, you can. Make the business school code for startup culture: a friend of your team, and cannot stop less than "I have an airline".

In summary, you get experience and torn jeans as you integrate yourself - they needed helping, say, but the early days we didn't tell you so.

=== End Text ===

The real shame of this, is it actually makes more sense than some of the stuff I get to read. Special thanks to Doctor Nerve's Markov Text Generator and yes, this is the last one.

Islands in the sky

I'm often asked how will the cloud develop to which I'll answer -"imperfectly, very imperfectly".

I was reminded of this through a long discussion with Benjamin Black, hence I thought I'd write something to explain my general thoughts on the problem. First, let me apologise as this will be a long post. Second, we need to start by recaping some basic concepts about risks. The barriers to adoption in cloud cover three basic forms of risk :-

Disruption Risks : Change to existing business relationships combined with issues around political capital and previous enterprise investment. It's often difficult to let go of that which we have previously invested in.

Transitional Risks: These risks are related to the shift from a world of products to a world of services and they include confusion over the models, trust in the service providers, governance of this service world, transparency from the providers and security of supply. Many of the transitional risks can be mitigated with a hybrid (private + public) cloud approach, a standard supply chain management technique. This approach has been used in many industries which have undergone a similar change, for example in the early decades of power generation it was common to combine public generation with private generators. Even today most data centres mix a variety of public suppliers with backup generators and UPS systems. Fortunately, these transitional risks are relatively short lived.

Outsourcing Risks: These cover lack of pricing competition between the new providers , lack of second sourcing options between providers, loss of strategic control to a specific technology vendor, lock-in and unsuitability of the activity for such service provision (i.e. it's not ubiquitous or well defined enough for such volume operations based service provision). The outsourcing risks can be reduced through the formation of a competitive marketplace of providers with easy switching between them and ideally the option to in-house service provision. The outsourcing risks are long term.

For a competitive market to form, you need easy switching which means portability. The basic ingredients of portability include a choice of providers, access to your code and data from any provider and semantic interoperability between providers i.e. both the origin and destination providers need to understand your code and data in the same way. There is limited value in having access to your code and data if no other provider understands it and operates to provide the same functionality e.g. getting access to your data in salesforce is great but what do you do with it?

In such circumstances, there does exist a weaker form of syntactic interoperability, which means both providers can exchange data but the end result may not function in the same way and your data may not retain its original meaning. Often, this is where we see translation systems to convert from one system to another with the usual abundance of translation and semantic errors.

The ideal situation is therefore semantic interoperability, which generally means a common reference model (i.e. running code) which providers either operate or conform to. Unfortunately, common reference models come with their own risks.

Let us suppose you have a marketplace of providers offering some level of service at a specific level of the computing stack (SPI Model) and these providers operate to a common reference model. The model provides APIs and open data formats, giving you access to your code and data. You therefore have a choice in providers, access to your data and semantic interoperability between them. You have portability. BUT, if that common reference model is owned by a vendor (i.e. it's proprietary code) then that market is not free of constrant but instead controlled by the vendor. All the providers & consumers in that marketplace hand over a significant chunk of strategic control and technology direction to the vendor, who is also able to exert a tax on the market through license fees.

To reduce this loss of strategic control and provide a free market (as in free of constraints), then that common reference model must not be controlled by one party. It has to be open sourced. In such an environment, competition is all about operational efficiency and price vs QoS rather than bits. This makes intuitive sense for a service world, which is why I'm pleased openstack is following that route and I hope it will become the heart of a market of AWS clones. Obviously, you'll need different common reference models at different layers of the computing stack. Whilst only one is probably needed for infrastructure, you will need as many as there are competitive application marketplaces (CRM, ERP etc) in the software later of the SPI model.

Before anyone cries the old lie of standardisation hampers innovation, it's worth remembering that utility service provision (which is what cloud is really about) requires volume operations which in turn requires a ubiquitous and well defined activity. Whilst the common reference models certainly won't be perfect in the beginning, they don't need to be, they only have to create "good enough" components (such as a defined virtual machine). They will improve and evolve over time but the real focus of innovation won't be on how good these "good enough" components are but instead what is built with them. This concept, known as componentisation, is prevalent throughout our industrial history and shows one consistent theme - standardisation accelerates innovation.

So everything looks rosy … we'll have the economics benefits of cloud (economies of scale, increased agility, ability to focus on what matters), competitive marketplace based around multiple providers competing on price vs QoS, the options to use providers or install ourselves or to mitigate risks with a hybrid option, "open" API & data formats giving us access to our code and data, open sourced common reference models providing semantic interoperability, "good enough" components for ubiquitous and well defined activities which will cause an acceleration of innovation of new activities based upon these components … and so on.

Think again.

In all likelihood, we're going to end up with islands in the cloud, marketplaces built around specific ways of implementing a ubiquitous and well defined activity. Don't think of "good enough" components but instead a range of different "good enough" components all doing roughly the same thing. Nuts? It is.

Hence, in the infrastructure layer you're likely to see islands develop around :-

• EC2/S3 (e.g. core of AWS) including the open source implementations such as Open Stack, Eucalyptus and Open Nebula.
• vCloud principally provided through VMWare technology.
• a Microsoft infrastructure based environment.
• any Openstack APIs, particularly if Rackspace implements this.

All of these will be providing their own versions of "good enough" units of virtual infrastructure. Within those islands you'll head towards multiple service providers or installations, a competitive marketplace with switching between installation and semantic interoperability based upon a common reference model. The open source projects such as OpenStack are likely to form assurance industries (think moody's rating agencies, compliance bodies) to ensure portability between providers by comparison to the common reference model whereas the proprietary technologies are likely to develop certification bodies (e.g. VMWare Express).

Between islands there will be only syntactic interoperability (with exceptions such as OpenStack which will try to span multiple Islands), which will mean that you'll require translation of systems from one island to another. Whilst management tools will develop (and already have started) to cover multiple islands and translation between them, this process is imperfect and a constant exercise in chasing different APIs and creating a lowest common denominator (as per libcloud). Of course, I wouldn't be surprised if the libcloud folk were hoping that as a community develops around them, then the providers will offer libcloud as a native API. Such command & conquer strategies rarely succeed.

Given this complexity and since there will be multiple service providers within an island, it's likely that consumers will tend to stick within one island. If we're lucky, some of these Islands might die off before the problem becomes too bad.

Of course, these base components could effect the development of higher order layers of the computing stack and you are likely to see increasing divergence between these islands as you move up the stack. Hence, the platform space on the vCloud island will differ from the platform space on the EC2 / S3 island. We will see various efforts to provide common platforms across both, but each will tend towards the lowest common denominator between the islands and never fully exploit the potential of any. Such an approach will generally fail compared to platforms dedicated to that island, especially if each island consists of multiple providers hence overcoming those general outsourcing risks (lack of second sourcing options etc). Maybe we'll be lucky.

So, the future looks like multiple cloud islands, each consisting of many service providers complying to the standard of that island - either vCloud, EC2/S3 or whatever. Increasing divergence in higher order systems (platforms, applications) between the islands and whilst easy switching between providers on an island is straightforward, shifting between islands requires translation. This is not dissimilar to the linux vs windows worlds with applications and platforms tailored to each. The old style of division will just continue with a new set of dividing lines in the cloud. Is that a problem?

Yes, it's huge if you're a customer.

Whilst cloud provides more efficient resources, consumption will go through the roof due to effects such as componentisation, long tail of unmet business demand, co-evolution and increased innovation (Jevons' paradox). Invariably one of the islands will become more price efficient i.e. there is no tax to a technology vendor who collects their annual license and upgrade fee through a drip feed process. It's this increased dependency combined with price variance which will result in operational inefficiencies for one competitor when compared to another who has chosen the more efficient island. The problem for the inefficient competitor will be the translation costs of moving wholesale from one island to another. This is likely to make today's translations look trivial and in all probability will be prohibitive. The inefficient competitor will be forced therefore to compete on a continual disadvantage or attempt to drive the technology vendor to reduce their taxation on the market.

The choices being made today (many are choosing islands based upon existing investment and political choices) will have significant long term impacts and my come to haunt many companies.

It's for these reasons, that I've recommended to anyone getting involved in cloud to look for :-

1. aggressively commoditised environments with a strong public ecosystem.
2. signals that multiple providers will exist in the space.
3. signals that providers in the space are focused on services and not bits.
4. an open source reference implementation which provides a fully functioning and operating environment.

In my simple world, VMWare is over-engineered and focuses on resilient virtual machines rather than commodity provision. It's ideal for a virtual data centre but we're talking about computing utilities and it also suffers from being a proprietary stack. Many of the other providers offer "open" APIs but as a point of interest APIs can always be reverse engineered for interoperability reasons and hence there is no such thing as "closed" API.

The strongest and most viable island currently resides around EC2 / S3 with the various open source implementations (such as UEC), especially since the introduction of Rackspace & Nasa's service focused openstack effort.

I don't happen to agree with Simon Crosby that VMWare's latest cloud effort Redwood == Deadwood. I agree with his reasoning for why it should be, I agree that they're on shaky grounds in the longer term but unfortunately, I think many companies will go down the Redwood route for reasons of political capital and previous investment. IMHO I'm pretty sure they'll eventually regret that decision.

If you want my recommendation, then at the infrastructure layer get involved with open stack. At the platform layer, we're going to need the same sort of approach. I have high hopes for SSJS (having been part of Zimki all those years back), so something like Joyent's Smart platform would be in the right direction.

---  Added 19th August 2013

Gosh, this is depressing. 

Three years and 15 days later Ben Kepes (a decent chap) writes a post on how we're coming to terms with what are basically "islands in the clouds".

OpenStack followed a differentiation road (which James Duncan and I raised as a highly dubious play to the Rackspace Execs at the "OpenStack" party in July at OSCON 2010). They didn't listen and we didn't get the market of AWS clones. In all probability if AWS compatibility had been the focus back in 2010 then the entire market around OpenStack could have possibly been much larger than AWS by now. But, we will never know and today, OpenStack looks like it has almost given up the public race and is heading for a niche private role.

In his article, Ben states that companies never wanted "cloud bursting" - a term which seems to be a mix of 'live' migration (a highly dubious and somewhat fanciful goal to aim for which is more easily managed by other means) combined with the ability to expand a system into multiple environments.

Dropping the 'live' term, then both can be achieved easily enough with deployment and configuration management tools. One of the reasons why I became a big fan of Chef in '08/'09 (and not just because of my friend Jesse Robbins). This sort of approach is simple if you have multiple providers demonstrating semantic interoperability (i.e. providing the same API and the same behaviour) as your cost of re-tooling and management is small. It becomes unnecessarily more complex with more Islands.

Anyway, that aside the one comment I'll make on Ben's post is the goal was never "cloud bursting" but instead second sourcing options and balancing of buyer / supplier relationship. Other than that, a good but depressing post.

A nice little earner ...

The U.K. government's use of a buy-out (re-capitalisation) strategy rather than a bail-out strategy has taken a lot of flak in the last month. I wholeheartedly support this Keynesian approach because it is a form of future wealth redistribution from the market to the state, assuming that we don't sell out too quickly when the market recovers (something which the laissez-faire vultures will obviously try hard to encourage).

Contrary to popular belief, most businesses are not the paradises of economic virtue and good management that they attempt to portray but are often haphazard structures prone to waste, incompetence, politics and simplified forms of management (often to ridiculous extremes). Dorian Gray would be proud.

It is the rare business that lasts fifty years without being seriously challenged by a couple of blokes in a garage start-up. If the military was run like most businesses, then we'd probably be on our twentieth regime change by now.

The government should be exploiting these weaknesses. The most obvious example of this, is the plans for more public building. Rather than making shareholders wealthy, we should be buying up the likes of Taylor Wimpey (on the cheap) and funnelling building projects through a part or wholly nationalised building company. Give people jobs rather than shareholders easy pickings.

It's worth remembering that money trickles up and not down, so if you want to get things going then start with those at the bottom of the social scale.

On the same note, the time has never been better to join the Euro. At such a low exchange rate, the potentials for investment and strengthening our manufacturing and export businesses are exceptional. Many pundits are asking the government to prop up the pound, however this form of interference is not only doomed to failure it also results in a transfer of wealth from state to market. Wrong way guys.

The debt burden maybe high but if we're buying out good future assets on the cheap then we're going to come out of this smelling like roses.

This is definitely not the continuing odour of the financial markets given the latest Ponzi scheme extravaganza. $50 billion in a pyramid scheme, talk about financial wizardry! You have to ask, who was auditing the books and signing off the accounts? Was it one of the big four again, the same gang who were also responsible for auditing many of the banks that have now collapsed.

We really should start asking ourselves whether we need a national owned auditing company and legislation that all company books have to be signed off by the government?

It'll be a nice little earner and we can always privatise it when the economy recovers.

Note for Self - that's a lot of talking.

For a number of years, I've been talking about how activities transition from innovation to commodity or more simply put how yesterday's hot stuff becomes today's boredom.

I undertook a piece of research into this field and found what appears to be an S-Curve relationship between the ubiquity (how common an activity is) and the certainty of an activity (approximated from the quantity of information published)

Now every presentation I give is slightly different. Each mashes up (thanks to Dennis for that) different parts from earlier presentations as well as new elements from my research. Well, I'm considering an entirely new style of presentation, so I've decided to write down the list of the themes I've covered and to use this as a basis for my new work. I thought, I'd keep a record of the list here (see below).

It's a lot, however there is a whole bunch of stuff that I've known about and barely touched upon. So next year, I'm going to provide a high speed, kitten based, mash-up of a presentation. It will contain an initial introduction and then fifty five themes, with the audience choosing which ones they want. I've got a nifty new way of doing this including bonus sections ... should be fun.

I've also been asked by numerous people whether I'm coming back to the U.S. to present again? I will probably do a presentation or two, on behalf of Canonical, for various cloud issues but regarding my management theory presentations that's strictly U.K / Europe based. The cost of travel and accommodation in the U.S. is simply too expensive.

Theme List

1. It's not just products that get commoditised but processes and all other forms of activities.
2. How an activity's characteristics change from innovation to commodity, no matter what it is.
3. Why management is complex and why there are no magic bullet solutions.
4. Why outsourcing often fails.
5. Why good management often leads to the death of a company.
6. How companies evolve between various stages from disorganisation to getting it together and finally "we need more innovation".
7. The inefficiency of organisational structure where similar types of activities are grouped together (such as marketing and IT) rather than the stages of an activity's lifecycle (transitional, commodity, first mover)
8. Why you need to constantly adapt to changes in the market place in order to just stand still and survive today (the business equivalent of the Red Queen Hypothesis)
9. The difference between commodification and commoditisation.
10. Why you need to constantly innovate in order to survive tomorrow (creative destruction)
11. Why commoditisation is both friend and foe.
12. Why change is the norm.
13. Why you need to constantly balance creative destruction and adaptation in an organisation and how this leads to a paradox of order and disorder. The innovation paradox.
14. Why Google's 20% rule was an efficient way of balancing this paradox and a continual source of competitive advantage.
15. Why marketing and branding for a vendor constantly creates a disadvantage for their consumers.
16. The shift of IT from a product to a service based economy (what we used to call utility computing many years ago, and now is unfortunately called cloud computing.)
17. Why open source standards are an essential part of our future.
18. Why organisations only exist in the intersection between people and activities and how traditional forms of management are inefficient.
19. The need for more dynamic methods of management.
20. The limits of ROI and why it is only suitable for certain stages of an activity's lifecycle.
21. Why you can't plan the future and why every organisation needs some chaos.
22. Why today's organisational structures often fail people and why innovation is not everyone's job.
23. How strategy varies with lifecycle.
24. Why innovation markets will only work for post-event inventions and discoveries.
25. The limits of open source and closed source technology and the domains where those techniques are particularly strong.
26. Why fortune favours the brave and how the future value of an activity is inversely proportional to the certainty we have about it.
27. Why transparency and portability matter in cloud computing.
28. Why you have no choice in the long run over whether you adopt cloud computing.
29. Why fuzziness in processes is valuable information.
30. Why single methods of project management (for example six sigma, prince 2 or agile) are inefficient and often harmful
31. Why getting it wrong doesn't matter as long as everyone else is getting it wrong.
32. Why web 2.0 is important and why now.
33. Why commoditisation leads to more innovation and a faster rate of evolution (extension from Herbert Simon's work on the Theory of Hierarchy)
34. The difference between innovation and product or service innovation (whether radical, incremental or disruptive)
35. Why KPI's and attempts to make management easy can seriously damage your wealth (extension from Ashby's law of Requisite Variety)
36. The three accelerators of innovation in web 2.0 - network effects, componentisation and bridging the divide between opportunity and ability.
37. How the growth of 3D printing and the commoditisation of manufacturing processes will create new languages.
38. Why IT organisations are under increasing organisational stress as they try to balance the needs of commoditisation and innovation.
39. Why competitive life just seems to get faster and faster.
40. Why the transition from one domain (such as products or services or bespoke) to another causes major disruption.
41. The difference between ideas, invention, discovery and innovation.
42. The effects and failure of organisations to deal with the commoditisation of human, physical and social capital.
43. How social networks allow us to challenge traditional views of management.
44. Why organisations need pioneers, colonisers and town planners.
45. Why the role of the enterprise architecture is so important and never completed.
46. Why organisations should use both X & Y managers and something in between (the XY Manager).
47. The problem with patents and why the length of term of a patent should vary according to the innovation and how long society could be expected to independently discover it.
48. Why tailor made can be bad for the consumer.
49. Why failing and gambling are important management traits.

The other six ... well, I've got to have some surprises. However, just like the other stuff in this list, they are not new ideas just old ideas repackaged.

Looking for a good author ...

Manolis is the creator of a piece of technology which turns an ordinary paper book into an interactive experience. I've written about this before but just in case you haven't seen this, I've included a video of me playing with the technology.

I want to be quite clear, this is a paper book which you touch words in and it interacts with your computer. It keeps all the wonderful characteristics of paper whilst gaining all the enjoyment of interaction. I love this concept unlike the Kindle which I think of as a poor excuse for a book.

Unfortunately Manolis' publisher has been unable to find an "absolutely stellar writer to justify the spend" which means the book won't be produced anytime soon.

So I've created a facebook group and I'm looking to find people willing to support this project. I need to be clear that I've worked with Manolis as part of amphilab, I still support him in his goal to find funding and I have a small interest in the company.

Manolis will need:-

• An outstanding author wanting to write a book which will be blinked.
• 1,000 people willing to buy the world's first ever truly interactive paper book. It won't be cheap (around £200) but each person will be named in the book and invited to the launch party.
• Ten companies who wish to buy sponsored links at £25,000. Each link will be a permanent electronic link from the physical book to their web site.

This is what it will take to usher in a new era of interactive books.

The obvious dangers of the cloud ...

We've had numerous instances of downtime, changes in TOCs and services disappearing in the cloud computing world. To this list of shenanigans can now be added Nings unilateral closing of WidgetLaboratory.

I'm not going to go on a rant about the need for open sourced standards to protect the interest of businesses built upon such services, because both James Urquhart and those smart guys at Reasonably Smart have already said what needs to be said.

It seems that Reasonably Smart are also planning to raise further investment. If you're looking at getting into the cloud computing space, I'd strongly recommend you talk to them. To be open in my dealings, I know James Duncan very well but I have no vested interest in the company; I just happen to strongly agree with what they are doing.

I want to clearly emphasise one important point. The value of large scale utility computing provider of a JavaScript based application platform can be measured in the tens of millions. By following an open source route, the value of the technology is in effect zero. However, the potential value of a marketplace of utility computing providers based upon an open sourced standard (with revenues from utility sales, switching services, maintenance contracts, brokerages and exchanges) can be measured in the tens of billions.

If I had the cash I'd invest in the company myself, unfortunately I don't. They have a reasonably good chance, with a little bit of luck and support, in hitting the big time.

Finally, I'm overjoyed to see this post by Tony Lucas (the guy behind FlexiScale) on the importance of Interoperability and Portability in the cloud computing world. I couldn't agree more, and I believe that FlexiScale (at the infrastructure layer of the software stack) and Reasonablysmart.com (at the platform or framework layer of the software stack) have the potential to be real game changers in this service world.

To James Duncan and Tony Lucas, fortune favours the brave ... I'm cheering for you both.

Who has the answer ....

I was recently asked for "answers" on how to implement web 2.0 and enterprise 2.0. I, like many others, can hazard a guess to a sensible course of action depending upon the company, but at this moment in time there are no answers merely informed guesses or what is commonly called recommendations.

Whilst web 2.0 and enterprise 2.0 are not new fields, the technology having been used in commercial settings for many years now, it is still emergent.

What this means, is that we are still learning. This is particularly true when it comes to enterprise 2.0 because you're dealing with a complex network of people (which we barely understand), operating in an environment containing a mass of changing activities (which often we barely understand) into which we are introducing tools that expose new mechanisms of communication, collaboration, componentisation and participation (for which we barely understand the effect or the most suitable means of management).

Some activities are common and well defined and hence we can provide ideal mechanisms of control. However, unfortunately, those which are common and well defined are of declining strategic value due to their ubiquity in an industry. The hypothesis is that there exists an inverse relationship between the certainty about which we know something and its potential future value - a sort of uncertainty principle of future business value.

So genres of activities which are highly uncertain (such as web 2.0 and enterprise 2.0) have high potential future value. Unfortunately by the time that we have all the information, case studies, best practices and research to tell you the best way of achieving this value, the activity is ubiquitous and common and therefore has little.

I mention this because I have recently seen people touting themselves not only as subject matter experts in these field but also setting themselves up as gurus and offering answers.

As with the best snake oil traditions of the past, such claims are founded on weak evidence and you should be glad it is. When it comes to creating value, you need to be experimenting and anyone playing in these fields is just as likely to make the big break as anyone else.

No-one has all the answers to web 2.0 and enterprise 2.0 yet, which is why these subjects still matter.

More duck with your pheasant?

One minute standards are too early, the next Bert tells us that standards are right for the cloud - here's theirs. Don't worry, Bert has given us something new to think about in his post on Open Source does NOT provide interoperability.

Of course, arguments just like portability need more than one participant. I'm not aware of anyone who would argue that Open Source, on its own, brings interoperability. What is sometimes discussed is how open sourced standards (i.e. complete open sourced operational reference models for a service) can be used (along with multiple service providers, trademarks and compliance authorities) to create competitive utility computing markets which have interoperability and portability between service providers.

Open source is key to this, it is critical for competitive markets and it is the only practical way of achieving it without entering a lock-in nightmare of a proprietary reference model. If Bert actually wanted to create an argument he could have said that Open Source is not key for interoperability in the cloud, then we'd have something to discuss.

I'm somewhat bored by all the vendors who try to explain why those components of IT which are ubiquitous aren't going to end up as services and who attempt to bring product mentality into a service world. The argument runs counter to an economy based on services. It's like those half baked ideas which pronounced the death of IT through commoditisation and ignore the feedback created by standard components (from commoditisation) which in turn leads to even faster innovation (as per the whole theory of componentisation).

However, since Bert is picking on open source, I thought I'd point out a few probable flaws with his argument:-

"Although there are open source systems for the base technology, they aren’t a complete solution". Well it's no surprise that without open sourced standards there is no interoperability. The closest we've seen to open sourced standards are the open SDK of GAE (Google App Engine) and Eucalyptus.

"Each provider must complete the solution themselves". Fortunately an open sourced standard is a reference model, it provides all the primitives. You can either implement it, or something that matches it. For example, if you consider that the open SDK of GAE is an open sourced standard, then GAE is simply Google's implementation of the open SDK and AppDrop is another.

"providers are looking for competitive advantage". There are two forms of competitive advantage here. One is in operational advantage, as in a faster, cheaper or somehow better implementation of the standard. The second is in product differentiation (a new feature etc). Product differentiation can* kill interoperability and it belongs in the product world and not in the world of ubiquitous activities treated as services.

"debian to ubuntu, Suse to Fedora, Redhat to CentOS": these are all competing products in a product world. In a service world you could get marketplaces such as "Fedora" as a Service where you will get Fedora and not something else. You could swap between service providers and know that as long as they complied with the "Fedora" standard it will work. Interoperability can be achieved with a proprietary standard, but it means the service provider gives up some strategic control of their business to the technology vendor. The use of open source in the standard is also about protecting the service provider (such as small ISPs) and reducing their barriers to adopting a standard.

I have no financial or commercial interests in the cloud world, I do however see lots of vendors either trying to persuade business consumers that interoperability, lock-in and portability are not issues, or that some committee will save the day.

I do wish Bert the best of luck with his standards committee, however if you are a consumer of these services, you really need to ask yourself whether you want the poachers to be the gamekeepers in a service world or whether it's business consumers who should be running any standards committee.

*I've added this conditionality in response to a comment by James Urquhart, with which I completely agree.

RedMonk talks clouds.

I've been busy with my new project, but I've just picked up all the cloud talk going on at RedMonk.

I've left a brief comment, so I thought I'd post a copy here as well.

=======

Good post.

I've talked about this stuff for a long time but to cut a long story short, standards (as in open formats and APIs) are not enough to create portability and interoperability between providers nor do they solve the additional issues of competition and strategic control for vendors (and a host of others).

We are likely to only achieve competitive utility computing markets where we "write and run enterprise applications that you could move from cloud to cloud" if the markets are based upon open sourced standards.

Since IT is moving from a product to a service based economy with competition on Price vs QoS rather than product differentiation, the use open sourced standards is obvious for the service provision of ubiquitous activities.

It is however unappealing for those vendors who are wedded to a product world with competition based upon features. For those willing to accept the new world, there will be opportunities from brokerages to exchanges to compliance authorities and so on.

Posts you might find of interest.

• video of OSCON talk covering these issues
• Data Portability and all that Jazz
• JSops, JSops ... buy, buy, buy.
• Open Source Utility Grid
• Do we have to change?

=======

As for Alistair Croll's question on whether there is a way of solving the SaaS lock-in (or more correctly lack of second sourcing) issue - well yes there is, it's called open source. The real question that should be asked is when will the *aaS vendors realise that they are competing in a service and not a product based economy?

One final warning, as I've said before there will be more open sourced standards at the application layer of the stack than the framework (now called platform) and the hardware (now called infrastructure) layer. If your "product" doesn't become the open sourced standard when a market emerges around that service offering (whether it's CRM, HR, ERP or JavaScript Development Environments or VM etc), then the odds are it's game over for you. Standardisation and consolidation go hand in hand in the service world.

This is a disruptive change that is going on, and there will be casualties from the product world.

Monitoring the "cloud" ...

At E-Tech (March 2007), I talked about :-

• The commoditisation of IT.
• The need for competitive utility computing markets.
• The "potential" green benefits of large scale computing providers.
• Why open source was essential for SaaS.
• The need for open hardware.
• The change of consumer from a passive to active participant.
• Why patent length needs to be variable and set to the likely time of independent discovery.

All of these themes were connected to the underlying process of commoditisation.

I continuously keep tabs on how different business activities are affected by this process as this enables me to help my clients determine a better strategic choice for their activities. There are numerous stages in an activity's lifecycle, each with its own methodologies and strategies.

Now whatever the "cloud" is, it is certainly about the commoditisation of IT. It's therefore about the creation of a competitive utility computing market for which there are a number of requirements.

One of these is a high degree of substitutability between services (what I jokingly called Fungitility and Patration and James called Software Fluidity). Substitutability between services in the Software as a Service or Cloud Computing or whatever term is in vogue, means:-

The freedom 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.

This term really is about the portability of data, applications and frameworks (see my talk from OSCON) between providers but that terms is used by the DataPortability group to mean something equivalent to "access to data". It's all a bit messy but it's the concepts that matter not the actual terms. They will all get cleaned up at some later point along with aaS wars when there is less buzz.

All you need to know is that IT is moving from a product to a service based economy (hence all the different aaS terms), and in a service based economy the freedom to move from one service provider to another without hindrance is critical. This of course means there must be more than one service provider.

Oscon, July 2007

Substitutability between service providers will require the portability of any necessary data, applications and frameworks from one to another services that are interoperable. For this, and for reasons of strategic control, the services will need to be based upon open sourced standards. This is starting to slowly happen for example with the open SDK of GAE and Eucalyptus. Another requirement is compliance and assurance services. It seems like we have a first step being made along this path with CloudStatus.

Back in July '07, I said: "Six years from now, you'll be seeing job adverts for computer resource brokers."

The speed at which things are moving, it could be even sooner.