Paradoxes of Organisation

I've just seen Dave Gray's post on the paradoxes of organisation. Oh, this is a wonderfully rich area and something I'm looking forward to reading.

Over the years (based upon evolution), I've noticed several patterns from conflicts (innovation vs efficiency, agile vs six sigma) to misunderstandings to paradoxes. From Ashby's to Jevons' paradox to the impacts of componentisation then there is lots of interesting material.

Four of my favourite paradoxes in business (with each argument described by a scale from 0 to 1) are :-

Predictability (of what) + Predictability (of when) ≈ 1 (i.e. we can often say what will happen but not when or when stuff will happen but not what)

Potential for future value + Certainty of value  ≈ 1 (i.e. the more something has potential, the less certain we are about it. If we're certain about it then so is everyone else and the value is correspondingly smaller)

Simplification of management + Effectiveness of management ≈ 1 (impact from Ashby's law of requisite variety i.e. the more we pretend management is simple, the less effective it becomes.)

Organisational focus on survival today + Probability of survival tomorrow ≈ 1 (impact from Salaman & Storey i.e. survival today requires coherence, co-ordination and stability whilst survival tomorrow requires 'innovation' and hence a replacement of those values)

A necessary capability but an unnecessary role - CDO.

Any widespread examination of corporate strategy will quickly demonstrate the prevalence of backward causality and the copying of others. 67% of companies have an "enterprise mobility strategy" ... do you? If this wasn't the case, my strategy template wouldn't have touched so many nerves.

Depressingly less than 30% of large companies have any form of scenario planning and of those less than 4% have any formal means of situational awareness. The majority are playing chess without looking at the board which is why techniques like SWOT or Business Model Canvas or single size debates like Agile vs Six Sigma become rampant. This is why it's so easy for someone like me to walk into an industry and help myself - I'm no genius, I just understand that looking at the board (even an imperfect representation) in a game of chess is actually a sensible thing to do.

By understanding the basics of competition, we know that organisations evolve and a new phenotype appears. We know how (competition), we know the causes (co-evolution plus punctuated equilibrium plus inertia), we understand the cycle and it is even predictable, testable and this has happened. I can even give you a list of the modern phenotype (from 2011) - see figure 1. We can trace the process back through hundreds of years of history from the Web 2.0 to Fordism to the American System.

Figure 1 - Next Generation vs Traditional

We know that strategic play is not uniform between companies, even in the high tech sector. We know the economic impact of poor situational awareness - see figure 2.

Figure 2 - Strategic Play vs Action

We know our organisations have difficult coping with change, we normally bolt on new roles and new departments to cope with the change. But this is not a sensible course of action but instead a symptom of a non adaptive structure - we bolt on because we cannot simply absorb the change. Given however that few can see the landscape and predictable changes heading towards them, this is probably no surprise.

However, be under no illusions that improving situational awareness and creating adaptive structures is complex, it's not simple, it doesn't fit into a neat 2 x 2. Inherently a map is more complex than a SWOT.

So, yes we are undergoing changes, many of which are predictable and we need to adapt. Since our organisations are not designed to do this, we've often bundled those phenotypic changes into roles - we hear the clarion call for Chief Insight Officers, Chief Data Officers, Chief Ecosystem Officers, Chief Digital Officers, Chief Open Source Officers, Chief Disruption Officers and on and on and on. 

It should be no surprise that the justification given is usually because "others are doing this" - backward causality and the search for simple answers remains as strong as ever. The words of wisdom I will leave you with belong to Phil Rosenzweig. 

When examining the marriage of convenience between business and the academic / consultancy groups that surround it, Phil concluded - "Managers are busy people, under enormous pressure to deliver higher revenues, greater profits and ever larger returns for shareholders. They naturally search for ready-made answers, for tidy plug-and-play solutions that might give them a leg up on their rivals. And the people who write business books – consultants and business school professors and strategy gurus – are happy to oblige. Demand stimulates supply, and supply finds ready demand. Around and around we go” 

Ah, the merry go round continues. All hail the new priesthood. Today's version appears to be the Chief Digital Officer. Tomorrow's will be something else. One day business will learn the lessons of the military from two thousand years ago and start to understand the landscape we compete in. Until such time, expect tomorrow endless calls for "Chief Ecosystem Officers, well HBR's got an article and 67% of other companies are hiring one" etc etc etc.

Learn the capabilities, they should be absorbed. Try to avoid building structures you're going to simply dismantle later on. The capabilities of a Chief Digital Officer are needed, as for the role itself - well, maybe as a transitional structure to force change in an organisation that is unwilling or maybe there's a specific need (assuming you know what you're doing). In all likeihood most will be hired because 'other companies are hiring one'.

Just remember it is the capability not the role that is important.

My viewing habits ... 100 hours

Out of curiosity, some time ago I started to record my viewing habits. Out of the last 100 hours of "recreational video" that I've watched then approximately :-

2% on Terrestrial TV
2% on 4OD
2% on Amazon Prime
4% at the Cinema.
9% on BBC iPlayer
34% on YouTube [highest volume]
47% on Netflix

If Wardley mapping is so powerful ...

... why isn't it more commonly used?

For over a decade I've used mapping to startling effect having outwitted much greater foes and reduced waste in existing environments. From many hundreds of millions in new opportunities, cost savings and raised funds. For those few who use mapping in earnest, the smorgasbord of management doctrine feels outdated and current popular tools simple artefacts of a deeper process. Lessons such as the use of multiple management methods become ingrained, tactical gameplay around ecosystems becomes second nature and strategy takes on a new meaning. There is no turning back when you start mapping.

To contrast today's thinking with mapping then I'll return to the battle of Thermopylae (the tale of the three hundred) and the clash between the Greeks and the mighty army of Xerxes.  The great general Themistocles devised a strategy where the narrow pass of Thermopylae would be used to hold back the Persians whilst the Athenian navy would block the straits of Artemisium (see figure 1).

Figure 1 -  Battle of Thermopylae

Now, imagine a universe where Themistocles had no situational awareness e.g. no map and no understanding of the landscape. Imagine on the eve of battle, if the troops had been called together and Themistocles had tried to rally them with a strategy not based upon the environment and context of battle but instead based upon the presentation of a SWOT diagram (see figure 2).

Figure 2 - Themistocles' SWOT

Now compare the two figures. What is more useful in battle - a map or a SWOT diagram? Now ask yourself, what do you more commonly see in business?

Had it been the normal practice to base a strategy upon a SWOT as opposed to situational awareness then I doubt we would have ever got the legend of the three hundred, the Greeks would have lost to the Persians and things would be very different today. On the bright side we might have avoided a very dodgy Hollywood film. Fortunately, Themistocles was well versed in situational awareness.

To be honest, I find teaching situational awareness hard in business because few CxOs have a military background and understand its importance. The best text on business is still a 2,200+ year old manuscript (the Art of Warfare) which very few understand. However, 'Wardley mapping' - as it has been nicknamed - continues to show its usefulness and is slowly gaining traction. 

For those wanting to know how to map - the key is to start (imperfect maps are better than none) and a simple step guide is provided. I occasionally hear strategy consultants tell me that they do something similar, well let us be clear - that appears to be prattle. In a decade I've seen no evidence of any kind whatsoever of a similar technique. Fortunately the technique is all creative commons, so have a go yourself. You don't need strategy consultants, they are generally a waste of time and money giving you little more than copying others.

Which leads me to the question of why don't more companies use it? Well, the technique might be ineffective and the observed benefits just simply coincidence. There are many examples of positive use and whilst it seems unlikely that this is just fortuitous chance it cannot be discounted. However, more likely is that change in management practice is extremely slow. Given this assumption then it'll take 15 to 20 years before mapping makes any kind of dent (assuming it continues to demonstrate positive effects and isn't superseded by something else). That's just the way things are.

However, there's another problem. Take a look a figure 1 and figure 2 again. When using a map Themistocles could have decided to defend around Athens or Thebes or any number of 'wheres'. The why was a question of why here over there. In the end, a strategy was devised to take advantage of the landscape and to funnel the overwhelming forces of Xerses into the hot gates. This process of strategy is inherently more complex than a 2 x 2 matrix. It's more reactive, requires greater understanding and flexibility. The 'Keep it Simple Stupid' mantra would argue for the use of a SWOT and abandoning any form of mapping.

I suspect that this complexity will be the real problem with maps and why adoption will take a very long time (more like 30 years) regardless of benefits. It's the same issue behind our love affair of single size approaches - outsource vs insource, push vs pull, agile vs six sigma, or hierarchical vs network. We like simple.

Maps, like life, are by nature more complex than our desire for simple answers.

Historically, approaches which change our way of thinking and shift us from a simple view of life - whether Boyd's OODA loops (1973), Business Relationship Management (Ernst & Young, mid 1990s), Cynefin (Snowden, 1999) or Scrum (Takeuchi et al, 1986) - take a long time to spread. Mapping has a long and slow road ahead of it in which (despite its apparent usefulness) it will have to stand the test and rigours of time. I am under no illusions regarding this.

However, on a positive note then this also has a considerable upside. Uncommon use will mean that mapping will retain for many years any ability it might have to create a significant competitive advantage over others. I still expect in a decade's time to be able to understand and map an industry, then play the game and take over an entire market with a fraction of resources of competitors. I still expect to be playing chess against competitors who can't see the board well into old age. I expect by then, I'll be an even better chess player.

I'm ten years into this journey but as Lao Tzu would say "a journey of a thousand miles begins with a single step". There's a long long road ahead but it looks like a pleasant journey.

Three of my favourite taunts of business - adoption, egosystem and SWOT.

Every now and then, I find something in business so ridiculous that it tweaks my sarcasm gene into overload. I normally respond with a graphic on the subject. I have many of these little gems scattered in my blog but my three favourite are ...

1) The Enterprise Adoption Cycle

A comment on the state of inertia within organisations.

2) Ecosystem vs Egosystem

A comment on strategic play exhibited by some companies in the cloud space

3) Thermistocles' SWOT

A comment on the artefacts we often call strategy in business.

Themistocles' SWOT

The battle of Thermopylae (the tale of the three hundred) and the clash between the Greeks and the mighty army of Xerxes has echoed throughout history as a lesson in the force multiplier effect of landscape. Themistocles devised a strategy where the narrow pass of Thermopylae would be used to hold back the Persians whilst the Athenian navy would block the straits of Artemisium.

The tale is a lesson on why understanding the environment (situational awareness) and exploiting it is critical in combat and why maps of the environment are powerful military tools.

Alas, it turns out that this tale is wrong. Recently discovered archaeological evidence has shown that rather than using awareness of the environment, Themistocles had no situational awareness at all. Instead, the troops were roused not through cunning strategy but the use of a SWOT (strengths, weakness, opportunity and threat) diagram which was presented to the troops in 28 pt Arial on parchment. The original Greek document has now been translated and is provided below.

Themistocles' SWOT

Please note, the next time someone turns up with a strategy document which has no map of the landscape but instead either a business model canvas or SWOT diagram masquerading as strategy - I will laugh mercilessly at you until you go away.

Both Business Model Canvas and SWOT diagrams are perfectly useful communication artefacts of the process of scenario planning but they are post event. Without a map, even an imperfect map then you have no strategy. Well, certainly not anything I'm going to take seriously.

Oh, and btw ... I ran strategy for Canonical in cloud between 2008 and 2010. I mapped the environment and with others we learned where to attack, knew where to not get in the way of others, used what was there to our advantage and exploited the inertia of competitors. With a small team and paltry resources (tiny fractions of our competitors) then in two years we took Ubuntu from a bit part of the operating system market to around 70% of all public cloud. Mapping helped me enormously to explain to others and to determine where to attack. Fighting Red Hat was like stealing candy from a child ... I felt guilty over how ridiculously easy it was to walk in and help myself.

Now, maps are imperfect and I'm no Thermistocles or miracle worker but if someone like me can waltz into a market and take it over through the use of a map then I have to say the strategic play in the world of business is pretty poor. In fact, I already know it is.

On Co-Creation ...

Co-creation is an extremely useful technique but it should be remembered that it's not suitable across the board. When I examine a map of the landscape then I tend to advocate its use in particular circumstances.

However when creating the novel and new (i.e. the genesis of an activity), it's actually better to get everyone else to create it for you and to exploit their creations to identify success. This is more You CREATE and I EXPLOIT and there is little collaboration to it.

An example of this is the ILC (innovate-leverage-commoditise) model which I've talked about extensively in the past. The model starts with a company first creating the industrialised services that you build upon (what is often called a platform) and then growing an ecosystem of companies consuming those services. 

The technique is incredibly powerful (it's a force multiplier in competition). If correctly used then my apparent :-

1) rate of innovation i.e. how much YOU are creating for me to EXPLOIT

2) rate of customer focus i.e. how much I'm EXPLOITING creations YOU made to give to others

