A spoiler for the future - Bitcoin

Bitcoin is a marvel of our time, a weapon which exploits social engineering to astonishing effect.  The delivery mechanism is greed, the payload is a laissez faire economic system for the unwary. I thought rather than go through the details of how it operates or where it impacts (much of which I've mapped and is related to commoditisation of the means of transfer) that I'd just get right to the conclusion of what I think is going to happen.

So be warned, as per the 3D printing, this is a spoiler for the future which I unfortunately expect to play out over the next thirty years (barring some strong intervention e.g. Government) ...

1. Bitcoin will continue to grow and whilst there will be some wobbles, as it pasts a $1,000 per bitcoin a slew of articles will be published on whether this is "the future of currency" and what is its potential for disruption of existing financial markets including currency arbitrage. Early financial instruments around bitcoin will be developing. China will invest in developing exchanges.

2. As bitcoin races towards $10,000 per coin (expect lots of wobbles along the way) many more Governments will start to introduce legislation formally recognising the currency. A number of articles will be written in equal measure on how bitcoin could threaten taxation systems and how bitcoin represents the rise of laissez-faire capitalism. Numerous books will be written on the "democratisation of currency", "the new laissez-faire", "a new form of capitalism" etc. There will be a very faint weakening in treasury bonds and the ability of Governments to raise funding. New practices will start to emerge from wealth hiding, wealth pooling, new fund raising and equalisation of global investment opportunities. Many organisations in the financial and related industry will still dismiss the impact of bitcoin as fairly irrelevant. China will invest in the development of the industry, encourage external use of bitcoins and have introduced legislation regarding internal use of bitcoins (i.e. outside its borders is ok but severe limitation of internal use as a currency). This will include a register of Chinese users with state identifiable UUIDs (bitcoin addresses) and control of the exchange rate of bitcoin to the Renmimbi (a non free floating currency) with severe sanctions for non state approved exchanges.

3. The volume of worldwide transactions will continue to rise exponentially with bitcoin hitting $50,000 per coin. Governments will become slightly concerned about black / grey markets and a perceived potential reduction of income tax receipts as we head towards a cash based system where the cash is untraceable. Whilst bitcoin transactions are public, the use of single addresses per transaction, mixing services, volume and other techniques will mean the effort required to identify connections between addresses and hence trace identity becomes exponentially hard. Concerns over tax receipts, Government debt, a slight weakening of gilts and increased difficulty in raising funds will add pressure for more austerity.  There will be a number of high profile investigations on bitcoin exchanges and articles will appear with provocative headlines such as "benefit scrounger is a millionaire bitcoin hoarder". Some attempts will be made to control circulation of bitcoins which will be countered through well funded lobbyist groups including large banks that have adapted to this new model. A journalist will also write an expose of "How many bitcoins does your MP have?'. The currency itself will start to appear in wider circulation with articles on "How to buy your car with bitcoins?".  New roles and services will start to emerge e.g. a wealth detective, used to hunt down sources of wealth. The battle to hide and find wealth will heat up and new start-up investment funds with new banking platforms will emerge. China will grow as a centre for development of bitcoin and related instruments. A significant fraction of Chinese external investment will be encouraged and conducted in bitcoins and there will be several high profile cases of severe sanctions for unofficial use of exchanges. In China, through a combination of the great firewall, official UUIDs, sanctions and official exchanges it will become difficult to use bitcoins internally to trade through non official routes.

4. As bitcoin reaches $250,000 per coin, other 'old world' currencies (with the exception of the Renmimbi) will show the first signs of weakening. Many articles will be written on "How I lost a bitcoin fortune" to "The bitcoin billionaires". Financial instruments (currency swaps, derivatives etc) will be well established with bitcoins and along with a growing OTC market there will be a growing market of publicly traded instruments. Most pension funds will be investing in bitcoins and the currency will now be so invasive into our systems, driven by greed, that it becomes too big too fail and impossible to stop. Most governments will have realised they face a future threat of reduced taxation as the public black market slowly starts to becomes unmanageable and the laissez faire economy looms. Articles will be written on "You can't arrest everyone?" exploring how widespread untaxed transactions have become. The effort required to now trace identity through public transactions will have become extraordinary due to highly automated privacy features taking advantage of mixing services. To add to this, along with mounting debt there will be significant weakening in the gilts market as market starts to price in the future effects of bitcoins. New solutions for taxation will appear with books published on topics from "No representation without taxation - managing a voluntary taxation system" to "Reducing the State" to "A Return to Land Tax?". Numerous currency based industries (e.g. exchanges, investment funds) that have not adapted to this world will be facing the early signs of oncoming disruption. Whilst institutions will describe 'shock' at the impact of bitcoin and some will exhibit signs of denial, there will be a rapid movement of organisations into the space. Some journalist will write an article "Is the end of the Dollar / Euro in sight?" whilst another will write "Is this the end for Government as we know it?"

5. As bitcoin surpasses $1M per coin (NB not in 'todays' money but allowing for decline in $ value), most currencies will show weakening. Many governments will start to introduce alternative taxation mechanisms as the ability to determine income and / or wealth rapidly diminishes. Despite various moral authorities preaching on the subject, the use of bitcoins in an effective black market for everyday goods will become a social norm.  Traders who operate with old style cash, declaring earnings and paying taxation will find themselves at a commercial disadvantage. Economists will promote pragmatism and acceptance of the laissez faire economy.  China will continue to heavily promote and invest in bitcoins, with most external trade conducted in such. Internal to the economy, the Renmimbi will dominate and have gained considerable value over other currencies. However, in other Governments conflict will result particularly with the welfare state since it will become almost impossible to determine individuals actual wealth. Concepts such as progressive taxation and means tested welfare will be unenforceable in practice. Alternative mechanisms will be proposed such as "everyone gets a basic salary" from Government, however with tax receipts in decline, reducing ability to raise funds, inability to measure an individuals wealth then this salary will be low.  Endless articles in the unforgiving press will talk of "welfare state funding for bitcoin millionaires". In desperation, taxation will turn towards mechanisms such as Land Tax forcing the poorer to sell property. However, the shortfall will be such that new measures of austerity and reduction of the state are needed and further taxation systems such as "Citizenship tax" become considered. With the dismantling of the state system and mechanisms of redistribution then extreme centralisation of wealth will occur as the ROCE (return on capital expended) increases with C.

6. As bitcoins close on $5M per coin, most currencies will be in severe decline. Government's will be in significant free fall regarding finances. Austerity measures will have taken the route of unprecedented and radical decimation of the state - everything from state provided healthcare to coastguards to income support to education will be practically gone replaced with numerous forms of bitcoin based insurance. If you can't afford it then you won't be able to gain access to it. There will be no state help as the state can neither fund universal care nor determine whether you deserve support. Severe forms of ghettoisation will appear. The argument will be provided that as we live and compete in a global economy then we have little choice. Articles will be written on "How Laissez faire will grow new industry", "The great economic experiment" and "The growth of user choice" but in reality the American dream (sic nightmare) will have become a nightmare for most. Social mobility will be at a historic all time low, the cross generational poverty trap will become an accepted norm and a harder and less forgiving society will emerge with little or no welfare state.  Taxation will be reduced to "property" and "citizenship" i.e. no representation without taxation (NB, as soon as you introduce this including the extreme $1 tax for 1 vote then a few court cases later and companies will have more voting rights than most ordinary people).  Social cohesion will be weak with often draconian imposition by the "funded" state on individuals seen as non citizens. The social contract will have been re-written, the rubicon crossed and many Wat Tyler's will have emerged.  A new global super class of the exceptionally wealthy will emerge.  Governments will be powerless to act as bitcoins will be embedded in every aspect of trade.  With severe reduction of the state, technological innovation in those economies will implode over the next economic cycle (k-wave) exacerbating an already vicious cycle. The key exception to this will be China with its tight control of the Renmimbi and limitation of bitcoins for external trade. China by this point will be the capital and innovation superpower with extensive and virtually untraceable investments in all countries, a mixed economy model and high levels of social mobility, social cohesion and stability.

7. Some monetarist economist somewhere will go back and read Adam's Smiths work on the importance of taxation, redistribution and government. Some member of the Chicago "nut house" of economic blah blah will still claim it's a success and the solution is more "laissez faire".

Of course, the future is uncertain. Let's hope that none of this comes to pass.

As you can guess, I'm not a fan of bitcoin. If left unchecked then I find it has the potential to undermine the importance of Government which is actually not good for competition and not good for the market. I hope none of the above happens and would rather see bitcoin disappear in a puff of history. However, don't confuse my disdain for bitcoin with opposition to the technology behind it. I view the blockchain as having huge and positive potential in many industries. I'm a fan of the blockchain, I just can't stand bitcoin.

The oncoming bloodbath for private cloud

Back in 2008, I talked about the development of the "private" cloud market as a transitional phase between the then and a future hybrid market of multiple public providers. Of course, back then I took the view that the hardware vendors in the space would create a price war to force natural fragmentation of the market i.e. commoditisation does not mean centralisation.

Unfortunately, due to the exceptionally poor gameplay of many vendors in this space, then in this instance commoditisation does seem to mean centralisation to Amazon, Google and MSFT.

The key date for me for the decline of the "private" market was 2016. A number of factors from inertia to energy provision to establishing alternative options to cycle time for investment pointed to that time. Given the amount of effort put into OpenStack, the number of vendors involved, the marketing, the investment and the hopes pinned to it ... I tend to now think of 2016 as a bit of a bloodbath for private cloud.

Do I think it will be just those three vendors? Nope. I expect there to be clone environments (e.g. AWS public clones). There's a lot of mileage to be made here and a very specific user need for alternative suppliers which operate in the same way.

Do I think it's all over for private cloud? Nope. I still hold to my view of 2008. Private cloud will head towards niches but admittedly highly profitable niches. The most successful of those niche players will be those that co-opt the public standard i.e. AWS. Hence, I'm quite upbeat about groups such as Eucalyptus, CloudStack and those elements of OpenStack who have a focus on being an AWS clone.

Do I think it's all over for VMware and OpenStack? Pretty much. I take the view that VMware  will experience a slow and painful downward slope and whilst OpenStack will exist after 2016 it won't do so in its current guise. In my opinion, many of the high profile companies involved will be facing a grim future. There will be some high value buy-outs and claims of success but it's all small fry for the future and what should have been for OpenStack.

Do I think it's all over for the idea of an open source reference model for cloud? Nope. I talked about the importance of open source in forming competitive markets at OSCON 2007 and my view remains as is. I view the work of CloudFoundry as developing such a competitive market in the platform space. However, whilst the IaaS industry maybe lost due to sucky gameplay this is but a temporary state. You should never confuse commoditisation with centralisation because the means of production can yoyo between centralised and de-centralised. 

It is perfectly possible that in a decade or so, as the industry becomes more settled and we've come to accept those standards that have been created for us that we will then see a movement towards more decentralised IaaS provision through a competitive market. This is where Apache CloudStack (possibly Eucalyptus) will succeed if momentum can be maintained. It's the usual long slow haul of open source (think 10 -15 years) and one which could have been avoided but in this case wasn't.

So who will succeed? Well, beyond Amazon, Google and MSFT then I see positive futures for AWS clones and for niche market provision of private clouds (especially Eucalyptus, CloudStack and parts of OpenStack). In the longer term, I still favour a competitive market of IaaS providers around an open source reference model but that'll be a good decade or more away.

--- Note, 8th October 2015

Eucalyptus and CloudScaling (focused on being AWS clones) got acquired. We've still to see any large scale public AWS clone launch (it's become way too late now to mount any serious effort). I'm disappointed here as I was expecting at least sometime to try this obvious game.  There's some niches for OpenStack in the network equipment vendor space (due to NFV). CloudFoundry continues to develop well but the past giants are still being half hearted about this. People keep on telling me that the future for private cloud is bright ... I don't think so, I think some are living in la la land.

