Subscribe: Bits or pieces?
Added By: Feedage Forager Feedage Grade A rated
Language: English
business  change  chapter  context specific  doctrine  figure  map  mapping  maps  people  product  strategy  system  time 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Bits or pieces?

Bits or pieces?

A node between the physical and digital. The rants and raves of Simon Wardley. Industry and technology mapper, business strategist, destroyer of undeserved value. "I like ducks, they're fowl but not through choice"

Updated: 2018-01-21T17:45:19.294+00:00


Better for Less


Chapter 18(a very rough draft)All change pleaseIn early 2009, I met Liam Maxwell. That name may not mean much to you unless you work in Government but he has been an influential figure in government technology throughout the world, a strong advocate of mapping and a good friend since that first encounter. We met when I was speaking at some random conference in London on evolution and technology. By happenstance Liam was in the audience. We got chatting and discovered we had common interests and ways of thinking about technology. I was soon invited to the “Triple Helix” group which consisted of a motley crew of interesting people – Jerry Fishenden, Mark Thompson and others. They wanted to try and help fix problems they saw in Government IT. It was a non-partisan group i.e. many of us came from different political backgrounds. For myself, I felt completely out of my depth. This was “big IT” as in huge projects with hundreds of millions spent on massive scale systems that I had usually only heard about because of some failure hitting the mainstream press. There were also big personalities. I met Francis Maude (he was in the opposition Cabinet at the time) which mainly consisted of me trying not to mumble “you’re Francis Maude” given I was a bit awestruck. What on earth was I, a state school kid who had lived on a council estate doing in the Houses of Parliament talking to people I’d seen on TV.I was also introduced to various departments who kindly offered to give me an hour or so explaining how “big IT” happened. What I saw shook me but then I hadn’t really seen “big IT” in the commercial world having mainly built companies or worked for moderate sized groups. The first, and most obvious thing, I noted was the lack of engineering skills despite the scale of these engineering projects. I would be introduced to engineer after engineer that in effect turned out to be a glorified project manager. The answer to everything seemed to be “outsource it”, a mantra that had been encouraged by hordes of management consultants. I tried to explain how this would inevitably lead to cost overruns because some components would be novel but usually got an answer blaming poor specification. It seemed that no matter how many times a project failed, the answer was “better specification” or “better outsourcing”. This was dogma run wild. I became increasingly aware that these groups were not only dependent upon the vendors but many lacked the skills necessary to challenge the quotations given. There was no concept of maps and no effective mechanism of communication, learning or sharing. Everything was isolated. Duplication was rife. Before anyone goes on about how bad Government is, let me be clear that this pales into insignificance compared to the inefficiencies and ineffectiveness of the private sector. I might have seen the same system rebuilt a hundred times in Government but in the commercial world, I’ve seen 350 separate teams of people rebuilding the same IT project in one organisation at the same time. Anything that the Government gets wrong, the private sector excels at showing how much more wrong is possible. Anyway, Government was still a shock. There were some weak measures of cost control but barely any concept of price per user or transaction or user needs or anything that I had started to take for granted. There was one project that Liam asked me to guess the price on, I responded around £300k after looking through the details. It was north of £50m. I had real trouble wrapping my head around such figures but then I’ve seen a billion dollars spent on no-hope, obviously doomed to fail from the beginning efforts in the private sector. I’d always assumed there was some greater wisdom that I wasn’t aware of. It was becoming clear that this wasn’t the case. In Government, however this tended to make me annoyed. I don’t mind survival of the least incompetent in the private sector because eventually someone will come along and do a better job. In Government, there is no[...]

To Infinity and Beyond


Chapter 17(very rough draft)Meeting a spacemanI was working on the use of printed electronics within a paper book (think of an interactive book which looks like a normal book) when I got that phone call from a friend about "this guy who really wants to meet you". I was curious, so I went along to meet someone called Mark at Canonical. I didn't know what to expect. The first few minutes were certainly interesting.Shuttleworth : "I'm Mark. I've been told you're a good UX designer."Me : "I don't know anything about design."... silence.It was an awkward pause. Then Mark realising the next hour was probably a waste of his time asked me to tell him what I did know about. I talked about evolution, the changes in the industry and before long we were into graphs, maps and cloud computing. The time flew by. We kept talking. I was introduced to others and in what seemed like lightning speed, I was working at Canonical. I had one job, to bring Ubuntu into the cloud. I called my friend, asked him what had happened. Steve just responded "I knew you'd get along".  Life is full of pleasant trouble makers like Steve.The first day I arrived for work, I was all excited and had the usual confused look of a rabbit staring at headlamps. My boss, who also happened to be another Steve, did the usual rounds of introductions. That was an interesting moment. Whilst I delighted in the warmth of the people I met, the first five responses to my role of bringing Ubuntu into the cloud were negative - it's a fad, why are we doing that etc. I knew I was going to have to build a cabal pretty quickly and create some momentum. However my first official task was to look at the virtualisation strategy that had been written. It was one of those "oh, what have I done" moments. Fortunately it didn't take long to find others with common interests - Rick Clark, Soren Hansen, Nick Barcet and many others. Steve George was one of the most supportive people I've worked for, a good friend and then there was Mark. Without Mark none of this would have happened. The problem to begin with was Canonical was focused on the server and desktop market. It was up against huge giants such as RedHat and Microsoft. It was making valiant, almost heroic efforts but Canonical was small. Many wanted to focus on the server OS, to generate revenue from support licenses and to a few then the Cloud was a distraction. The problem was one of focus and what I needed to do was change the mindset. To explain this issue and why it mattered I'm going to cover a number of concepts from the Three Horizons to Porter.The Three HorizonsThe three horizons was a model put forward in the Alchemy of Growth, 1999. It discussed three views that any corporation had to take.Horizon 1 : the core business which provides the greatest profits and cash flows that need to be extended and defended.Horizon 2 : are the emerging opportunities and businesses that will drive medium term growth. These may include new ventures that you are investing in which are expected to generate substantial future profits.Horizon 3 : These are ventures that should ensure the company long term future.  They can include research projects or pilot programs or even investment in startups.For Canonical, horizon one was the core support licensing revenue.  Horizon two included new concepts such as online storage, the app store and extending onto more devices. Horizon three ... well, I'm quite convinced a few would have thought that included myself. Whilst this model of three horizons is a reasonable way of examining a company, I personally find it inadequate. I often find that some confuse it with the pioneer - settler - town planner model of organisation by associating town planners with horizon one and pioneers with horizon three.  To explain the weakness with the model, I'm going to use the map of mapping that I introduced earlier. To save you scrambling back through past chapters, I've provided that map here in figure 213.Figure 213 - The Map of Mapping.Let us now assume that we decide[...]

Blue pill or red pill?