3) rate of efficiency i.e. how much I take advantage of economies of scale by all YOUR use.

4) stability of revenue i.e. volume of predictable industrialised services I'm providing to all of YOU.

5) ability to maximise opportunity i.e. how much I am able to spot future success from YOUR experiments.

... all increase, simultaneously with the size of the ecosystem.

Spotting a company using an ILC like model is fairly easy. Whilst the company might grow in terms of physical numbers of employees, it's apparent rate of innovation, customer focus and efficiency all seem to accelerate at a faster rate (because it's growing with the size of the ecosystem). Worse, this seems to happen all at the same time (counter to the old ideas of you can focus on one).

A telltale signal is when people & other companies start grumbling that this company has just trampled all over their business models. Words like 'eaten the ecosystem', 'bully' tend to get mentioned a lot. At the same time, customers (i.e. those not being trampled on which can include other companies) benefit from the net effect of an increasing number of useful services. This tends to act as a magnet and the model is therefore reinforcing with plenty of network effects.

Anyway, more information on ILC can be found from reading the above post (linked here also).

So, why do I mention this? Well, first of all the ILC technique has been in operation for almost a decade. Hence, to anyone who is recently discovering the force multiplier effects of ecosystems - can I suggest that something is going terribly wrong with your horizon scanning. 