Accounting for change

This is an old post, repeated once again because I'm flabbergasted by some of the practice that goes on in IT due to a recent event.

Tl;dr : You always add exit costs to the originating system.

When comparing two systems you have numerous costs including licensing, maintenance, installation, support and exit that need to be considered. In one recent example, a question of whether to upgrade a system or switch to a more open alternative, a blatant example of misappropriation occurred. The figures are provided in table 1.

Table 1 - Costs of System

Name	License / Maintenance / Support	Length of Term	Installation Costs	Cost (solution)
System A2	£3 million p.a.	5 years	£1 million	£16 million
System B	£100,000 p.a.	5 years	£20 million	£20.5 million

In the above, upgrading system A1 to system A2 (which were the same system, just the latest version) incurred a high annual license / maintenance fee but small installation costs due to similarity of the system. However, migrating to an open source system (in this case system B) whilst reducing annual fees incurred a massive installation cost due to the cost of changing systems which worked with the existing installations. Hence at first glance, the sensible thing to do is simply upgrade to System A2. 

This is woefully wrong.

Let us take Table 1, add in the exit costs and include System A1. See Table 2.

Table 2 - Costs of System

Name	License / Maintenance / Support	Length of Term	Installation Costs	Exit / Migration Cost
System A1	Unknown	Unknown	Unknown	Unknown
System A2	£3 million p.a.	5 years	£800,000	£200,000
System B	£100,000 p.a.	5 years	£300,000	£19.7 M