The strategy cycle is one of those simple mental devices which hides a world of complexity. On the surface, it's all about observing the environment (the landscape and climatic patterns which impact it), orientating around it (the doctrine or principles we might use), deciding where to attack (leadership) and then acting. It's a combination of OODA (Boyd) and Sun Tzu in a easy to understand cycle. Figure 1 - The strategy cycleHowever, dig beneath the surface and you start to discover layers of complexity.  To understand the landscape you need to map it and there as many maps as there are industrial landscapes. There's also not just one climatic pattern but many and these are useful in anticipation. There's not just one principle to follow but many patterns for doctrine that are universally useful for any organisation. There are also many forms of context specific gameplay which are used in scenario planning various plays. Finally you have the speed at which you loop around the cycle.  However, take one small area - doctrine - and the complexity expands.Figure 2 - ComponentsThere are least forty different forms of universally useful doctrine from focusing on user needs to a bias towards action to using appropriate methodology. Each of these in turn expands. For example managing inertia has 16 different types of inertia and different tactical plays for each.Figure 3 - DoctrineFigure 4 - Managing inertiaOf course, how you implement doctrine is also context specific. Thinking small as in team structure (e.g. Amazon two pizza or Haier's cell based teams) might be universally useful doctrine but the teams within Amazon will be different from the teams in Haier whether in size, composition or number.With practice much of this becomes second nature, you learn to map, you to learn where inertia will exist in the map and the types of inertia to change that you're likely to face. You learn how to constrain complex spaces by dividing large scale businesses into small contracts and small teams. You learn how to constrain maps themselves creating an atlas for an industry with each node representing an entire map itself. It also all blends together with gameplay and anticipation of change to become part of the craft. You learn how to exploit the inertia of others or to design an organisation to cope with constant evolution. But there are layers of subtlety and many unexplored areas.For example, I've long used doctrine as a way of examining competitors to determine how adaptable they are and hence what sort of gameplay I might use against them. I've provided two doctrine tables that have been completed by others - one for a US web giant that is tearing up industry after industry and one for a US investment bank. I'll let you decide who is who and where you fit between them and which you would prefer to face off against.Figure 5 - Doctrine table 1Figure 6 - Doctrine table 2The problem of course, is whilst the list of doctrine has been developed from mapping many industries and finding patterns that are universally useful, I cannot actually say which components of doctrine matter more. Is transparency more important than a bias to action or is using appropriate methods more important than a focus on user needs. Sorting this out will take decades of data collection and as organisations evolve we will find that more universally useful principles emerge. However, as a rough guide the doctrine table appears useful enough for the time being.Of course, without the priority order it becomes difficult to say which you should adopt first. Certainly some of these doctrine appeared significantly important in our Learning from Web 2.0 report published in 2012 but are they the most important? Also is there an order, are some dependent upon others?Using experience, I can make an educated guess about which should be implemented in what order (as a discrete set of phases) but it's only a guess. For example, I know that implementation of a pioneer - settler - town planner structure (a t[...]

Is my diagram a map?


Let us take a systems mapIt is visual and context specific (being a system diagram of an online photo service and not a self driving car). It has components and the relationship between components. We also have the flow of information (blue line) between components. But does this make it a map? I've shaded one box (CRM) in grey and moved it.The components and the relationship remain the same. It's still visual, it's still context specific specific and nothing alters with flow. The diagram is in essence identical but yet I've moved a box. Let us compare this with a road map of major roads in the UK.It's visual and it's context specific (being the UK not France). The diagram has components, relationships between them and also flow (e.g. the movement of traffic). But it has more than this. The compass acts as an anchor, the components have position relative to each other (London is North East of Southhampton) and we have a concept of movement. If I wanted to walk from London to Exeter (not travelling along the major road) then I could head South South West (roughy). The diagram is not very accurate, it lacks scale but is this a map? Let us move the component I've marked in grey (Nottingham).By moving the component I've fundamentally changed the meaning of the map. Nottingham is no longer North of London but SSW of London which of course, a quick flight across the territory will tell you is wrong. The map (and this diagram is a map) helps you explore the territory. It does so because it has the characteristics of navigation e.g. anchor, position and movement. Without such characteristics you cannot learn about the territory.Whilst the road map is a map, the systems map is in fact not a map. It lacks those navigational characteristics which enable us to learn about the territory. We might call it a map, in the same way I might call myself a Jedi but it's not the name but the characteristics that define what something is. I still lack the powers of the force no matter how many times I tell myself that I am a Jedi.A map must be visual and context specific. It must have components but more than this it requires an anchor, position and movement. The quickest way I know to determine if something is a map or not is to move a component (i.e. use movement) and see if this changes the meaning of what is being looked at. If it doesn't then it's not a map and hence it is of little use for learning about a space. Almost everything we call a map in business - systems maps, business process maps, mind maps, digital maps, product road maps, strategy maps - are not in fact maps. They are diagrams.  If you want to map a business then I've written the best part of a book (all creative commons) on how to actually do this.[...]

The book so far


Writing is not something I find comfortable. Lately I've been consumed with putting together a book on mapping. It's getting there. Slowly.Chapter 1 — On being lostAn introduction into the concept of situational awareness and the strategy cycle.Chapter 2 — Finding a pathHow I built my first map of business.Chapter 3 — Exploring the mapThe shock of discovering common economic patterns.Chapter 4 — DoctrineThe even bigger shock of discovering that some patterns are universal whilst others are context specific.Chapter 5 — The play and a decision to actUsing maps to make a choice including some basic strategic play such as ecosystem models.Chapter 6 — Getting started yourselfHow to start mapping and some useful books to read.Chapter 7—Finding a new purposeUsing mapping on itself and discovering a new purpose. The underlying work on evolution. Chapter 8—Keeping the wolves at bayThe dangers of simplicity and the concept of flow.Chapter 9 — Charting the futureThe use of weak signals and economic cycles.Chapter 10 — I wasn’t expecting that!The evolution of organisations and different forms of disruptionChapter 11 — A smorgasbord of the slightly usefulA collection of useful mapping topics that by pure coincidence might be needed for the following scenario.Chapter 12 — The scenarioSomething for you to get your teeth into.Chapter 13 — Something wicked this way comesAnalysis of that something from chapter 12.Chapter 14 — To thine own self be trueThe path you probably should have taken in chapter 12.Chapter 15 — On the practice of scenario planningOn scenario planning and the concept of roles. Diving a little more deeply into financial modelling.Chapter 16 — Super LooperA walk through of severals loops of the strategy cycle.I've around 4-5 more chapters to go and then this first pass, this introduction into mapping, should finally be finished. Except of course for the rewriting, editing, rejigging, frustration, burying in soft peat for 6 months in triplicate, tearing up, cursing etc etc.[...]

Round, round, get around, I loop around


Chapter 16(draft)The LFP example is based upon a real-world event. I say “based” because I usually take time to disguise the actual event to protect any guilty parties. In this case, the haphazard and stumbling CEO was ... me. The variations to the real world include it was I, not the client, that proposed this concept of worth based development and I put in the effort to build those numerous financial models. True to form however is I also fought plenty of internal battles over inertia to make this project happen. In this case, I’m going to use that LFP scenario to examine mapping in practice. I’m very wary that my long experience with mapping means that I tend to gloss over parts through assumption. In much the same way, I spent six years assuming everyone already knew how to map and it wasn’t until 2011 that I started to realise they didn’t. With that in mind, I’m going to go into excessive detail in the hope that I don’t miss anything useful to you. To keep it relevant and not just a history lesson, I’m going to go through the steps of how you would tackle the LFP scenario as if it was happening today.  To begin, I always start with the strategy cycle. To me, it doesn’t matter whether I’m looking at nation states, industry, corporates, systems or even individuals – the strategy cycle applies. For completeness, I have provided this cycle in figure 198.Figure 198 – the strategy cycleOur initial purpose for this LFP system is to help create leads for our client. That is what they need and it is also how we will be measured. We don’t have to agree to the proposal but if we choose to accept it then our focus must start here. Of course, we have our own needs – to survive, to make a profit, to have fun - which we could choose to map. In this case, I’ll elect not to.We know we also have a “why of movement” question in the scenario – do we build the entire system in-house or do we use elements of a public platform? Do we go here or there? Why? Before we can answer this, we need to understand the landscape a bit more. Fortunately, in the LFP scenario a map has been kindly provided by engineering along with the more common financial models. As tempting as it is to dive straight into the financials, start with the landscape. I do love a good spreadsheet, I’ve spent years of my life immersed in cashflows, GAAP, chart of accounts, options analysis, business models and all manner of delightful things. However, a word to the wise, put these to the back of your mind for the moment. The financials can often be skewed by a bias to the present. With the map provided, one immediate thing I’m going to note is that we have inertia against using the public platform space via both security and the systems group. I’m going to mark that onto the map in figure 199.Figure 199 – adding inertia.Now let us focus on that platform change, the shift from product to a more industrialised form which in this case means utility. As noted many times before we have a common economic pattern of co-evolution i.e. as an act evolves we often see a corresponding co-evolution of practice. Let us concentrate here, remove all the other bits of the map and add in co-evolution. I’ve done this in figure 200Figure 200 – co-evolutionBy applying that basic pattern to our map, we can anticipate that as the world shifts towards more utility like code execution platforms, some new-fangled practice (a sort of DevOps 2.0) will emerge. We don’t know what those practices will be as they emerge in the uncharted space. We don’t know when precisely this will occur. But we know that we will have inertia to this change. We also know that such changes tend to be rapid (another common economic pattern known as the punctuated equilibrium). We can also go a bit further. The nodes on the maps are stocks of capital with the lines representing flows of capital between them. With evolutio[...]

On the practice of scenario planning


Chapter 15(draft)One difficulty that people face with the Phoenix scenario outlined in the previous chapters is the question of role. It’s not unusual to look at the scenario and its corresponding plays such as “pig in a poke” and ask what happens to the people? A common retort is “leadership is all about people and the leader should sacrifice themselves for their people”. It's a noble idea.As difficult as it is, you have to remember that in the scenario you are an executive of the conglomerate and your focus is on maximising its advantage. The game is somewhat different if you’re the CEO of the subsidiary. That which brings maximum advantage for one perspective is not necessarily that which brings the maximum benefit for another. There are often many competing interest and many maxima in a single landscape. Whilst the game itself is rarely zero sum (i.e. I win, you lose or vice versa) as both can often benefit, your focus should be on maximising your advantage. It is almost inevitable that the pursuit of such will result in conflict whether it’s the shareholders desire for profit versus the consumers desire for lower product cost or some other trade off. When you examine a map, you need to go beyond just the landscape, the why of movement (i.e. this choice over that), the why of purpose (to be this or that) and to consider your role and that of others. There are many actors in a map and they have different perspective. Even the consumer's view of the landscape can be different from that of the producer. Mapping simply shows you a landscape, you have to apply thought, you have to balance conflicts and you have to strive for your maximum advantage. But isn’t this cold hearted? Yes, it can be dispassionate. But remember, you also have to lead and that requires trust from others. There is a cost associated with brutal corporate action and you have to balance another conflict, present action versus future. Become too Machiavellian, too brutal and too few will follow you. Seeking the path with least conflict, to win the war without fighting and to demonstrate how all can benefit is the pinnacle of the craft of war.Balancing these conflicts, focusing on your role, removing your own bias and understanding the different maxima that exist is one of the hardest challenges that I know for leadership. The practices of mapping are the trivial entry point into this world. The complexity of playing the game is vastly more than just seeing the board, knowing the rules and a few opening plays. I often suspect this is why we like story-telling, magic frameworks such as 2x2s and secrets of success - we paper over a complex world with simple to understand “truths” regardless of how incorrect they are. It makes management easier.To tease out the concept of role, I’m going to use a generalised scenario that has two variants – one which covers product to product substitution and the other which covers product to utility. I’ll use a single map to describe both and I’m going to focus on a pattern of change rather than user needs. You should be familiar enough with mapping by now that such shortcuts are permissible. The "generalised" scenarioYou are the founder / CEO of a company that produces a product. You’ve developed a successful business, you are proud of what you have accomplished and the team you have built.  In one variant, your product is being substituted by another product (A1 to A2) e.g. Blackberry vs Android. In the other variant your product is being substituted by a utility (A1 to A3) e.g. traditional hosting versus cloud computing. I’ve drawn these variants on a single map in figure 188.Figure 188 - a changing spaceIn any business relationship, there are more than just products involved. There is the practice of how the product is used, data about the product, data consumed by the product and even knowledge about the produc[...]

Google Next Trip Report


Been a bit quiet of late in terms of writing but then there has been a lot of travel and oodles of events. The most recent was Google Next 17 which I managed to catch on the 2nd day due to prior commitments teaching students.

From my perspective, the event was good and had some interesting announcements (Spanner, Kubo), strong sessions (Liam Maxwell on Open and Gov, Sam Ramji's fireside chat) along with solid demos e.g. Google Cloud Functions with Firebase. It was rare that a talk didn't hit the mark but there was at least one which wandered off into the usual corporate bingo without substance. Finally, the corridor chat was outstanding providing an opportunity to catch up with old friends. For reference, Google has put up a list of the announcements.

During the event it was noticeable that Google was leaning towards a more "enterprise" crowd, not something I had really noticed before. The rebellion will be corporatised! I was also somewhat disappointed that Google didn't push much further with Cloud Functions. Going into beta is good but I'd be hoping for much more noise on the keynote stage. For me, "standard" GAE and Cloud Functions are both operating in the right space. 

I understand all the excitement about kubernetes and I'm excited to see Google and Cloud Foundry getting close but you all know my view on containers - a useful but ultimately invisible subsystem. The real battle for platform is in the code execution layer and so I'd advise that no matter how tempting things might be that you spend your energy winning that space. It's important to understand that the stakes in this game are the entire future of software development and I'm not kidding when I say "Amazon is eating the software which is eating the world". The danger is people always think they have time but the war is won (in ecosystem battles) long before the market has been dominated.

Anyway, I enjoyed the event and congratulations to the organisers. I was also a guest of Google and thank you for making my life easy. On the subject of corporate bingo, I also had the opportunity to speak on mapping, ecosystems, serverless and way too much other stuff.

Crossing the river by feeling the stones.

allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="" frameborder="0" height="266" src="" width="320">

To thine own self be true


Chapter 14(draft)The hardest thing about mapping is coming to terms with a simple fact that there is no right answer. Mapping enables you to observe the environment, the constant flow of evolution and moves of other players but it won't tell you what to do. There are alas no simple steps for you to follow to success. There are no plans that guarantee to bring you a fortune. I face this obstacle regularly when companies ask "how will mapping benefit me" to which the answer "it depends upon what you observe and then what you do" is seldom welcome. They often want the concrete, the definite and a world of levers you can pull or buttons you can press. I long to say "By turning this mapping dial you will save 12% of costs" or "press the mapping button to increase your rates of successful innovation by 34%" but it just isn't true. The benefits are context specific and they depend upon you.The journey of mapping is one of abandoning the simple mechanistic world and embracing an iterative path of learning. Yes, there are patterns we can learn. Yes, there are universal principles we can apply. Yes, there exists context specific gameplay we can use. Despite this and in spite of our ability to observe the environment, it is still awash with uncertainty. The uncharted is uncertain, the timing of various patterns are uncertain and the actions of others are uncertain. Even the future value of something is inversely proportional to the certainty we have over it. The more uncertain, the more risky and also the more potential value. Evolution itself, the very heart of these Wardley maps, can't be measured over time and instead we have to measure over certainty. This use of uncertainty is an intrinsic part of learning to map but as any map shows, not everything is uncertain and even the uncertain can be exploited.Fortunately nature has provided us the ability to cope with this, to be resilient to and learn from a constantly changing world. This ability is known as cognitive reasoning or in layman's terms the application of thought. We can use the patterns and our understanding of the landscape to try and create a more favourable result. Sometimes we will get this right but more importantly, sometimes we will get this wrong. Every failed attempt is an opportunity to learn, assuming we use a systematic method of learning. Every mistake learned can be taught to others, assuming we use a common method of communication. There is a lot of future value in error. By learning these patterns, it helps us constrain the bewildering number of possible moves to the adjacent probable. Hence we can say that the industrialisation of artificial intelligence to commodity components and utility services will enable a rapid growth of new things built on top of them. We just can't say what those new things will be but we can prepare for it.Sometimes the lessons learned from mapping are nothing more than "Ere be dragons" such as the uncharted space will contain highly risky and uncertain sources of future value that require us to experiment, discover and gamble. Other times they are more concrete such as the the shift from product to utility will result in co-evolution of practice. Embracing this spectrum from the uncertain to the certain, from the unknown to the known, from the uncharted to the industrialised is for many the most uncomfortable bit of the journey.So to the exercise at hand. I will explain with maps my reasoning to the choices that I would make in this scenario. My reasoning is not the "right" answer but instead it is simply "my" answer. It maybe the case that you read this and say "I wish I'd thought of that" or maybe you have a better answer in which case I'd be delighted to learn from you. Challenge, communication, learning and embracing uncertainty are the very core of mapping. My playBack in 2008, when I was faced with t[...]

In this case, resistance is futile


I'm not going to go through how the DNC lost the election other than to say the DNC farce has just turned up the dial to 11.Trump used confusion to excellent effect in the campaign. I don't like a large amount of the things he says but I won't dismiss his skill, he has shown himself to be very capable. He didn't so much win the election as not do as much damage to himself as his opponents did to themselves. But during the election he made some big promises, the biggest of all and the one that is his signature is "Make America Great Again". The problem for Trump is that isn't solely his choice. Greatness is always relative and he has significant and skilled opposition in China on this front. Fortunately for him, there's a get out clause - the Democrats.In the first few days, as Trump promised, there has been a flurry of executive orders. Some are interesting from the point of competition (e.g. removing TPP), others are damaging (ACA) whilst more still are downright unpleasant - the enhanced Mexico City Policy, enhanced interrogation et al. Amongst this is a bit of the showman such as building the wall. However, Trump is successfully reinforcing his image as a man of action and at the same time he is inviting the Democrats to resist, to protest and to try and prevent the changes. He's not quite saying "Democrats, resist me!" but it's pretty close. Why? Because he will need a fall guy, someone to point to and say "I was ready, I did what I said and what the American people asked, I was their leader and their man of action BUT these people [point, point] stopped me from making America Great Again". It's a terrible trap. If the DNC don't resist then people will blame the DNC for not doing enough to stop Trump if it goes bad. If they do resist then Trump (and his supporters) will blame the DNC for resisting if it goes bad. If things go well then Trump will claim he was right regardless of whether the DNC resisted or not. What they should be doing is tearing him down on that one signature promise that he made. This means, the best route (baring the ability for workers to hold a general strike which seems highly unlikely) for the DNC is to stand firm, not obstruct him but to hold him to account. He wants a wall, build the wall. He wants a freeze in hiring, then let the freeze happen. The question the DNC need to be constantly asking him is "When is America going to be great again? That was your promise."You need to expose him on that question of leadership and what he stands for. Oh, but we can't support his awful actions! Well, some of them are unpleasant, some are worse and many might get you angry. I'd imagine they're even meant to do this, to get some people to react and to resist. By all means challenge them, question their legality, expose them, use the courts but don't just resist Trump by trying to use political process to thwart him. You'll fall into the trap. You need to bang that drum on "When is America going to be great again?" and hold this representative to account on his promise.Before you say - I didn't vote for him - whether you like it or not, he is the democratically elected president of the US. Again, that might make you angry but those who have the right to vote need to use democracy and the will of the people to their advantage. That means bringing lots of other people to your side. Remember, he did win which means he has lots of supporters. By all means, make your feelings clear, show support to any victims but try and encourage his supporters to join you which means listening to their concerns. Give in to your anger, run around calling them "Nazis" and celebrate people punching them is a surefire way to lose. Don't let them use your resistance against you, as a way of maintaining power. Gather your support. As uncomfortable as this might sound to m[...]

By the pricking of my thumbs


Chapter 13[draft, more upto date version kept on medium]It maybe unlucky for some but I'm going to start this chapter by announcing that I'm not going to give you an answer to the scenario - yet. Instead, I'm going to give you some analysis just in case you're needing a bit of help. If you're some wizard that has already worked through the scenario, determined the right strategy and have a solution then that's fine, you can skip unlucky 13 and head straight into the next chapter. This is more for the rest of us mere mortals, who like me, have found themselves totally lost when faced with problems such as the scenario. I'm not going to use any additional information other than that already provided - in other words, there's no mystery character inserted in the last paragraph that committed the crime, see all those loathsome detective novels that make you go "where did that come from?"I'm also going to explain this analysis in quite some detail. I apologise in advance if this is tedious but I've spent a lifetime reading mathematics texts which go - "it is therefore obvious that" - only to continuously discover that it's not obvious to me. I am going to start by creating a map of the environment and use it with some of those basic climatic patterns. I'm also going to add in a bit about market position, that'll become clear as we go through. Remember maps are just a communication tool and so feel free to annotate and adapt them as you need. From this basic map, we're going to examine the state of the company and its proposed strategy. We're finally going to use time-turner magic (for all you Harry Potter fans out there) to wind the clock back in time and give you a chance to choose your order again and decide once more what you want  to say to the executive board.A map of the scenarioTo start with, we need to create a basic map. The company unfortunately doesn't talk a great deal about user needs but we can infer that the user need is either about saving money or being green (possibly even a legal requirement). This need requires some form of efficiency analysis which is provided by the company as a product - Phoenix.  We also know the market whilst reasonably sized (£301 million) is seen to be far smaller than the applicable market (£3 billion) and so the market of clients is not yet fully mature. Hence to begin with, I'm just going to add client which needs efficiency analysis to our map and position the pieces roughly where I think they should be (see figure 167).Figure 167 - starting the mapI also know that Phoenix requires some form of sensor and this sensor seems to be a highly expensive product. The clue that this isn't some form of resource constraint is that a more commodity version is provided in China. I also know that the sensor (or at least the system using the sensor) requires some form of custom built data set which our own in-house IT team creates. I'm not quite sure how this operates but for the time being I'll attach this as a need for the sensor.  Finally, I'm aware that Phoenix has some form of system logic based upon best practice use of the sensors. I know that changing the sensor to multiple commodity sensors would "require a complete rewrite of Phoenix" (the CDO told us this). So, I can now extend my map with these components (figure 168). It's not perfect, no map ever is. I've marked on the sensor logic as a practice (i.e. it seems to be connected with how we use sensors) and the environmental data as data.Figure 168 - extending the map with practice and dataThe head of marketing also told us that the US was a more mature market and Brazil was less developed in the area of such efficiency analysis software. I'll assume that the markets are competitive (i.e. there is supply and demand competition) particul[...]

The Scenario


Chapter 12[rough draft, more upto date version on Medium]Who are you?You are :-a member of the executive board of a huge conglomerate focused on facilities management.attending a meeting of one your wholly owned subsidiary companies with their executives.on a fact finding mission, trying to determine what the future of this subsidiary is. There has been some recent positive noise about the subsidiary from analysts and also some interest by third parties in potential acquisition. This company offers a single product which is a software system that monitors a data centre's consumption of power in order to determine whether it is being used effectively. The product is known as Phoenix.The CompanyThe CEO introduces the company and their vision to provide customers with the best tool in the market for reducing power consumption and improving environmental performance. The CEO talks about their mission to "help reduce IT's impact on the planet" and there is noticeably a great sense of pride and self belief within the group. The CEO reiterates their core values in a presentation. The values are described as being instrumental to the company's success and they include responsibility, integrity, transparency, compassion, empathy, adaptiveness and decisiveness. The CEO then provides some background information, more for your benefit than anyone else's.What is PhoenixThe system involves a proprietary software package which performs analytics across data gathered from a sensor that is installed within a customer's data centre.  The sensor is a highly expensive piece of kit that is manufactured by third parties. The sensor monitors both the electricity input, the temperature and airflow within the building.The analytics software is based upon a decade of best practice experience for the use of these sensors. The algorithms contained within the software package are considered to be the essential core IP of the subsidiary and they differentiate this product from everything else on the market. These algorithms are a carefully guarded secret. The software package also consumes a set of environmental data (which is provided by the company) that contains performance information on common hardware.Operation of PhoenixThe setup on a client site requires:-installation of the sensorsetting up a highly redundant server which contains the software packageinstalling agents on each machine in the data centre to provide performance information to the analytics tool over the networkdescribing the initial layout of the data centre to the analytics tool allowing the system to run for several days to collect data The system contains a learning AI which over time develops recommendations for improving the efficiency of power use from air conditioning, air flow, positioning of equipment, type of equipment and modes of operation. It has been shown to consistently reduce 10% of energy consumption within client sites with constant active monitoring. The process of setting up a new client involves a two day installation of equipment and software on premise. The service is charged for on an initial hardware and setup cost followed by a two year renewable software license. You note that the group is clearly proud of its accomplishments, the technological marvel they have created and their ability to deliver against their vision. Next up to speak is the head of marketing.Marketing & Business DevelopmentThe name Phoenix inspires the ideas of regrowth, of nature and of power and this is heavily used in branding and marketing materials. The company is the largest vendor of such energy efficiency systems in Europe providing a complete service from on premise software package to sensor install. Your systems currently account for 43% of the 2016 ma[...]

A smorgasbord of the slightly useful


Chapter 11[early draft version, more upto date version with corrections is kept on medium, still working on this, it will change]"Here's one I made earlier" is the staple diet of TV programmes when faced with the possibility that something might go wrong. Demonstrations are always a risky business. In the case of this book, doubly so. I want to let you loose on a scenario but alas I'm not even there to correct things if it all goes pear shaped. To manipulate the odds slightly in my favour of a beneficial result then before we get to the scenario (chapters 12 and 13), I'm going to cover some aspects of mapping in a little more detail. This is somewhat naughty because these ideas being fresh in your mind are likely to create a bias which is exactly what I'm hoping for. I'm signposting the answer before we've even got there. It's the closest I could get to "Here's one I made earlier" without writing down the answer first and then doing the scenario.However, to make this still relevant and challenging then I've hidden these clues throughout this chapter and interspersed lots of useful but not directly relevant concepts in a smorgasbord of the slightly useful. The concepts we will examine are on the opportunity of change, the trouble with contracts, common lies we tell ourselves and how to master strategy.Opportunity of changeActivities, practices, data and knowledge all evolve and co-evolve in a process which is not always smooth or continuous. In chapter 10, we covered the peace, war and wonder cycle and how previous giants in a peaceful product phase of competition can be overtaken by new entrants in the "war". Those new entrants are likely to settle down to become the titans of that industry. The most interesting aspect of this change is in the change over (point 1 in figure 133) between the two states. Whilst the act itself (e.g. computing) is well understood, this transition causes a great deal of confusion because the nature of the act is changing - we're moving from a world of constantly improving products with feature differentiation to a world of volume operations of good enough. This change is compounded by co-evolved practices, inertia to change, the speed of change due to a punctuated equilibrium and vested interests usually spreading all manner of fear, uncertainty and doubt.Figure 133 - A time of changeBehind the confusion, what is fundamentally occurring is the rise of new standards, the de facto optimisation of a market and a shift towards commodity. This doesn't mean that alternatives aren't available, we often have a battle over standards e.g. AC vs DC in the "electricity wars" or VHS vs Betamax for video recording standards. It's however marketplace adoption and network effects that will choose the winner and consign others to the niche of history. It's important to understand that in the early stages then everything is up for grabs.Alternatives in Cloud ComputingWhen Amazon launched EC2 (its utility compute environment) in 2006, I made a number of calls to executives in traditional hardware companies and offered to help them set up a competing service using our Borg technology - a technology suite that we had be used to provide on demand virtual machines within my company based upon Xen. I was confident we could emulate the APIs of Amazon and though we were behind the game in some areas, we were ahead in others. Overwhelmingly there was no interest and the couple (i.e. two) meetings I had with traditional vendors always ended up with the same result - "how will this help us sell more servers?"I'd like to say that by 2008 the attitude had changed but it hadn't. In late 2008, in the first of many such trips, I flew to the US, met a number of executives, told them their entire hardware [...]

A set of principles does not make a strategy


I often find World of Warcraft a useful vehicle for explain basic concepts of strategy. In this example, I want you to imagine two teams preparing to fight for the first time in a battleground - Warsong Gulch. Both teams have a short time to prepare before the game of capture the flag. Neither have been to Warsong Gulch before or have experience of fighting battlegrounds.One team (the Alliance) outlines its strategy for how it's going to win the battle. It consists of what they describe as five "universal" principles that they've all agreed upon.1) We're going to capture the flag and win the game! We're not going to just fight the opponents.2) We're going to do this with great people! We're going to be the best fighters (tanks, good for taking damage), mages (damage dealers) and healers. We won't just let anyone be in the team.3) We're going to be prepared to take risks and fail fast! We're not going to just play it safe.4) We believe in a supportive culture! We're going to help each other when asked.5) We're open to challenge and asking the hard questions. The team is enthusiastic and ready to go. Facing off against them is a team of Horde players. They've also spent their time preparing but the result is somewhat different. Focus : capture the flag and win the gameDoctrine (i.e. universal principles) : 1) Develop mastery (perform your role the best you can) - tanks take the hits, mages dish it out, healers heal.2) Act as a cell (unit) e.g. use concentrated fire, work and move together.Strategy (context specific play) :1) To begin with team will act as one cell in an initial all out attack. Group will quickly move through central tunnel towards enemy base, taking out opposing players that interfere. Always take out opposing healers first, then damage dealers and then tanks.2) Once their flag is captured by our tank, cell will work to take out opposing players and camp in their gaveyard (as per map) killing off opposing players as they are resurrected and before they create any form of group. Taunting opposing players is encouraged.3) Once graveyard is contained, cell will split into two smaller cells. An offensive group consisting of a few mages to take out opposing stragglers and the remaining group (including flag carrier) to camp graveyard. Once opposing players are contained in graveyard the cell will reform and a solo mage will keep running the flag. If the plan fails then the group will reform around our flag carrier.Now, the later has focus, principles and some form of strategy. It might not work but then the Horde players have the possibility to learn. I can almost guarantee that when the battle kicks off, the first question from the Alliance players will be "Should we attack or defend?" and "Where do we need to go?" Arguments will then happen and before they know it the Horde will be upon them. The next cries you'll hear will be "Help!" and "Why is no-one helping me, I need help here!" followed by endless bickering that this or that player isn't good enough to be part of the team and lots of shouts for "what is going on?" or "where is everyone?" or "should I grab their flag?". With luck, the Alliance team will be quickly broken.The point I want to emphasise is that principles are fine and yes strategy has to adapt to the game but don't confuse the two. A set of principles does not make a strategy. Though it's certainly better to have a set of principles than to have no principles and no strategy.This is equally applicable in business.[...]