The second reason is someone just asked me whether I thought Amazon was a good example of co-creation. Oh, you're kidding right? Seriously?

Data points for mapping ...

The mapping technique I describe (known as Wardley Mapping) is not widely used, in fact usage is quite rare. However, seeing that I made the technique creative commons many many years ago - I don't actually know how many people are using it.

Of those that I do know then I have numerous examples on impact e.g. :-

1) Estimated reduction in cost of an entire project by 30%

2) Reduction in cost of individual project transactions between 99.3% and 99.6%.

3) Identification of new opportunities and successful funding of new business to exploit this (around $70M raised in total).

4) Increase in market share in an emerging field from 5% to 70% with minimal (sub $1M) investment.

5) Identification and removal of project risks for large scale projects (in excess of $100M).

The problem of course is that "numerous" isn't the vast number of examples I need. Even the examination of high tech companies on strategic play (see figure 1) only covers 160 high tech companies.

Figure 1 - High Tech companies, Strategic Play vs Action

Now mapping has a reasonably solid base in terms of the research on evolution. But unlike the evolution work, it lacks the many thousands of data points that I require to confidently say (to my satisfaction) what the impact of mapping is to most organisations. The signs all look encouraging but that's not enough. I like my work to be backed by large volumes of supporting evidence as opposed to handfuls or a few hundred. I'm not into the "this company did A and is successful, so you should do A too" world of backward causality.

