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.