I wasn't expecting that


Chapter 10I was in a quandary. Having described the three states of war, wonder and peace then I found myself in the unusual position of finding them everywhere. All activities seemed to show these three competitive states. However, I had no real way of testing the existence of these stages and my ability to perceive them might be caused by some sort of bias? It's bit like owning a Mini Cooper, once you have one then you suddenly notice how many other cars are Mini Coopers. I started to scout around for some means of testing these concepts. Did the states really exist? How could I test them? Do they just effect individual activities in industries or could they have a wider effect? At the very least I had a set of predictions (from weak signals) for when a range of activities would start to industrialise and so I could just wait. Of course, this could just mean the weak signals were wrong or I was just lucky? There was also something strangely familiar about those three stages. I'm a geneticist by training, I hold a second masters in environmental management and I also have a background in economics, courtesy of a mother who as an economist ignited my interest in the subject. I knew I'd seen these three states elsewhere. It didn't take me long to re-discover that first example - C.S. Holling's Adaptive Renewal cycle. The adaptive cycle describes the dynamics of a complex ecosystems in response to change. We start with the creation of some form of disturbance  - the genesis of a new act, some form of wonder. This is followed by a rapid stage of exploitation and accumulation in a stage of conservation where the change has become more stabilised in the ecosystem - the equivalent to a time of products, a peaceful state of competition. Eventually, the change has been normalised which releases energy enabling re-organisation and the genesis of new acts and new disruptions - the time of war. The Holling's cycle is measured over the potential of the system for change and the connectedness of the system. Whilst not an exact corollary, I've overlaid an approximation of the peace, war and wonder cycle onto the Holling's cycle in figure 112.Figure 112 - Adaptive renewal cycleThe importance for me of this was it gave rise to a number of concepts. First, when considering economic systems we would have to look at them as we do with biological systems and consider how an ecosystem reacts to a change and how competition will drive that change throughout the system. Secondly, the size of the ecosystem impacted should reflect the connectedness of the system that is changing i.e. industrialisation of legal will writing would only impact the legal industry whereas industrialisation of computing should have a much broader macro-economic effect. Lastly, there may well be an element of re-organisation involved. I was already aware of co-evolution but maybe this enabled broader organisational change?With this in mind, I started to explore macro economic scale effects on an assumption that a suitably connected technology should not only have micro economic impacts to its industry but wider impacts. I was aware that the economy exhibited cycles known as Kondratiev waves (thanks to my interest in economics) and the largest waves we described as Ages.  The first thing I noted was that these ages were not initiated by the genesis of some new activity but always by the industrialisation of a pre-existing activity that enabled higher order systems to develop. For example, the Age of Electricity was not caused by the introduction of electrical power which occurred with the Parthian Battery (sometime before 400 AD) but instead utility provision of A/C electric[...]