In the above, we have no data for the original system A1 and the majority of the costs involved in installing System B involved conversion of other systems which had previously worked with System A1. I've put this into a column Exit Costs. For System A2, the costs involved with converting other systems is lesser due to the similarities between system A1 and A2.

Now, the first thing to note is that the majority of the costs involved in System B have nothing to do with System B. Instead they're costs of moving from another solution. System B itself because it uses open standards is relatively easy to move to and from. What we're in effect doing is transferring a liability created by one set of systems (i.e. A1 / A2) to another (B) which makes the latter more unattractive. It's a bit like someone saying that because Wind power is replacing nuclear that wind power should absorb the costs of nuclear decommissioning. Only in the world of IT does this accounting slight of hand seem to work.

What should happen is exit costs should be applied to the originating system. Now, if we adjust this taking into consideration the cost of transferring an open standards system B to an equivalent and how use of any system will create continued and increasing exit costs then we get to something like table 3.

Table 3 - Cost of System

Name	License / Maintenance / Support	Length of Term	Installation Costs	Exit Cost (upgrade)	Exit Cost (migration)	Cost (solution)
System A1	Unknown	Unknown	Unknown	Unknown	£19.7 million	Unknown
System A2	£3 million p.a.	5 years	£800,000	£200,000	> £19.7 million	> £35.7 million
System B	£100,000 p.a.	5 years	£300,000	£100,000	> £100,000	> £1 million

In the above, the cost of upgrading from A1 to A2 incurs the exit cost of upgrade, the license / maintenance and support fees and the installation costs. The long term liability (exit cost) to another system is continued and in effect will only increase.

Migrating from system A1 to B will incur low costs of license / maintenance and support but also a longer term lower liability of exit cost since system B uses open standards. We can estimate a cost of upgrade from one open standards based solution to another and I've added a figure for this. 

The total cost of solution B is vastly lower than upgrading to system A2. The only reason why it didn't appear so in the first instance is we transferred an originally unaccounted liability associated with exit from system A1 and discounted it from the upgrade path of A1 to A2 by adding it to the migration path of A1 to B. The only thing that will happen in this circumstance is you will become further locked into the vendor of system A1 / A2 and your future liability will just increase.

By forcing such exit costs to be calculated and added to the originating project, you also force vendors to attempt to reduce your exit costs by including more open data, open standards efforts. If you don't do this and allow exit costs to be misapplied then you only create incentives for vendors to lock-in you in further.

Yes, in terms of cash the cost of implementing System B will be more expensive but that's only because those who installed System A1 didn't account for the exit costs. We learned these lessons a long time ago. 

If you're still adding liabilities from exit costs to the wrong project (usually disguised as costs of migration / transition to) then :-

1) Please, never, ever run a piece of critical national infrastructure. 

2) Please go find someone to help run your IT for you. It'll save you money long term if you consider exit costs in purchasing.

Every single IT project creates a future liability, a cost of exit. When someone tells you that you can't move to a more open system (i.e. open data formats etc) because the cost of migration is too high then this normally means someone hasn't been doing their job and accounting for, managing and mitigating against this future liability.

Good things come in threes ...

First, an excellent post by +Bernard Golden on AWS vs CSP which reminds me of the whole "Innovation" debate. Key to the process of commoditisation is the formation of standard interfaces providing good enough commodity components and then innovation moving above (new things that are built) and below the interface (operational efficiency).

Second, another excellent post but this time by +Geoff Arnold on "Whither Openstack?"

Lastly, a great quote on Enterprise Cloud by Jack Clark  "It's a marketing term. No one has ever convinced me otherwise."


So, I couldn't resist. From an old presentation in 2010 (without the typo).

The Demand.

The Answer

The problem is that what people want is the benefits of efficiency and agility created through volume operations and commodity components but they don't want to occur the cost associated with co-evolution of practice (i.e. N+1 to design for failure, scale up to scale out etc). So they want the new but provided like the old hence avoiding any need to re-architect the legacy. 

It doesn't work like that and why the term "Enterprise Cloud" can be so misleading. A better choice of words is still virtual data centre (VDC).

Without a map you have no strategy

To paraphrase a recent conversation.

Vendor : we're going to attack this space in Q1 next year.

Me: Excellent, that's when you're going to do something but what are you going to do?

Vendor: we're going to launch a cloud based service

Me: Fine, that's what you're going to do and I'll ignore the vagueness here but how are you going to do it?

Vendor: we're hiring talented people to build our system which we might build in an agile way using open source.

Me: Ok, that's sort of how and I won't go into the details because it all sounds a bit suspect, I'll just ask you why?

Vendor: because our competitors are launching cloud services and we need to be in the market.

Me: that's not really a good example of why. What I'm looking for is why here over there?

Vendor: because everyone else is launching ...

Me: ... no, you're just repeating yourself. Why attack this space over another? There are multiple "where" that you can attack, why this one over another?

Vendor: not sure I follow you?

Me: do you have a map of the landscape identifying user needs and how things are changing?

Vendor: what's a map?