I don't obviously expect to get this data anytime soon - it'll be a very slow road (i.e. 10 -15 years). However, if you are using mapping then please take a short amount of time to jot down the impacts (positive, negative and no impact) and ping me.

On D&D vs Ant Battles - a Question of Strategy

Recently I posted on the question of "Dungeons & Dragons vs the Art of Business Strategy" and received this wonderful riposte to the same. I do like a good joust and much of the response is perfectly reasonable.

Now, whilst I don't view D&D as a teaching tool itself, I do view it as a remarkable comparison between how a gaming environment and business operates. The premise that I proposed is that business can do better if they understand their environment, their capabilities and roles, improve their team play and prepare (i.e. scenario plan and train).

The impact of the first of these premises (the necessity of situational awareness) is demonstrated in the following graph (figure 1). This examination of 160 high tech companies showed that those with poor situational awareness tend to have a negative market cap growth over a seven year period. It seems that situational awareness is important to all endeavours of competition whether business, military or D&D.

Figure 1 - Examination of Strategic Play vs Action

In business we often have no form of competitive maps but instead rely on what should be artefacts of scenario planning. In the worst cases those artefacts (business model canvas, SWOT, kaplan strategy maps) become the primary source of awareness and the scenario planning required to create them isn't even done. This is my primary issue and why I made the comparison between D&D because such a basic element of strategic play shouldn't be missing from business. But alas, it more often than not is.