Chapter 9[The more upto date version is kept on Medium]My map of mapping that I produced in chapter 8 has multiple flows within it. My focus was on teaching people how to map and the flow from my purpose to my scope to the user and their desire to learn mapping and my desire to survive financially (see figure 94).figure 94 - flows within maps.The flaw in the above is it assumes that there is a market of users who have an inherent desire to learn mapping. Not only did I find this to be quite unlikely, it just wasn't the case. What people were aiming for is some way to create an advantage over others. Mapping was just a tool to achieve this.If you look at the component for "advantage over competitors" then I've identified three areas of interest - the learning of context specific play (i.e. outsmarting others), the application of doctrine (i.e. being more effectively organised than others) and anticipation of change (i.e. seeing change before others).  Maybe you can think of more, if you do then by all means update the map and share. I've highlighted the flow through these components in figure 95.figure 95 - three aspects of advantageNaturally, the entire map is evolving and so the benefit of doctrine will decline as more companies adopt them. Fortunately we have that pipeline of context specific gameplay and lots more discovery. In this chapter however, we're going to turn our attention to anticipation. Back in early 2008, I had become quite a dab hand at using maps and common economic patterns to anticipate change. I was regularly invited to speak at huge events and published articles where I would declare with sleight of hand that over the next decade we would see :-Rapid increases in the rate at of innovation on the web.New entrants dominating ITHigh rates of disruption in the IT marketsRadical changes in IT practices.Higher levels of efficiency within IT.Widespread adoption of cloud services.Increasing organisational strain especially focused on IT creating a necessity for organisational change.In 2016 we can see that this is happening but back in 2008 I was often greeted with a few gasps of wonder and a cacophony of derision and dismissal that things would change. I think I've been tagged with every label from "idiot" to "rubbish" to "gibberish" to "unrealistic". The most vociferous came from the world's of established vendors, enterprises, analysts and strategy consultants who had oodles of inertia to such changes. Fortunately, the gasps of wonder were enough to pick up some advisory work and keep booking a few gigs.  I need to be clear. I don't claim to have mystical powers of anticipation, a time machine, some great intellect or a crystal ball. In fact, I'm a lousy prognosticator and a very normal sort of person. What I'm good at is taking pre-existing patterns that are in the wild and repeating them back to everyone. It's more of the "I predict that the ball you've thrown in the air will fall to the ground" or the "I predict the army currently walking off the cliff will lose the battle" kind. A basic understanding of the landscape can be used to remarkable effect with an audience of executives that lacks this. To begin our journey into anticipation we're going to have to start with areas of predictability.Not all parts of the map are equally predictable.Every component that inhabits the uncharted space is uncertain by definition. As it evolves then our understanding and certainty about it grows until it becomes familiar. At the same time it becomes more widespread in its ubiquitous market and therefore any differential value it creates declines. When we talk about the uncharted space, we're discussing[...]