Me: Ok, we can assume that's a no then and this is probably the root of your problems. When trying to write a strategy then the first thing you have to do is map out a landscape for the area that you're looking at. To do this always start with user needs. Second, once you have a map then you can determine where you might attack. Third, once you know where then you can determine why here over there. Then you determine the how, what and when. Without a map then you don't have much of a strategy just a tyranny of how, what and when and basically you're just playing chess in the dark.

Vendor: we do have a strategy, we're launching our new cloud service next quarter.

Me: so is everyone else and not one of you seem to know why or have determined the needs.

Vendor: we do know our users, it's written in the strategy.

Me: I could tell you a joke about a general bombarding a hill because "67% of successful generals bombard hills" but you'd probably miss the point. You don't have much of a strategy since you're just doing this because others are and you have no way of better playing the game than this. 

... and so on.

Can, I please reiterate to people the importance of :-

• Map your environment (starting with user needs)
• Determine where you can attack (the options)
• Determine why you would attack one space over another (i.e. the games you can play, the advantages / disadvantages, the opponents, how you can exploit inertia or constraints, possibilities for building ecosystems etc)
• Determine the how (i.e. the method - using an open approach, co-creation with others, alliances)
• Determine the what (the details) and finally the when.

If you don't first map your landscape, you can and only ever will be playing chess in the dark.

Mapping, Competitive Advantage and Kodak Moments.

Throughout this blog and my talks, I've covered the question of mapping (understanding the board), the rules of the game (economic change) and given examples of game play. Mapping is critical to understanding the environment you exist within and "where" you might attack, "why" being a relative statement of why here over there.

However, I want to put up a warning because I was recently asked whether mapping itself can be a source of competitive advantage or differential. 

Tl;dr Rarely can mapping be a source of competitive advantage, it's more a survival tool.

Back in 2005, myself, James Duncan and Greg McCarroll (who recently passed away) mapped out Fotango, the company I was CEO for, and used the map to determine where we should attack in the future. From this, the project which became known as Zimki - a platform as a service play - was born along with all the gameplay around it.

The map is provided in figure 1. This is not the original but a simplified version which I've tidied up adding more recent terms like "uncharted" and "industrialised" to describe the different domains. The map describes the value chain, the evolutionary state and inherent in this was :-

1) How activities evolves and characteristics changed, leading to agile being useful on one side of the map and six sigma on the other.

2) Inertia to change that organisations have.

3) Componentisation effects leading to higher order systems.

4) Use of ecosystems (in particular models like innovate-leverage-commoditise)

5) Use of open as a tactical weapon to manipulate the map

Figure 1 - The Fotango Map.

The single most important thing you can take away from the map however is the date - 2005. There are people out there who have almost a decade of experience in playing these games within companies. James fortunately works for UK Gov these days but there are many others who have long and detailed experience of this.

Which brings me back to the question of competitive advantage. Certainly mapping can provide an advantage when you're playing a "blind chess" player (a category of companies we define as 'chancers') which admittedly many companies do an excellent job of emulating. But there are some very dangerous foes out there. If you think mapping alone is going to give you an advantage over some of the big players in the cloud space then think again. Some of these companies are run by very accomplished chess players. 

In these cases, I'd be using mapping to find another route by which you can build a company and avoid any head on confrontation - you will tend to lose, they will tend to outplay you, they have the experience and they've built highly defensible positions and strong ecosystems. Knowing when to withdraw from a battle to conserve resources in order to fight on another front is one of the hardest things I know for a CEO to do. No-one likes to admit defeat, no CEO likes to accept they've been outplayed and many companies are lost pursuing conflict driven by ego. 

More than inertia, poor situational awareness and chess play - the hubris involved and continued pursuit of the un-winnable battle is what I like to call the "Kodak Moment".  Whilst it is common for people to state "but Culture eats strategy for breakfast" just remember that whilst culture is always important, there are times in the economic cycle where strategy is more important.

We are in one of those times within the IT field (including every industry where IT is a main component of its value chain). There is no hiding place here. The cause of company failure whilst it will be blamed on lack of engineering talent or poor culture or inertia is not caused by this. Companies will principally fail because of poor chess play by 'peace' time CEOs.  

Somewhat bored

I find many of the moves made in the technology industry frustrating especially when there are obvious plays. Back in 2008, I told Dell / IBM / HP about the threat of AWS, their use of a learning model similar to ILC (see below) and how they could be attacked. 

AWS back then had a constraint in terms of building data centres, by creating an AWS clone and forcing  a price war then you could increase demand (compute infrastructure being elastic) beyond Amazon's ability to supply and naturally fragment the market. Did they do this? No, they fiddled whilst Rome burned.

Ok, I'm not expecting any of these companies to listen but having mapped it out, some advice - whether welcome or not.

Versus Android / Samsung

Android is becoming a market dominant and Samsung is the biggest player in this space. Samsung is also heavily supporting Tizen but this really isn't a challenger to Android, it's simply about Samsung's buyer / supplier relationship and power games. Google is hardly going to pay a great deal of attention and Samsung is vulnerable to product versus product substitution.

Android's weakness is Google, who whilst they are ok at platform / ecosystem plays are hardly the best players. The ecosystem around Android is mainly centred on the App Store but despite all the hype on "Apps will rule the world", these type of ecosystems are incredibly poor learning exercises. This matters.

Take for example Amazon EC2. This is a component ecosystem i.e. Amazon provides components as utility services for others to use. What those companies build varies from applications to other component services. This provides a learning opportunity for Amazon. As new component services diffuse, Amazon can leverage the ecosystem by examining consumption information (i.e. core consumption data on underlying APIs) to identify new successful components which they can commoditise themselves. This is the heart of ILC -  (get others to) Innovate, Leverage (the ecosystem) and Commoditise (to components). App stores don't have this as the App tends to be the end state i.e. Apps are rarely used as components. They also tend to be domain specific i.e. fixed to a device. App Stores are hence very weak ecosystems compared to component ecosystems.

So, you have one company which is vulnerable to product vs product substitution and a weak ecosystem play. This can be attacked.

I won't go through the details of how but I'll shoot to the end.