This absence often shows itself in the 'strategy' of a business being little more than a tyranny of action (how, what and when) with operational, implementation, purchasing and tactical choices.  This is opposed to situational awareness (where and why) being dominant. 

The 'why' itself can often be reduced to the copying of others on a premise of backward causality.  If A does B and A is successful then we too should do B. Hence many companies have identikit strategies covering topics like cloud, big data, social media, IoT but little awareness of why or the context they exist within. I have poked fun at this before. It is depressingly common.

Whilst I agree that strategic planning is complex especially over a considerable period of time, the basic premise of understanding your environment appears to apply regardless of time or complexity. Whether within Government or commercial settings, I have witnessed first hand the devastating effect of understanding the environment. Now, I do not propose that companies simply copy the actions of others but instead understand their environment before acting. 

We often like to think that business is like a game of chess. The reality is more akin to a game of chess with competitors that rarely look at the board before moving. I'm not being disingenuous when I state that D&D groups often have far greater situational awareness over their environment than a business does over its - that often appears to be the case.  I wouldn't also compare business to military because the level of strategic play within the military far exceeds anything I've ever witnessed in business, even in the most high tech of companies. 

This alone is why I often smile when I hear people ask how do we make the military more like a business? My normal response is - "Take away any maps, don't allow people to understand an environment before engaging, remove scenario planning and training, add in poor communication and replace combat strategies with a vision and some nice stories - once done, you'll be just like most business".

Now obviously, the scopes are different and business is a continuous and draining act of competition. However, it's for these very reasons that I strongly suggest we learn the basics from other competitive groups because we appear far behind them in terms of play. There are exceptions and there are companies such as Quid and Palantir that are trying to change this. But I do recommend that we should be realistic about business and not to be lulled into believing we're some bastion of strategy.

Instead, what we normally are is - an organisation with communication, management and control issues competing in an environment over which we have little to no situational awareness nor mechanisms for learning nor understanding of basic principles of change but in which we take action. 

Our saving grace is our competitors are normally in the same boat. In competition it's ok to suck as long as everyone else does.

Maps are imperfect but that's ok ...

The mapping technique I use (commonly known as 'Wardley map' - see figure 1) is imperfect. These maps are simply a representation of the problem but the act of making a map has some profoundly useful effects.

Figure 1 - A Wardley map

The useful effects are :-

1) It encourages you to think about USER needs. The map starts from the visible user needs and moves through the components necessary to make that need happen.

2) It encourages you to think about COMPONENTS. Rather than treating a system as one thing, mapping encourages you to break down complex systems into components and understand that a complex system is in fact many things.

3) It encourages you to think about METHODS. Rather than treating a system with one method, mapping helps people to understand that as a component evolves then its properties change (from uncharted to industrialised) and hence the methods you use are different. Use of multiple methods (Agile, Lean, Six Sigma) in a single system at the same time is appropriate. Hint: you can co-ordinate a mass of different components using different methods (agile, six sigma and lean) through a scheduling system such as a Kanban board.

4) It encourages you to think about CHANGE. Evolution is not static, the components evolve due to competition. Mapping teaches you that how you treat something today is not the same as tomorrow.

5) It encourages you to COMMUNICATE. One huge advantage of a map is that other people can read it and obviously compare to other systems. Having maps is extremely useful in identifying common components between systems, to avoiding duplication and for sharing plans and strategic direction.

6) It encourages you to CHALLENGE. If you can read a map then you challenge the assumptions made especially by comparing a map to the outside world. Is CRM really at the stage of custom built or are we custom building what is in fact common and ubiquitous and suitable for commodity provision?