Building a business from a great idea, some future Monday


[Rough draft - the more upto date version is on medium]It's Monday, it's the year 2025 and I've woken up with a great new idea. [Actually, it's a pretty lousy idea but hey, I just spent five minutes on the scenario so let's just assume it's great.]I'm going to create a recommendation engine for stock picking based upon the mood of the internet. I quickly scribble down the user needs "make profitable trades" and "know what to buy" and write a basic map whilst grabbing breakfast. I have my map, I know the basic components that I need - the recommendation engine, trade feed etc. I start work at 8.30 am.I know Amazon provides one of the components as a service (the lambda platform) and several others can be found as AWS lambda services in the marketplace. The company I work for also provides a stock portfolio service. I mark up what I think we can use and what we need to build - the recommendation engine and the mood system.It's 9.20 am, I send the map of to our spend control group. They act like an intelligence gathering organisation, collecting all the maps of everyone, comparing them and giving some feedback. They build profile diagram by finding common elements between the maps.I get a reply by 10 am with some details. They send me the profile diagram below. It seems some other team in the company has built a recommendation product. I'm the only person thinking about a mood system. In general, I'm roughly where everyone else, However, 16 different teams are using trade feeds and everyone else is using some well developed lambda service and apparently everyone else is using some utility service for a trading engine. I check click the details, it's Amazon.They've also sent my map back, slightly modified. Ok, well at least this is not the like the bad old days of 2015 where my company had thousands of duplicated systems and endless rebuilding of stuff that already existed.It's 10.15 am. I start thinking about some metrics. The trade feed system is going to be providing trades to the recommendation system. Each one will need a call to the mood system, the risk system and so on. I start marking out where all the metrics are.It's 10.45am. I flip a switch and the map is converted into a business model. The same components, the same links, the same metrics. I start running a few scenarios, checking that I've made a truly variable cost business model. It's 11.30 am, I send the map and the model to finance. They come back with some helpful comments [in this case, it would be ... and how do we make money? but then again the scenario took me five minutes].It's 12.00 am. I send the maps and the improved model to the executive group. 15 minutes later I get the go ahead and a small budget of $20k.  I know from the spend control profile that some other cells are already building this stuff. I give them a call, tell them what I'm upto.  They already know, spend control told them.I know from the spend control profile that there is a group building a recommendation engine. I send them the map and model and outline my idea of adding a mood system to recommendation. We have a quick call and they're up for it. We agree a metric of value for charging - everyone uses worth based development these days. Most of the stuff is already built and provided as services. I just need a cell of pioneers to build the mood system, whatever that will be.I update my map with the organisation structure and load it with the build map and financial model to the company's job portal. I wait. Our company operates in cells, using pioneers, settlers and town planners. We live in a constantly changing environment. Watch the[...]