Microsoft / Nokia, Lenovo, HTC, China Telecom, Ericsson (after buying BlackBerry) and others in Canonical's Carrier Advisory Group should make a play around Ubuntu Touch. Forget the past, Ubuntu has a large development ecosystem, they're positioned strongly, there's ample opportunity for intelligent software agents and this route is viable - even for Microsoft.

Versus AWS

Forget the IaaS play or the transitional private cloud play - you've lost. Lick your wounds and leave the whole infrastructure battle to a later substitution play. It's far better to accept losing this one battle, conserve your resources and try to win the overall war. You're up against a well established player - Amazon - who knows how to play the game and use ecosystems. You need to change this to your advantage.

Again, I'll shoot to the end, ignoring the details.

IBM / HP / Dell et al need to make a massive play around Cloud Foundry and by that I mean building large public PaaS built on AWS. You need to drive AWS to an invisible component, grab the ecosystem through a common market and then over time look to substitute AWS at the infrastructure level and hence balance supplier / buyer relationship. You can exploit your position on building on AWS to prevent AWS playing games against you whilst you build the substitution play.

On Ubuntu

In both the examples, Ubuntu is prominent. Before you ask "why not RedHat?", well they're poorly positioned on both fronts - great for the past, weak for the future. As for Ubuntu, the above companies should make the plays and create a JV to buy out Ubuntu.

Canonical is the wedge to achieve both plays, you don't have much time to do this - Google is building components, AWS could make a strong platform play by buying Salesforce though fortunately Amazon needs to invest so much due to AWS growth that they may be unable to do this. Hence, fast action using Ubuntu as the wedge to create a market which favours you should be the order of the day.

I can go through the game play in more details, some of the nuances, how you build competing ecosystems through co-opetition etc but that's not the point. My point is AWS and Android will only win if others let them and there is time for this game to be changed if you play smart and work together.

Oh not again - should we be an agile or six sigma shop?

I was recently asked this question and to be honest, I was flabbergasted. Understanding when to use agile and when to use six sigma (or some other highly structured method) is almost a decade old problem which is well known.

However, I was asked to write a post on this and so with much gnashing of teeth, I give you the stuff which you should already know and if you don't then please stop trying to write systems and go and do some basic learning instead.

First, every system of any reasonable scale consists of multiple components. Those components are all evolving (due to the effects of competition) and you can (and should) map out the components of any system before embarking on trying to build it. Below in figure 1 is a basic map from a heavy engineering project with a large IT component.

Figure 1 - Basic Map

Now, all the components are evolving from left to right and as they do so their characteristics change - they move from an uncharted space (the novel, the chaotic, unpredictable, uncertain, potential differential) to the more industrialised (the common, appearance of linear order, the predictable, the certain, the cost of doing business). See figure 2.

Figure 2 - Basic Characteristics

Agile (e.g. XP, Scrum) and Structured (e.g. Six Sigma, Prince 2) methods are suited to different problem domains. Agile, through the use of test driven development attempts to reduce the cost of change throughout a projects life to a baseline but it does so at a slight cost compared to the cost of change in the requirements / design phase of a structured method. An approximate of this is given in figure 3.

Figure 3 - Cost of Change by Method

Hence for those uncharted activities where there is rapid change (due to their properties i.e. they're uncertain and we're discovering them) then Agile is the most appropriate method because whilst it might have a higher cost of change compared to the requirements / design phase of a structured method, there will however be change throughout the project's life.

Alternatively, those more industrialised acts that are defined, well understood and highly repeatable are more effectively managed by a highly structured method because change shouldn't exist and where it is necessary it should be eliminated in the requirement / design phase.  This leads to a situation where different methods (e.g. Agile, Six Sigma) are suitable for different evolutionary stages - see figure 4.

Figure 4 - Method by Evolutionary Stage

So when examining your map, it should be fairly obvious that you need multiple methods with two extremes of Agile (e.g. XP) including development in-house and Six Sigma with potential for outsourcing. For those transitional activities (i.e. products) then you should be using products and minimising configuration / waste / unnecessary change where possible which requires another set of methods. Hence for our heavy engineering project we could use the following - see figure 5.

Figure 5 - Application of Methods to the Map.

The anomaly in the above is 'web site' being a commodity but using Agile methods. This is because maps are imperfect and 'web site' is in fact a value chain of multiple activities, some of which are more commodity whilst others are novel and new. This needs to be broken down and in the case of the engineering project it was. One final note is that all the activities are evolving due to competition and hence the method you will use for one activity will change as it evolves.

Misapplication of methods will have costly effects. For example, if you outsource the entire value chain described by the map to a third party then you're likely to settle on a structured method because you'll want 'guarantees' of what is being delivered. The net effect of applying a single structured method (such as six sigma) across the entire value chain is that whilst some activities will be effectively treated, you'll also be applying structured methods to activities that are rapidly changing. The end result will always be cost overruns due to change control costs associated with structured methods i.e. you're applying a method designed to reduce deviation to an activity that is constantly deviating - see figure 6.

Figure 6 - Single Method.

At Fotango we went all agile in 2001 and then by 2003 had learned our lesson - multiple methods were needed. I first spoke about this need for multiple methods at a public conference in 2004 and have repeated this countless times. Since about 2007, the use of multiple methods and application of appropriate methods has increasingly become common. The above is of course a fairly basic interpretation.

It's 2013 now ... come on people get with the program, we've had almost a decade of this agile versus six sigma nonsense! It's really only the very extreme of the laggards who describe themselves either as an 'Agile' or 'Six Sigma' shop. There is no 'one size fits all' and you need to use methods where appropriate.

On a personal note

I'm extremely disappointed to be asked this 'Agile vs Six Sigma' question in 2013. The next person will get a boot up the backside from me. Either learn your techniques and how and when to apply them or find another job where you'll do less damage.

That pesky issue of power.

There's been a lot of interest in new forms of data centres recently and the growth of large public cloud providers investing in power production.

Ok, just a quick note because this is all obvious stuff and hence I'll provide a simple back of a fag packet style calculation :-

• The number of transistors increased from 10^11 in 1974 to 10^19 in 2004. That's a 100 million fold increase.

• During the same time, efficiency in energy consumption by transistors increased two million percent! Wow ... alas, that's a 20,000 fold improvement.

