In the previous post I talked about Evolution, Maps and Bad Choices. I wanted to express the importance of understanding evolution (i.e. movement) in order to anticipate change. In this post I want to explore that subject more.
Let us start again with that first map from 2005 which was of a single line of business for an organisation I ran (Figure 1).
Figure 1 - A map of Fotango
From the map we had users needs (step 1), the value chain expressed as chains of needs (step 2) and we understood (and could anticipate) that compute was going to evolve from product to utility (i.e. cloud). We could use weak signals analysis to determine this was going to happen soon - in fact AWS launched EC2 the following year. The map gave us position (i.e. relationship of components) and movement (i.e. how things are evolving).
Now let us explore more. In figure 2, I've focused on the compute aspect. We knew that compute (an activity or what we do) had associated practices for architecture (i.e. how we did stuff) - see step 5. Those practices were best practices for the industry including N+1, Scale Up and Disaster recovery.
Now, practices evolve in an identical manner to activities (driven by the same competitive forces) we just call them novel, emerging, good and best. We also had applications (step 6) built on those best practice (step 5) for the product world. However, compute was evolving (step 3).
Figure 2 - Practice and Activity
As compute evolved then the architectural practices co-evolved (see figure 3). Novel architectural practices appeared (design for failure, chaos engines, scale - out) based upon the concept of a more evolved form of compute. We happened to call those architectural practices DevOps (step 7) and applications were built on them. Those practices themselves evolved becoming emerging then good and heading towards best practice for the utility world (Step 8).
Figure 3 - Co-evolution of Practices.
This created a situation, show in figure 4 below. Part of the application estate was based upon best practice (traditional) for a product world. We call this LEGACY but I prefer TOXIC IT (see step 9)
At the same time part of the estate was built on good and evolving practices (DevOps) for the utility world. We call this the FUTURE estate (step 10).
Figure 4 - Legacy and Future.
Now, what will happen is that eventually the estate will consolidate on the future estate i.e. applications will be rewritten or replaced and built on the best practice of "DevOps" (see figure 5).
Figure 5 - The Future.
We knew this in 2005. I used this knowledge in part of the gameplay of Ubuntu in 2008. What we didn't know was what it would be called, what exactly those practices would be and who would lead the charge.
We knew that some companies would resist the change (i.e. have inertia). There are 16 common forms of inertia from political capital, cost of acquiring skills to cost of changing governance of the current estate (including re-architecting) but we also knew that competition means no-one would have a choice. There are some very specific impacts of evolution which creates an effect known as the Red Queen. You never had a choice about cloud, it was never a question of "if".
However, we also knew that some people would try and somehow have this future world but without changing the past. The first attempts were private and enterprise cloud. As that lost ground, the latest efforts are combining these with public cloud in order to create a hybrid (see figure 6) and step 12.
Figure 6 - Hybrid.
The reality is that private and hybrid was always a transitional play. The speed of change however is exponential (known as a punctuated equilibrium). We can clearly see this happening from Amazon's AWS figures. By today, you should already be in the process of (or at least planning) decommissioning your private cloud environments having sweated and dumped much of your legacy. You should be starting your path towards data centre zero. You've had at least ten years to prepare for this and the game has been in play for eight of those. Fortunately I do see this happening with some very large and "traditional" looking organisations (finance, pharma etc). In other cases, well ... this brings me to my last point.
There are 16 different forms of inertia including social relationships with past vendor, political capital and existing practices. If you're still building out a private cloud or embarking on a private cloud effort today then chances are you've got a very operational CIO. With a few exceptions, these people aren't thinking about gameplay, the impact of future pricing differentials and they probably lack the skills necessary to understand effective use of supply chains.
Don't get me wrong, there are very strategic CIOs out there but these aren't the problem, in those companies you see adaptation happening already. However if you had found yourself lumbered with a non strategic CIO then these are the people you should have been planning to replace with a more strategic CIO - which after all was the real reason we hired CDOs (Chief Digital Officers).
Assuming you didn't do something crass and get lumbered with a non strategic CDO (i.e. constantly waffling on about innovation, disruption and story telling without any clear understanding of the landscape) then now is probably the time to be considering that change. If, however you only hired a CDO because every other company did then heaven help you. Just pray your competitors are in the same boat and your industry isn't interesting enough or has large enough regulatory barriers or cost barriers to prevent anyone else taking a pop at you.
Your CDO should by now be embedded in the organisation, the costs of acquiring skill sets is only going to increase, there'll be a crunch in demand as enterprises all try to head towards public cloud, the toxic element of legacy will start to show up in your P&L, your cost of trying to keep up with adapted competitors will escalate and somehow you're going to need to be able to navigate this landscape safely. In the next few years then things will really heat up. You should be well prepared and motoring by now and if this isn't happening then it's time to start thinking about pulling that lever and making that switch.
Your CDO should by now be embedded in the organisation, the costs of acquiring skill sets is only going to increase, there'll be a crunch in demand as enterprises all try to head towards public cloud, the toxic element of legacy will start to show up in your P&L, your cost of trying to keep up with adapted competitors will escalate and somehow you're going to need to be able to navigate this landscape safely. In the next few years then things will really heat up. You should be well prepared and motoring by now and if this isn't happening then it's time to start thinking about pulling that lever and making that switch.