https://medium.com/wardleymaps/exploring-the-map-ad0266fad59b

1*H9kGJvIcoAyYXAevubbrcg.jpeg

Hurray, we’ve got a map! What now? The purpose of producing a map is to help us to learn and then apply basic climatic patterns, doctrine and context specific forms of gameplay. Maps are our learning and communication tool for discovering these things and enabling us to make better decisions before acting. However, the strategy cycle is iterative and we’re not going to learn all the patterns the first time we use a map any more than we learn everything about Chess in our first game. Instead, like a game of chess then play by play, move by move we’re going to get a little bit better.

This is what happened to me starting in 2005 and even today in 2016, I’m still learning. In this chapter, I’m going to start looping through a single pass of the strategy cycle, see figure 19

Figure 19 — Looping through the strategy cycle.

Figure 19 — Looping through the strategy cycle.

Learning climatic patterns

Climatic patterns are those things which change the map regardless of your actions. This can include common economic patterns or competitor actions. Understanding climatic patterns are important when anticipating change. In much the same way Chess has patterns which impact the game. This includes rules that limit the potential movement of a piece to the likely moves that your opponent will make. You cannot stop climatic patterns from happening though, as you’ll discover, you can influence, use and exploit them. In this section, I’ll go through a number of climatic patterns relevant to business and then we will apply them to our first map.

Climatic pattern: Everything evolves

All components on your map are moving from left to right under the influence of supply and demand competition. This includes every activity (what we do), every practice (how we do something) and every mental model (how we make sense of it). This means that everything has a past and a future. For example, in figure 20, the component described as platform was considered to be a product and in 2005, for an online photo service, this was provided by the LAMP (Linux, Apache, MySQL and Perl) stack. There were other competing product sets out there with different features but few of us would entertain the idea of custom building the lot i.e. with an online photo service then you wouldn’t start by going “we need to build our own novel operating system, our own computing language and our own web server software”. However, roll the clock back further in time and that’s exactly what you would have needed to do.

Figure 20— Everything evolves

Figure 20— Everything evolves

Even with this product stack, there was still a lot of stitching required. We were far from the highly standardised world of electricity supply where you simply insert a plug and switch it on. We had installation, configuration, setup, networks and many underlying components that had to fit together to provide a working stack. I would have dearly loved to just walk into the office, metaphorically flip a switch and start coding on some form of utility platform but that wasn’t our world in mid 2005. However, platform was evolving and at some point in the future it would become more of a commodity, even a utility. In much the same way compute would at some point become a utility. This was a subject that we had discussed at Euro Foo in 2004 and within our own company we had already created a system known as the Borg which provided virtual machines on demand. It would only take a small leap from that to the compute utilities described by Douglas Parkhill in his 1966 book, The Challenge of the Computer Utility.

Climatic pattern: Characteristics change

Organisations consist of value chains that are comprised of components that are evolving from genesis to more of a commodity. It sounds fairly basic stuff but it has profound effects because that journey of evolution involves changing characteristics. For example, let us take the genesis of computer infrastructure and wind the clock back to 1943 and the Z3, the first digital computer. The activity was scarce, it was poorly understood and we were still in the process of discovering what a digital computer could do. The act was uncertain as we had little idea of what it could lead to and as such it was unpredictable and rapidly changing. But this activity had the potential to make a difference, it was a source of differential value and competitive advantage. There was however no firm market to speak of, any customers were on as much of a journey of exploration as the suppliers.

Computing infrastructure did turn out to be useful and it started to spread. Custom built systems such as LEO (Lyons Electronic Office) were built and eventually products released (such as the IBM 650) with diffusion of ever more functionally complete systems. By 2005, computing infrastructure was starting to become treated as a commodity with racks of fairly standardised servers. It was increasingly commonplace and its purpose and use was well understood by a large number of people. We were already starting to think less about what a digital computer could do and instead on what we could do with vast numbers of fairly standardised units. In our Borg system, we had even abstracted away the concept of the physical machine to virtual ones which we created and discarded with abandon.

This change of relationship was not unfamiliar to me as I ran an online photo service and could clearly see the same impacts happening with images. As the industry evolved from photo film to digital images then the behaviour of the user was slowly altering in front of us. In the past, every single photo taken was precious and it required some effort including a trip to a photo processing lab. Accidentally taking a shot with the camera lens cap on was met with sighs of disappointment due to the waste of film, the effort of trying to set up that good shot and the inevitable wasted print from the lab. However, the format had become a more digital commodity and so users increasingly took many shots and discarded unwanted ones regularly. The idea of taking and throwing away images with abandon was no longer waste but an expected consequence of taking thousands of them. Ditto virtual machines.

The use of computing infrastructure was also not seen as a differential between companies but instead more of a cost of doing business. Whilst in the very early days, you might have had a press announcement with a CEO that this or that company had bought their first computer, those days were long gone. Even the days where our system admins would take care in picking names for our servers, such as famous Sci-Fi characters or places was disappearing. These servers were no longer pets, they were becoming cattle.

The market itself was becoming more predictable; customer demands for large volumes of more economically efficient units. This single activity had evolved from rare to commonplace, from poorly understood to well defined, from competitive advantage to cost of doing business, from rapidly changing to standardised. Everything evolves from that more uncharted and unexplored space of being rare, constantly changing and poorly understood to eventually industrialised forms that are commonplace, standardised and a cost of doing business. What happened with computers and images had happened with electricity, the nut and bolt and Penicillin — the once marvel drug that became a generic. However, this assumes survival and though everything evolves not everything survives. Given a presumption of survival then the progression and change of characteristics is shown in figure 21 on which I’ve also marked the domains of the uncharted and the industrialised.

Figure 21 — Characteristics change

Figure 21 — Characteristics change

Since this change is common for all components then I was able to collect a list of characteristics in order to produce the cheat sheet previously shown in figure 17 (chapter 2). Now, you might argue that this is circular because I’m stating the extremes are different using a map which is built with a cheat sheet which assumes that the extremes are different. This is a perfectly reasonable challenge and one which requires me to explain how that evolution axis was created. That subject is an entire chapter of this book and if you wish you should skip ahead to read it (Finding a new purpose. Chapter 7 | by swardley | wardleymaps | Medium ). For the time being, it is enough to know that all your components evolve due to competition and as they do so their characteristics change from the uncharted to the industrialised. You cannot stop them evolving if there exists competition around them.