• Hence our rate of consumption increased about 5,000 fold. Which approximates to a doubling rate of 2.5 yrs.

• Depending upon who you talk to then electricity consumption by computing represents around 3% of total supply. 

So, assuming that in the next 10 years we continue with the same level of efficiency improvement (i.e. 97% reduction in energy use for the same amount of computing power) then we will only need 50% more power stations than we have today just to cope with the increase in demand. Doubling rates of 2.5 years, Jevon Paradox and all that malarky can create real headaches if you're not careful.

Of course, there's all sorts of complications, substitution effects etc but as I said, this is just a quick note and many of those effects also have counter effects. 

However, the above is why I've often asked people building private clouds whether they have thought about how they're going to secure the electricity supply to power it? I usually do this with my first question on their private cloud effort being where are they building the power plant and what fuel are they intending to use? Depending upon how mean I'm feeling, I might quip have they considered nuclear just to rub the point home.

It's also part of why back in 2008 I made the prediction that by 2016, the private cloud market would be in decline ... in fact, I expect it to be a bloodbath.

The last twelve months

Last year, to the day, I wrote a post on my concerns on OpenStack and stated that in my opinion the next twelve months were critical.

Well, that twelve months is up. 

I don't see a benevolent dictator or a flourishing market of competitive providers with easy switching between them at scale. I do see a collective prisoner dilemma, a refocus on private cloud (a future niche) and capitulation in the public space with Amazon and Google gaining speed.

Back in October '12, I said

"I would like to see Open Stack succeed, there are many talented people (and friends involved). But I have my doubts because I feel it has wasted an opportunity, it has been very poorly led in my view despite its success in marketing."

Well, my view is that this project is not going to create the competitive public market we all hoped for back in 2010. There are outside chances it will be relevant due to the work of +Rick Clark, +Randy Bias and others but overall despite the claims of Mirantis that OpenStack will dominant everything and +Ben Kepes that is has thrown of its "dead duck" moniker - I don't buy it.

I'm fairly convinced that a number of companies will make a decent exit price around OpenStack, that a number of VMware based virtual data centres will come under pressure or be replaced by OpenStack . I'm sure some will claim that as success.

However, the grand idea was for a a future of public providers competing in a market with semantic interoperability based around an open source technology stack. Making such a grand idea happen needed more than just open source but good strategic play from co-option to massive scale investment. That hasn't happened.

Instead, what we're likely to see is consolidation of a market to Google, AWS and a few others. Fortunately, there will be a slow burn model around CloudStack / Eucalyptus and some groups within OpenStack to create a future more competitive market around open source but this will take considerable time. We're back into the old slog that open source found itself in the server market.

It didn't have to be this way.

I've got high hopes for Cloud Foundry to create a competitive market at the platform space around open source. I would wish that companies rather than trying to introduce alternative approaches which blur the market in order to support their dying past business models would just adopt. I expect them to however argue that differentiation on a commodity is key and the same old nonsense be repeated again. 

I would strongly urge people to get behind Cloud Foundry and ignore the rest. No thank you Mirantis, OpenStack has messed up one vision of competitive markets - I'd rather not see it mess up another.

Questions on how?

Twitter is an incredibly useful medium for numerous reasons but one of the things I like is that every now and then you're asked great questions. One of these for me was from Florian Otel on the use of incrementalism and the "art of muddling through".

To give a bit of background, when I talk about strategy it's all about the where (to attack) and the why (a relative statement of why here over there). Tactical choices are all about how you go about something and finally the what and when is simply implementation and operational planning. 

Most strategy documents I read have a tyranny of how, what and when and very little of the why because the where is almost always absent. I know they're called strategy documents but I usually refer to them as tactical and implementations plan with no strategy. On the most part, they're fairly hopeless.

Now in order to plan out a strategy you first need to map the landscape in order to determine where you might attack. For the last eight years I've happened to use a technique called mapping to do this though other techniques exist.

In figure 1, I've mapped out a hypothetical value chain of an organisation which is built from components (including activities, practices and data) over the state of evolution of the components. I will use this map to identify where I might attack and then determine why one route over another. 

Figure 1 - A Map

I'm not going to go through that exercise for now, since the above is a hypothetical example but instead I'll assume I've done the work and determined that the best option for strategic gameplay is three routes described in figure 2.

Figure 2 - The Strategic Play

The three routes are :

Step A) : A particular activity we consume is currently provided custom built and in-house but it is widespread and well defined enough to be suitable for provision by a product as evidenced by existing products on the market. I will therefore move away from our custom built example to using a more standard product with a view of minimising customisations. 

• How to go about it? I'd examine competing products for fit, check to ensure that data is extractable (i.e open data formats etc), determine standard market KPIs for implementation and probably implement with a waterfall method. A key part of this is ensuring that data is extractable because I know at a later stage the activity will evolve to a utility and for reasons of past business model it is unlikely that my vendor will provide the utility, so I'll have to move again. I'd therefore concentrate on what the cost of exit will be, aim to minimise it and certainly factor it into any purchasing decision.

Step B) : A particular activity we consume is provided as a product but it's widespread and well defined and suitable for utility provision. The technology exists to achieve this, I know customers are dissatisfied with the product cost but no utility provider exists. This is an opportunity for me. 

• How to go about it? If I have the technical capabilities then I'll aim to provide a utility service to the market based upon our experience of the product. We will focus on providing the utility through APIs and building up an ecosystem with an ILC model. Ecosystems are valuable future sensing engines if used correctly. I know existing vendors will have inertia due to past business models, this is beneficial to me. I know existing customers will have inertia due to past practices, changes in relationship (social capital), knowledge capital, prior investment along with concerns over lock-in. I'd look to counter by adopting an open approach (e.g. source). Since the activity is well known and defined, my focus is on industrialisation and hence I'd use a structured approached designed to remove deviation e.g. six sigma / ITIL.

Step C) : We've identified a concept for an entirely new activity which we believe has potential of being a differential.

