Consider the provision of an ordinary window. While a window is a standardized building commodity, the practices used to manufacture them have evolved dramatically from blast furnace and grinding to Pilkington’s float glass method. In other words, the way we make windows (the practice) has evolved but the window (the result of activity) remains roughly the same. Here we have independence of practice and activity. post 
However, in many cases as the activity evolves then the associated practices tend to co-evolve. For example, consider computing infrastructure. When infrastructure was primarily a product, novel architectural practices appeared for capacity planning which relied mostly on the use of more powerful machines (‘scale-up’). For system resilience we also had novel architectural practices that heavily relied on ‘n+1’ designs. Theses architectural practices were based primarily on better products (i.e. hardware) and they diffused and evolved becoming emerging, then good then best practice. However as the activity of computing infrastructure itself evolved to become more of a commodity that is these days provided through utility services (such as Amazon EC2) then novel architectural practices appeared based not upon hardware but on software. For capacity planning we now had the novel practice of ‘scale-out’ (i.e. the use of large numbers of small and good enough virtual machines) that started to diffuse and evolve becoming emerging and then good practice. For resilience, the novel practice of design for failure appeared and also started to diffuse and evolve becoming emerging and then good practice. Hence, as infrastructure has evolved, the practices of infrastructure management have also evolved. This inter-relationship of practice and activity is shown in Figure 17.
Figure 17 Co-evolution of Practice and Activity.
This co-evolution of practice and activity can create significant inertia to change for consumers of that activity. In the case of infrastructure, if the consumers of large powerful servers had developed estates of applications based upon the practices of scale-up and N+1, then as the activity evolved to more utility services those consumers would incur significant costs of re-architecture of the “legacy estate” to the new world. Our current way of operating often creates resistance (or inertia) to change due to the costs of changing practices (see figure 18). In many cases we attempt to circumnavigate this by applying the “old” best practice to the new world or we attempt to persuade the new world to act more like the past. Today, cloud computing is an example of this as it represents an evolution of parts of IT from product to utility services and the “legacy” is often cited as a key issue for adoption or for the creation of services which mimic past models.
Figure 18 Inertia due to co-evolution of Practice with Activity.
By now, the reader should have some appreciation that :- * Organisations can be described through value chains of activities, practices and data. * All the components of that value chain are evolving and sometimes co-evolving. * Plotting value chain vs the state of evolution can create a map of this landscape. * As those components evolve their characteristics change which is why one size fits all techniques are ineffective. * Our inability to see and to deal with evolution causes common problems such as the perils of outsourcing and business alignment * The co-evolution of practice with an activity can create resistance (i.e. inertia) to change due to the costs associated with it. In comfort to the reader, Simon Wardley will now tell you that we are slowly getting to the good stuff and all of this is necessary to understand it. But before we do, we have a few more hurdles, as we need to explore the relationship between genesis and evolution along with macro and micro economic effects. Then we should have enough to start using the map to exploit our position and explain strategy.