The curious thing about Article 50


I'm well aware that legal English is slightly different to common use but Article 50 has something very curious within it and I'd be very grateful if someone with solid international law experience could help clear this up.The problem ...Article 50Under s1, we have the right to withdraw. That's all very dandy. The process of withdraw is set out in s2 to s5 assuming we "notify" of our intention to withdraw. But here's the rub. The articles says "shall notify" and "shall" can be interpreted in many ways e.g. must, will or may.So in May 2017, what happens if we interpret it as "may". In which case we could just leave, on the day, stop any funding and that would be it. Now given UK is a huge contributor to the EU that's going to kick up a bit of a fuss but then it's our choice us if we wish to go through article s2 to s5 as under this interpretation they are optional. It's for us to decide what is in our best interest.Of course, some will say that "shall" means "must". Ok, so let us assume we decide to interpret it as "may" and the EU decides to take us to court and the court conclude that "shall" means "must". Well, then we turn to s2. Under this section we now "must notify" and we have a legal obligation to do so. However, look a bit further along and using the same interpretation then you'll find "the Union must negotiate and conclude an agreement with that state". Hang on, the Union has a legal obligation to conclude an agreement? That's a bit one sided isn't it? We could just sit there say "non" to everything until they give the UK everything it wants (have your cake and eat it!)It seems there's no obligation on the state, there's also no obligation for the state to agree to any extension but there's every obligation on the Union to conclude an agreement or be in breach. To which someone would say "well, you just let two years lapse". That still doesn't get rid of the obligation on the Union to conclude an agreement.To which someone could point out there's no timeframe. There's no timeframe for notify either. We could leave and notify in say a thousand years time.  It feels to me like article 50 was written on the back of a bus in a bit of a rush.However the problem is if the UK decides to interpret "shall" as "may" and leaves in March 17, cuts funding to the EU (and the UK is one of the largest contributors in terms of the delta between what is paid and what is received back) and seeks trade arrangements then in order to force an interpretation of "must" the EU has to accept a legal obligation to conclude an agreement. This seems like a sticky wicket for the EU whichever way it goes.Maybe some kindly passing international lawyer can clear this up.[...]

Amazon is eating the software (which is eating the world)


Continuing from my post on the fuss about serverless, I thought I'd riff off Marc Andreessen's famous statement and explain one possible future scenario where all your software belongs to Amazon. There are counter plays to what I'm going to discuss but these would make the post too long and being honest, I'm quite content to watch the executives of software giants flap around like headless chickens whilst their industry disappears. It won't happen overnight, this process will take about 10-15 years but by the time people realise it's happening (if it does) then it's too late. It's a type of economic change known as punctuated equilibrium but ... that's getting too technical, let us keep it simple.I'm going to use a map to explain what is going to happen. I've quickly cooked one up for a trading system, based upon nothing much at all. It's however a starting point. Now, I'm going to assume we're going to build this trading system in AWS Lambda which means all the software components of the map (trading engine, stock portfolio, risk system, recommendation engine and mood system) are built from functions (which may call many other functions) in Lambda. For why you might want to think about doing this, go read the post on the fuss about serverless.Ok, our customer in the above map has a desire to make profitable trades (I told you I cooked it up in five minutes and of course, you can make a better map). Making profitable trades requires us to be able to trade and to know what trades are going to be profitable (you wish!)Now, the secret to our success, the system which differentiates us from everyone else is our recommendation engine. It takes a feed of trades, and uses a magical mood system to determine what's worthwhile and profiles this with our risk system. Before you go "mood system, sounds like gibberish" then let me remind you - this is an example.In any case, back in 2005 when we had Zimki (the earliest serverless, functional billing environment), I did actually build a mood system in a day or so. It scrapped information from flickr and other sources to generate a mood for the world. It was daft, part of an evil plan I had that involved an animatronic monkey and concept art  .... let's not go there.So, we've got our hypothetical trading system to which I've also added some metrics. I'm now going to turn this map into a flow and add the metrics. From below, the trade feed creates the list of trades and is governed by the number (#) of trades. The trade feed is a Lambda function and so there is a cost to it.  Each trade is run through the risk, mood and finally recommendation system - each creating their own functional costs. The recommendation system provides a list of recommended trades (#recommended) which impacts the trading engine and the stock portfolio system.Yes, this is a very basic setup. You can argue with the map / flow diagram as much as you wish. Certainly in most banks then almost every component is treated as something relatively novel as if no other bank manages risks, trading, makes recommendations etc. In fact, from experience they usually have huge numbers of custom built systems all doing the same thing i.e. a single bank can often have a few hundred custom built risk management systems. But let us pretend we're working for some relatively sane bank.You can see from the above we have a cost for each of the systems such as trade feed = #trades x average cost of the trade feed lambda function. Most banks have no idea what individual functions within their organisation cost, they have no clear way to calculate[...]