• How to go about it? This novel act is uncharted by nature (being novel and new) and hence highly uncertain. It's a gamble but might provide us with a differential for our customers. I'd aim to minimise any costs by ensuring that underlying components consume commodity or utility services where possible. The approach we'd have to take is incremental i.e. we're going to be exploring our way and change is a necessity. I'd focus development on in-house with use of agile techniques (which include Test Driven Development). TDD is essential because though it incurs some overhead it reduces the overall marginal cost of change and I'm expecting lots of change. The approach will be one of minimal viable offering, quickly gathering feedback and "muddling through". We don't know what we will end up building, we'll have to find our way.

Now,  as per normal practice I'd break activities into small components with small teams (think FIST, Two Pizza etc) in order to focus on the right approaches, create the right cultural fit for that activity and use the right sort of people (pioneers, settler, town planners) but this is getting more into operational details. The point of the above is to show that once you've determined where and why, then the how varies accordingly. All three steps would probably occur simultaneously. Hence at the same time an organisation might embark on efficiency in one area, building of a utility in another and creation of entirely new activity with each using different approaches and methods.

Try doing that with one size fits all methods like "we're an agile shop", "we're a six sigma shop" etc etc. To answer Florian's question - incrementalism is a tactical approach (a how) to a specific type of problem. 

Now, if the above doesn't make sense to you, well I've been doing this for eight years and so it's easy for me to gloss over things and take them as granted. I will at some point write another beginner's series on this, just not now.

Four Basic Smackdowns on Economic Competition

Tl;dr Competitive gameplay requires an understanding of the landscape, the rules and experience in playing the game - there are no shortcuts.

The Problem

I read an awful lot at the moment on Entrepreneurship and I have to say that most suffers from a one size fits all mentality. It's the same issue with statements like culture eats strategy for breakfast  but usually expressed in terms of the top ten secrets of being a successful entrepreneur. Alas competition isn't that simple and the methods you use have to adapt with what you're doing. To demonstrate this I thought I'd cover some of the basic games of competition.

First, let us start with the simple premise that competition in business is like playing a game of chess. In order to play the game then you have to understand the board (the landscape), the rules of the game and then learn how to play. Many companies I met have no clear way of understanding the board let alone anything else. Hence everything seems random and one size fits all - either agile versus six sigma, push vs pull, network vs hierarchical, unstructured vs structured - tend to rule and we're bombarded with over simplifications from culture to disruptive innovation. 

Mapping

Contrary to popular belief there are ways of viewing the board. A technique that I've used successfully for the last eight years is mapping and I've given an example of a map from an extremely large heavy engineering project in figure 1.

Figure 1 - Mapping a heavy engineering project.

The map uses an axis of value chain from the visible needs of customers to the more invisible components needed to meet those needs versus an axis of evolution i.e. how evolved those components are. Once you have a map, there are some general rules of the game that need to be understood.

Basic Rules

• Organisations consist of many value chains

• Value chains consist of many components: Some of these components meet visible user needs and others that are invisible but enable that need to be met.

• Components include activities, practices and data.

• Everything evolves: All components evolve due to competition.

• Characteristics Change: As components evolve their characteristics change. For example the uncharted are rare, chaotic, constantly changing, deviating from what existed before, uncertain and a source of differential. The same component as it evolves becomes more industrialised and its characteristics are common, often provided through standard and what appear to be "linear" interfaces, it is known, measurable, deviation is undesirable and it becomes a cost of doing business.

• No one size: Since a value chain is likely to consist of many components at different stages of evolution with polar opposite characteristics (uncharted versus industrialised) then no one single management method is applicable across the entire value chain.  For any complex system it becomes important to break the system down into smaller components and apply appropriate methods i.e. it shouldn't be a case of agile versus six sigma but agile plus six sigma with each being appropriately used.

• Genesis begets evolution begets genesis: as any component evolves to a more industrialised form then this can allow for the rapid development of novel higher order systems, as in higher up the value chain.  For example, standard mechanical components (such as nuts and bolts) enabled the rapid development of machinery and engines. This is an effect known as componentisation.

• Efficiency, Agility and Wealth: evolution increases efficiency in provision but also through componentisation the rapid development and agility in building higher order systems. These higher order systems are also new sources of future wealth e.g. utility electricity enabled the creation of television and the media industry. 

• Choice is an illusion: The combined benefits of efficiency, agility and new sources of economic wealth are powerful competitive forces and hence organisations are forced to adapt as components evolve.  This is known as the Red Queen Effect.

• Co-evolution: the evolution of a component can force other components to co-evolve. For example, the evolution of computing infrastructure from product to utility has forced co-evolution of architectural practices from scale-up and n+1 to  distributed systems and design for failure.

• Inertia: Both consumers and vendors have inertia to change due to past success, existing business models, changes in capital whether knowledge (i.e. new skillsets needed due to co-evolved practices), social (i.e. changing vendor relationships), financial (i.e. past investment) or political (i.e. past choices). Inertia whilst manageable can often be fatal for an organisation by limiting adaptation when adaptation is actually a necessity.

• The speed of change is deceptive: Diffusion of any change has an exponential element but we are often lulled into a view of more linear change of evolutionary state because one “product” tends to be replaced by another “product”.  Hence we have the impression of a relatively long and linear process of improving computing servers (i.e. products). The shift from one evolutionary state to another e.g. product to utility has the same exponential element as the Red Queen creates a network effect of increasing pressure as more competitors adapt to it. In these circumstances our inertia to change due to co-evolving practices which is normally reflected in the “legacy question” combined with our past belief of more linear change (due to the long period of time that products have existed) tends to reinforce a belief that change will be gradual. It won't. This period of rapid but surprising change we call a Punctuated Equilibrium.

• The economy has states: The interplay between evolution and inertia creates different economics states that occur at both a macro and micro economic level. These include a relatively peaceful state of relative competition between product vendors where sustaining changes tends to exceed disruptive followed by a war state, a fight for survival caused by the evolution of product to utility. The war state is characterised by new forms of co-evolved practice, rapid and deceptive speed of change, new entrants and disruption of past companies stuck behind inertia barriers. This is then overlapped with a state of wonder where we see rapid development of new higher order systems, increased in new forms of data and flows of capital from past industry to these new wealth generating industries.