7) It encourages GAMEPLAY. Once you have a map, you can ask questions about how to change it e.g. using open approaches to drive to an activity, practice or data (all can be mapped) to more of a commodity or slowing this down with dark arts, constraints or regulation. Manipulation is at the heart of strategy.

8) It encourages you to PLAN.  Once you have a map, you can test various scenarios and examine the probability of effectiveness of one scenario over another.

9) It encourages you to LEARN. With a map, you examine the effect of a given play before and after. This helps in learning what plays work, how economic forces change the landscape and how force multipliers (e.g. ecosystems) can be used.

10) It helps you to MITIGATE risk. Examining different scenarios, breaking down complex systems into components and effective communication are all necessary mechanisms for mitigating risk.

11) It helps you to COMPETE. Mapping can equally be applied to competitors to discover points of weakness, inertia to change and tactical plays (e.g. Tower & Moat) that you can exploit against others.

12) It helps you to find OPPORTUNITY. Understanding that the uncharted space is all about differentials and the industrialised is all about operational efficiency enables you to identify potential areas for improvement and how to exploit it.

13) It focuses on CAPABILITY and ORGANISATION. Once you have a map it becomes fairly easy to identify what aptitudes (skills) and attitudes (pioneers, settler and town planners) are needed for each component.

Now, if competition, strategic gameplay, opportunity, communication, risk mitigation, capability, scenario planning, challenge, organisation and user needs are not important to you then you probably don't need a map. If however the above is important for you then a map - even an imperfect map - will help you. The beauty of maps is of course that they can be shared and it is this act that improves them.

Robots vs Intelligent Software Agents

When examining potential points of future change, I use a very purposeful distinction between robotics and intelligent software agents. One is a component of the other.

Robotics is rapidly heading towards a state of early generic robotic platforms (as per Baxter) which over time promise greater commoditisation of this space (often associated with human physical effort). As we all hopefully know by now, it's never the first innovation of something that overhauls our society but commoditisation of pre-existing acts. Robots have existed for sometime, generic and hence more commodity robotic platforms haven't.

However, those generic robotic platforms are limited in scope to the system in question because the "intelligence" behind them is targeted to that scope. When you examine medical systems or self driving cars or SIRI or any number of environments - the intelligent agents are specific. There is no generic intelligence agent ... yet.

But there will be (see figure 1).

Figure 1 - map of robotics.

Today's "intelligent" agents are still in relatively early stages. But in the near future the "intelligent" agent needed to drive your car will be no different to the one that flies a plane, delivers your coffee or undertakes your cosmetic surgery. Obviously those "intelligent" agents will be trained for the task in hand and some will be trained for multiple tasks. But this "intelligent" capacity will be very much a commodity.

So what's with the distinction here? Why bother?

Well, as things evolve they go through the stages of wonder, peace and war. It's never the wonder but the war stage (where things become commodity) that impacts society widely depending upon how well spread the activity, data or practice is in other value chains. 

Hence in this case, then in the first instance we will see disruption and change caused by the introduction of generic robotic platforms but because these will have targeted intelligent agents they will be generic to a specific area - the intelligence behind self driving cars will not be the same as the intelligence behind your surgeon. Hence to some extent the impact will be constrained. Much of the disruption will start in robotics manufacturing and existing industry users. These targeted systems will tend to be adopted by other industries hence the self driving car will be a feature differential of high end vehicles and not a destroyer of the automotive industry.

Alas, there's a later stage when the intelligent agents become commodity. At this point we will see truly commodity platforms in robotics and numerous other fields. This in turn will drive commoditisation in those sectors. Every car, every airplane, ever railway, every truck, every 'doctor' will be a 'self driving' and intelligent machine based upon the same intelligent system. The once benign feature differential of high end cars becomes the commoditising force behind the entire industry.

So why mention it? Well, I've summarised this in figure 2.

Figure 2 - Impacts of War

In the first wave (2020-2025) we should see rapid introduction of generic robotic platforms for different activities based upon targeted intelligent agents. Expect commercial high end self driving cars, increased use of robotic platforms such as Baxter. The impacts of this will generally be adopted by various industries from automotive to transport to healthcare. Disruption will tend to be fairly minimal or localised to existing users and robotics industry.