The map is not the territory


As the saying goes all models are wrong, some are merely useful. A map is simply an imperfect representation of the territory. This is actually essential for usefulness. A perfect map of France would be a 1:1 scale map at which point it is the size of France and in effect useless. All maps are approximations.There are a number of discrete characteristics that are essential to any map. These are1) visual. It’s not a verbal story.2) context specific. It is a map of specific landscape, it’s not a general map that applies to everything i.e. France is not the same as Spain.3) position. You can see the position of relevant components (or features) on the map. This requires two things:- first, that you have components. Second, you have some form of anchor. Position is relative to something else and in the case of a geographical map then the anchor is the compass i.e. this hill (a component) is north of that feature. In the case of a game like Chess then the anchor is the chess board itself and a piece (a component) could be at position C1 or A2 etc.4) movement. With a map you can see where components are moving (assuming they are capable of moving) and where they could move to i.e. the constraint of possibilities. Hence, I can see my infantry troops moving across the map and understand the barriers which force them to change direction i.e. troops walking off a cliff is not a good idea.In business, you can use a Wardley map (these are provided as creative commons) to describe the landscape. It’s visual, it is context specific (i.e. this business or that industry), it has position of components (on a value chain) relative to an anchor (the user need) and lastly you can see movement. I’ve provided an example below. It also has some advanced mapping characteristics e.g. flow, type and climatic patterns.A mapNow, most companies use “maps” that aren’t maps i.e. they lack one of the basic characteristics e.g. business process maps, value stream maps, customer journey maps, mind maps … there’s a long list of things called maps which really aren’t. This doesn't mean they are not useful, they are except from the point of effective learning about the territory. These characteristics of a map are essential to learning whether it’s the rules of the game (climatic patterns), doctrine (universally useful approaches) or context specific gameplay. But what if my map is wrong! First, all maps are wrong, they are all approximations. What you mean to say is "What if my map is badly wrong?" Well, a map that is badly wrong can be quite dangerous. There’s a long history here of dangerous maps and poor situational awareness, books like Topographical Intelligence in the American Civil War are a worthy read. But there’s also plenty of examples of armies charging into a battle with no map and no understanding of the territory and the disastrous results that ensue - Ball’s Bluff, Little Big Horn.The difference here is that even a wrong map provides you with an opportunity to learn. Without maps, you can never learn the territory, the rules of the game, what context specific play works and what is universal. You can’t even effectively communicate with others over the territory.It’s true that maps are not the territory but if I’m going to lead a significant force against an opponent then I’d rather have a map of what we do know about the territory (even if parts of it says “here be dragons” or “we don’t know what’s in this bit”) than to charge in blindly as if everything is unknown.&nbs[...]

Why the fuss about serverless?