• Organisations evolve: The interplay between co-evolved practices (caused by evolution) and the changing economic states (i.e. peace to war) causing the disruption of past vendors tends to create new forms of organisation e.g. Fordism, Web 2.0. These organisations tend to demonstrate all the co-evolved practices and often have new methods of strategic gameplay.

• The map can be manipulated:  The landscape can be altered by changing rates of competition, use of open approaches (whether open source, open data or open hardware) or by deliberately driving a component to a more utility form. There are many strategic reasons for doing this from creating a new opportunity, undermining a competitors barrier to entry, building an ecosystem and running an ILC model, playing a tower and moat game to playing a standardisation game. 

Four Basic Smackdowns

Ok, now we have an idea of how to map and the basic rules of the game we can talk about four basic smackdowns of competition - i.e. how you fight.

Building the new
The first play is to build something that is actually novel and new i.e. the genesis of an activity such as the first ever telephone, first ever computer, first ever television. By nature this is highly uncertain, you don't know what customers will actually want as the act is new. 

You need to be adaptive, take a minimal viable approach and quickly create feedback loops with customers. You're in a fight to establish the new thing as being relevant and useful often in the face of bewilderment. Inherently this whole approach is uncertain, you just don't know whether it will succeed and whether people will want it. 

Building the novel and new can be done at any time, though there are certain times when the cost of reduction of underlying components makes certain novel acts possible.  The first televisions depended upon home electricity supply to be economically viable. This is why whenever we have an economic state of war caused by commoditisation (Custom made nuts and to bolts to standard nuts and bolts with Maudslay Screw cutting lathe, Electricity from own generators to utility services with Westinghouse and Tesla, Computing from products to utility services with Cloud)  then we see an explosion of higher order novel systems - a state of wonder. 

However being economically viable doesn't mean the act will succeed. Because the act is uncertain then you just don't know if it will work, you have to experiment, to fail fast and to gamble. Get used to it and work on this basis.

Substituting one product with another product
A second play is to go after an established product market with a view of substituting it for your product. I'm not going to talk about the more general product versus product competition of improving features as this is normal fare but instead the replacement of one category with another e.g. one format of hard drive with another format. 

To do this you have to find a property of the value chain which is not catered for and which will become important - e.g. size of hard drive, power consumption, provision of an application store. This novel property is uncertain and to establish it you'll almost always need to find an underserved market due to inertia within existing markets (i.e. customers and vendors are used to the other format). This is the classic case of disruptive innovation, using an uncertain property often developed in an alternative market to improve the product to a point that you can assault the main market where the vendors will be suffering from inertia due to existing business models.  

The uncertain nature of the property is both friend and foe. It protects you against incumbents because they'll tend to dismiss it but at the same time you don't know if it'll work. Hence this is another gamble but when it works you can seriously damage incumbents and take a chunk of the future e.g. smart phones vs mobile phones or ARM vs Intel.

Substituting one product with a utility
A third play is to go after an established product which is widespread and fairly well defined and create a utility service for it. This has all the benefits of a product to product substitution with existing vendors having inertia however it has several advantages over the former. First, it's not uncertain but instead a known process of evolution not reliant upon creating novel properties, hence it's far less of a gamble. Of course, this means it's more defendable against but since most companies have poor situational awareness of the landscape (i.e. they can't view the board) then they're not likely to defend against your move. 

Secondly, you can use ecosystem effects through models like ILC along with a host of other tactical plays such as using open source, open APIs, open data to enhance your position. This is the easiest play to make and the one most likely to give you success however the opportunity to make such a play depends upon the act being suitable and so you have to wait for the right timing. 

This is what has been going on with cloud and why I talked at OSCON in 2009 on how it was the perfect time to disrupt great giants. It might feel like you're David vs Goliath but just remember Goliath is looking the wrong way and can't see you coming.  You don't have to worry about their size, all they will do is help validate your market.  Naturally, the easy pickings have already been taken though some opportunity still exists but the window is closing. 

Examples of this include Amazon vs Dell, where Dell has now had the good sense to realise it has lost the public computing infrastructure battle for an activity (computer infrastructure) which it once was a dominant player. Knowing when to retreat is also an important part of the game.

Don't worry if you've missed the boat a new window of opportunity will open up around 2020 related to 3D printing / Printed Electronics and commoditisation of the manufacturing industry.

Substituting one utility with a utility
A fourth play which is incredibly hard to make work is to substitute one utility with another. Once a utility gets established and inertia sets in due to a large ecosystem built on top of the component provided then it's difficult to shake it. It becomes very hard if the vendor behind this is playing a good ecosystem game. Taking this on is less David vs Goliath and more like David vs Goliath and an Army of His Brothers all pointing straight at David with Gatling guns. 

To stand a chance, you'll have to counteract the impact of their ecosystem. Now remember, this isn't the same as a product ecosystem where information flows are slow (i.e. marketing surveys) but one which information flows are based upon consumption data and are almost real time. This is the toughest of all battles and the best plays are around co-option rather than substitution and huge bets i.e. think billions per year if you're taking on Amazon. Oh, and you'll need a master kung fu black belt oracle of strategy to make it happen and before you think you can just hire one, the number of people that I know who can pull off this trick are very few. They currently work for Amazon, Google, Microsoft, Dell, UK Gov, Cambridge University, Canoncial and seven other companies. None of them are consultants, you've almost certainly never heard of them and most of them are very wealthy. Good luck in trying to find one.

Beyond the Smackdowns

Now there's a myriad of options and gameplay beyond the four basic smackdowns from the use of resource constraints against opponents, weakening focus by reducing barriers to entry in an opponents business models, misdirection, tower and moat play, use of alliances, organisational structure and cultural fit, to an endless barrage of dark arts. Remember I've been doing this for eight years and it would take a long time to write this all down.

However, the point I want to mention is that even with the four basic smackdowns the approaches you need, the type of information available, how you focus, where you attack and when you can do this vary from a high risk gamble (building the new) to a low risk but time dependent gamble (product to utility substitution).

The idea that there are ten basic secrets applicable to all is like the idea there are ten basic secrets of playing chess. Beyond the trivial i.e. understand the board, know the rules, learn to play the game then the moves you make depend upon the situation at hand. Certainly you can learn basic moves which are applicable to certain situations but they are not applicable to all.