In the second wave (2030-2035) then you should expect to see the rapid introduction of generic intelligent agents. The agent that drives your car, pilots the plane, automates your house will be the same. This will rapidly spread impacting and commoditising multiple industries. Every car will be self driving - not that you will own a car anymore, you'll just pay for the use of the journey through an Uber like service. The entire transportation system will change. Many will be disrupted.

Now whether the timings are right here is highly questionable. The overall transition to commodity depends simply upon competition but the timing depends upon individual actors actions - this is always unpredictable (see Hayek and the pretence of knowledge). There is also constraints such as power and impacts such as Jevon's paradox to consider.

I would suggest however, that before people claim doom to humankind and our role in society due to the introduction of generic robotic platforms that they consider there are two waves approaching. The later is unquestionably the more dangerous in terms of social policy but it also allows for the greatest possible number of recombinations of higher order systems and hence the creation of unimagined roles today.

In much the same way the gas lamp lighter could see their job going but no-one could tell them that we'd have radio producers, television personalities and computer programmers - then the Barista maybe worried by a robot but find themselves later on as a counsellor to a neurotic intelligent agent. Can you honestly say that intelligent machines aren't going to need psychologists? Have we forgotten that the best chess computer in the world can beat a human BUT an average chess player with an average chess computer can beat the best chess computer?

So, will everything be rosy? No. But the real threat to society is not so much the machines but other humans and self interest. I'll leave that post to another time - fortunately by my reckoning then we still have quite a bit of it left.

Rough guide - use cloud, build cloud or micro-services?

A quick and rough guide.

First, map your environment. Remember that the rate of innovation of novel and new components (i.e. higher order systems) is exponentially related to the level of industrialisation of the underlying components (an effect known as componentisation).

With this in mind, then ...

Figure 1 - using a public cloud.

Figure 2 - building a public cloud service.

Figure 3 - How to build? Micro services or not?

First, I'd like to note that every node in your map is a component and ideally would be built as a 'small' and relevant component (see USAF FIST) for the activity that the component represents. Hence, for the activity of computing infrastructure then in the past we used product components such as servers though today we tend to use utility service components such Amazon EC2. Not breaking things down can cause all sorts of issues - see ASPIRE. 

From the above example, it should be clear that how a component is delivered depends upon how evolved the activity is. In some cases the component can be provided as a product, in other cases (when the act is less evolved) you have to custom build it whilst in others (when the act is highly industrialised) you can use utility services or commodity components. The type of component you use to deliver an activity will also change over time (as the act becomes more evolved).

HENCE don't rush to build a public service for a novel act because it will rapidly change (evolve) in both code base and interfaces. Let me emphasise, the interfaces are anything but stable. Hence an 'experimental' code base with objects in a code repository is more than enough at this stage. Don't enforce its rapidly iterating schedule and changing interfaces on other consumers in your organisation. Let them choose the version they wish to use.

However - word of warning - ask yourself is this really a novel act? Just because it's the first time you're doing something doesn't make the act novel. For example, user object, security permissions, financial transactions are anything but Novel. So, check with the market and find out how evolved (i.e. ubiquitous and well defined / understood) something is.

Assuming the act is novel then as it evolves and the interfaces start to become more stable then by all means start to consider providing it as a common library and then as a micro-service to others. Yes, everyone using other versions will have to refactor a bit for use of the new micro-service. 

For the more industrialised components, if you're not using utility services or your own micro services (in an ideal world the service would be both) then please ask yourself 'why?'

The above was brought to you with experience of building large and complex environments for millions of users with micro and some not so micro services between 2003-2006.

Snippet - Fotango Board Pack, 2007.

Yes, we had a mass of component services throughout the organisation from storage to server provision to utility billing to fulfilment to printing with configuration management, auto deployment and near continuous deployment of code.

However, maps and these techniques are simply a rough guide and not a substitute for thought.

--- 16th May 2015

If you want to learn more about this, you can always find members of the old Fotango crew speaking at various conferences. Always try and grab a few minutes with Artur Bergman (now, CEO of Fastly) and James Duncan (now, a CTO within UK Government).