[The more edited version I've posted to Medium]To explain this, I’m going to have to recap on some old work with a particular focus on co-evolution. Co-evolutionLet us take a hike back through time to the 80s/90s. Back in those days, computers were very much a product and the applications we built used architectural practices that were based upon the characteristics of a product, in particular mean time to recovery (MTTR)When a computer failed, we had to replace or fix it and this would take time. The MTTR was high and architectural practices had emerged to cope with this. We built machines using N+1 (i.e. redundant components such as multiple power supplies). We ran disaster recovery tests to try and ensure our resilience worked. We cared a lot about capacity planning and scaling of single machines (scale up). We cared an awful lot about things that could introduce errors and we had change control procedures designed to prevent this. We usually built test environments to try things out before we were tempted to alter the all important production environment.But these practices didn’t just magically appear overnight, they evolved through trial and error. They started as novel practices, then more dominant but divergent forms emerged until we finally started to get some form of consensus. The techniques converged and good practice was born.  Ultimately these were refined and best architectural practice developed. In such confident days, you'd be mocked for not having done proper capacity planning as this was an expected norm.Our applications needed architectural practices that were based upon (needed) compute which was provided as a product. The architectural norms that became “best practice” were N+1, scale up, disaster recovery, change control and testing environments and these were ultimately derived from the high MTTR of a product. I’ve shown this evolution of practice in the map below. Normally with maps I just use the description of evolution for activities, it's exactly the same with practice but with slightly different terms e.g. novel, emerging, good and best rather than genesis, custom, product and commodity.Map - Evolution of Architectural PracticeThe thing is, compute evolved. As an activity then compute had started back in the 1940s in that uncharted space (the genesis of the act) where everything is uncertain. We then had custom built examples (divergent forms) and then products (convergence around certain characteristics with some differentiation between them). However, compute by the early 2000s had started to transform and become more commodity like with differentiation becoming far more constrained, the activity itself becoming far more defined. In this world a server was really about processor speed, memory, hard disk size, power consumption and how many you could cram in a rack. In this world we built banks of compute and created virtual machines as we needed them. Then we got public utility forms with the arrival of AWS EC2 in 2006.The more industrialised forms of any activity have different characteristics to early evolving versions. With computing infrastructure then utility forms had similar processing, memory and storage capabilities but they had very low MTTR. When a virtual server went bang, we didn’t bother to try and fix it, we didn’t order another, we just called an API and within minutes or seconds we had a new one. Long gone were the days that we lovingly named our servers, these were cattle not pets.This change of characteristics[...]

How to master strategy as simply as I can ...


Understand that strategy is a continuous cycle. You don't have all the information you need, you don't know all the patterns and there are many aspects of life that are uncertain ... fortunately not all is. Start with a direction (i.e. a why of purpose, as in "I wish to win this game of chess") but be prepared to adapt as the game unfolds (i.e. the why of movement, as in "should I move this chess piece or that one?").Your first step on the journey is to understand this strategy cycle.Step 1 - The cycleYour next step is to observe the game as it is i.e. the landscape. This is essential for you to be able to learn about the game, to communicate with others and to anticipate change. To observe the landscape you must have a map of this context e.g. in chess it is the chess board and pieces, in warfare it's often a geographical map and troop movement. Any map must have the basic characteristics of :-being visualcontext specific (i.e. to the game at hand including the pieces involved)position of pieces relative to some anchor (in geographical maps this is the compass, in chess it is the board itself)movement (i.e. how things can change, the constraint of possibilities)In business, extremely few companies have maps. Most have things they call maps (e.g. stories, business process diagrams, strategy plans) which turn out not to be maps as they lack the basic characteristics. A simple way of mapping a business is to start with user need, understand the value chain and map it over evolution.Step 2 - LandscapeOnce you have a map, then you can start to learn the next part of the strategy cycle i.e. climatic patterns. These are things that effect all players and can be considered rules of the games. The more you play, the more rules you'll discover. I've added a basic list, to get you started in business.Step 3 - Learn Climatic PatternsEven with a few basic patterns you can apply these to your map to start to learn how things could change. There will be more patterns out there but again, you'll need to keep playing the game to learn them. With a map, you visibly communicate in a common language those things you expect to change. This also enables others to challenge your assumptions, a key part of learning.Step 4 - AnticipateNow you have an idea of your landscape and how it can change, you'll want to start doing stuff about it. However, there are two classes of choices - universal and context specific. Universal choices are those which are beneficial to all, regardless of the context. To help you on your way I've provided a basic set which we call 'doctrine'. As with patterns, the more you play the game then the more universal forms of doctrine you'll discover.Step 5 - Learn DoctrineOf course, knowing about doctrine is not enough - you'll want to apply it. When it comes to doctrine then there are three basic cases:-the map solves doctrine for you (e.g. having a common language)you can use many maps to apply doctrine (e.g. use of multiple maps of different lines of business to reduce duplication and bias)you can apply doctrine directly to a map (e.g. cell based structures, cultural forms such as pioneer - settler - town planner)Step 6 - Apply DoctrineThe other class of choice is context specific. You will learn there exists many approaches that you can deploy in order to influence the map. These approaches depend upon the map and the position of pieces within it i.e. they are not universal and you have to learn when to use them. I've provided a basic list. As with climatic[...]

Keeping the wolves at bay


Chapter 8[Draft version. The completed version is on Medium]To keep funding my research, I took a few more paid gigs which basically meant becoming a gun for hire.  Cloud computing was colliding with the technology scene and there was lots of confusion about.  This meant a constant stream of conferences - including some that actually paid - along with plenty of opportunity for piecemeal work.  This wild west also resulted in some fairly shady practices and exploitation.  I tried not to cause harm and instead gave time to community events like Cloud Camp London.  Hang on, don’t you either decide to do harm or not?  Where’s the ambiguity?  My problem was simplicity.Making it simpleOne of the issues with mapping is people found it complex.  This is not really that surprising because you’re exposing a world that people are unfamiliar with.  It takes time and practice.  However, confusion over cloud computing had also created plenty of opportunity for a new way of thinking.  Alas piling on complexity onto a confused person doesn’t help them hence I looked at ways to simplify, to make it more palatable and more familiar.  I started spot painting.Spot painting companiesTo help people understand maps, I produced mini-cheat sheets (see figure 73) for each of the stages of evolution and then rather than produce a map, I used to paint on whatever existing diagrams they had.  I’ll use the following figures from a Butler Group conference in 2008 to explain.  I’ve taken the liberty of updating the older terms of innovation & bespoke to use the modern terms of genesis and custom built.Figure 73 — A cheat sheet for commodityThe cheat sheet had a number of features.  It had the evolution scale (point 1) to provide you an idea of what we were talking about (e.g. commodity) and how it fitted into evolution.  It had a basic list of primary characteristics (point 2) and a benefit curve (point 3).  This benefit curve was a reflection of the changing differential benefit of an activity to an organisation e.g. research was an overall cost, commodity provided little difference and the differential value of products declined as they became more widespread.  I then used these mini cheat sheets to annotate existing business process diagrams – see figure 74.Figure 74 — Annotated diagramThese diagrams have certain advantages and disadvantages over maps.  First, they are more familiar and unthreatening i.e. you can take an existing process diagram and colour it.  They certainly (in combination with the cheat sheets) help you question how you’re building something.  But, as they have no anchor, there is no position relative to a user which means people don’t tend to focus on the user.  Also movement cannot be clearly seen but has to be implied through the changing of colours.  These diagrams enabled me to introduce the concepts of evolution but without position and movement then they were unhelpful for learning economic patterns and forms of gameplay.  However, the simplicity made them moderately popular with a few clients.Taking it too farUnfortunately, I didn't stop there.  The next diagram, I’m a bit loathe to show.  I wasn’t trying to cause harm and I hope it hasn’t.  In order to teach mapping then I simplified the evolution curve and focused on the extremes – see figure 75 from the Bu[...]

Finding a new purpose


Chapter 7In 2007, I was at home.  Unemployed.  I twiddled my thumbs for a couple of days, did some DIY and then set about thinking on my future.  This is code for watching my bank balance plummet whilst not doing anything useful.  I was exhausted, running a company, inspiring a future and being broadsided had taken its toll.  However, whilst I wasn’t ready to immerse myself into a new role, I couldn’t just sit idle.  So, I undertook a few paid speaking gigs, did some advisory work, wrote a few articles, ghost wrote a few more and researched. At least, it would keep the wolves at bay for a bit.I was convinced that there was some mileage in the mapping concept but I had two major problems.  First, I had failed to create that bright future with it.   Second, I had no real evidence to support it.  I had collected data that hinted components evolved but the evolution axis was no more than a pattern that I had observed and talked about at Euro Foo in 2004.   Maybe it was completely wrong?  Maybe that’s why I failed?  Maybe that’s why no-one else seemed to be talking about these concepts?  I decided my library wasn’t big enough to answer these questions and became a reader at the British Library.  I collected, collated and trawled through a huge volume of written work in pursuit of my answers.  At the very least, it was keeping me busy and providing time to recoup.As I read more into the subject of strategy then I noticed that disquiet over the field was palpable.  Phil Rosenzweig, in the Halo Effect (2007) pointed to the cause being a marriage of convenience: “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.”I wanted to change this, to somehow give people the tools they needed to learn themselves by exposing that secret tome of strategy to everyone.  I wanted to be free of this marriage of convenience and I still believed there was a secret tome back in 2007 and that it was probably guarded in the halls of business schools.  I started to think about doing an MBA, shuddered at the expense and borrowed copious notes and books from friends who had.  However, I was disappointed.  Beyond basic concepts in financial, marketing and operational “strategy” there was no discussion of landscape or context.  Maybe the tome was guarded in the halls of strategy consultancies themselves?I applied for a job with one of most prestigious consultancy firms and I was invited to a competitive interview process with dozens of other candidates.  We would be put through our paces in a number of rounds in a Darwinian battle, a survival of the fittest.  In my first round I was asked a question - “A news media company is looking at divesting itself of its print and distribution business. What things should it consider?”I immediately starting mapping out the landscape, pointing to opportunities and impacts from loss of control through physical capital to provision of distribution as a public utility to redirecting print capabilities into printed electronics - those [...]

Getting started yourself


Chapter 6I often talk about that wise SVP that I met in the Arts hotel of Barcelona. I’ll jump ahead of the story and let you into a little secret. He didn’t have a clue either. However, I didn’t find this out until 2011. I had always assumed that there was some secret tome but it turns out that much of industry is fighting battles with a poor understanding of landscape. It’s like generals fighting without maps. It boils everything down to luck and individual heroism. When I discovered this, I started to question the trove of business strategy books in my small library. I had an onerous task of going through it all and categorising individual pieces as doctrine, climatic pattern, context specific or just plain luck. These days, when someone tells me they know strategy then I ask them for a map of their business. If they can’t show me it, then regardless of their claims I take a skeptical position.  They probably don’t know as much as they hope they do. They might even be more dangerous than this as it’s rarely the unknown that gets you but what we think we know but don’t. This doesn’t mean I think people are daft but instead that understanding your landscape, the context that you’re competing in and having a modicum of situational awareness is not a luxury for strategy, it is at the very core of it. Inspiring vision statements, well trained forces, a strong culture and good technology will not save if you fail to understand the landscape, the position of forces and their size and capabilities. Colonel Custer is a worthy lesson here and even he had maps which were better than most corporates today. I've seen billions wasted by companies that have charged into battles that they have no hope of winning. I've seen endless SWOT diagrams, stories and other magic thinking used to justify such actions. I've also seen others tear apart industries with ease.Unfortunately, for those who lack some form of military background then situational awareness is rarely a topic of discussion. It’s often a struggle to make executives appreciate that it might matter, that you have to apply thought to the process and that the secrets of success might not work everywhere. In more recent years, I started to recommend that executives spend a month or two in some form of coaching that involves playing a massive multiplayer online role playing game (MMORPG) such as World of Warcraft (WoW).  You might think that this sounds like goofing off from the real work of business but for those who are uninitiated then there are some basic practices that an MMORPG will teach you. These include: -The importance of maps.  Before launching your team of elves and dwarves into the midst of a battle then the first thing you do is scout out the landscape and improve your situational awareness. Understanding the landscape is critical to strategic play, to learning, to using force multipliers and to not getting spanked i.e. beaten soundly by the opponent. Play the game long enough and you’ll know this by instinct along with moaning at players who haven’t bothered to look at the map hence wasting both their and your time with constant questions of “Where is this? or "How do we get there?”The importance of aptitude. The biggest battles require a multitude of aptitudes from damage (those who do our spanking usually from range) to tanking (defensive protection) to healing (th[...]