Transcript
Wardley: I'm going to talk about maps, bizarrely enough. Has anybody ever seen any of my maps at all? Any? Wow, that's about 15%, that's amazing. What we're going to go through today, I'm going to talk about the issue of strategy and then I'm going to talk about maps and why maps matter, why they're important. Then I'm going to get onto communication and why we need maps to communicate, then we're going to talk about patterns, because, one of the beautiful things about maps is that you start to learn patterns about a space. Then we'll get onto anticipation of change before we get onto how to organize yourself before we finally get onto leadership. Then we're going out in to sea, and we're going to talk about Serverless. We're going mix all of that stuff to tackle this one subject. We're going to do it all in 50 minutes.
Strategy
We start about strategy, this is a bit of a journey back in time, takes me back to 2004, I used to work for this company, Fotango is an online photo service, 16 different lines of business. Many millions of users have small by today's scale, but quite big back then, revenue rapidly growing very profitable. I had a problem though, and its problem was this person, the CEO. The CEO was a fake CEO, they didn't have a clue what they were doing. Now, I know this because I was the CEO, I wasn't some sort of chess player, I was more the alchemist making it up as I went along.
What do I mean by that? When it came to navigation of the business learning and strategy, while I was all about storytelling, secrets of success, or we should copy those people, magic frameworks, it was what I call a low-level situational awareness environment. I would pick up copies of "Harvard Business Review" and read the latest articles such as the November 2011, How Ear Lobes Can Signify Leadership Potential. It's not an April fool, I think we better employ people with the right sort of ear lobes.
Chess is very different, it's visual, you've got the board, it's context specific, it's game at hand. It's all about position and movement, is what we call a high-level situational awareness environment. It's a bit like the military, if you ask a general, "Why did you bomb that hill?" It's all about position and movement. In the business world if you ask a general, "Why did you bomb that hill?" It would be, "Well, I read an article in General Weekly, bombing hills is the latest thing." Or, "I've got a consultant report saying 67% of other generals are bombing hills, therefore, I should bomb a hill." Or it would be, "Because that's what Uber would do."
I got interested in military history and I went back to Themistocles. Themistocles, ancient politician, Greek general had a problem, the Persians were invading. Somewhere between 140,000 and 170,000 Persians were invading a much smaller Greek force, the city-states, but they had a combined Greek force. What they did was block off the streets of Artemisium, forced the Persians along a coastal road, a narrow pass called Thermopylae, where a small number of troops could defend against a larger force. There was about 4,000 Greeks, including 300 Spartans.
I want you to imagine, I'm going to take the business view of this, I want you to imagine that I'm Themistocles. I'm giving you purpose, a moral imperative, defend against the invading Persian hordes. Then I say to you, "I don't have a map, I don't understand the landscape, I don't understand the environment, but I have no fear for I have created a SWOT diagram." Strengths, a well-trained Spartan army, a high level of motivation not to become a Persian slave. Weaknesses, the Ephors might stop this Spartans turning up a truckload of Persians or turning up opportunities, get rid of the Persians, get rid of the Spartans who are actually Athenian. We don't like the Spartans and the threats the Persians get rid of us, and the Oracle says, "A really dodgy film might be produced a few thousand years later." What would you use to communicate and determine strategy in battle? Position and movement described by a map or some sort of magic framework, like a SWOT diagram?
Participant 1: Map.
Wardley: Map. What do we use in business?
Participant 1: SWOTs.
Wardley: Good.
Why Do Maps Matter?
There I was and I realized I wanted to be over here, but in order to be over here, I needed to understand the landscape and that brings me onto maps. The first question is why do maps matter? I started going back through history and came across Sun Tzu. Anybody, know what Sun Tzu wrote?
Participant 2: "The Art of War."
Wardley: Perfect. Sun Tzu talked about five factors that mattered in competition. One, understand your purpose, your moral imperative. Two, understand the landscape you're competing in. Three, understand the climatic patterns, this is how the landscape is changing the weather. Then you understand doctrine, these are patterns of organization, how you structure yourself, then finally, you get into leadership. It's a cycle, every action you take may impact the landscape and the weather, of course, may change, and so you just keep on iterating around this process. What's important to remember is that landscape impacts it all, in terms of the games that you can play, the opportunities you can exploit. Then I came across John Boyd. Anybody know what John Boyd wrote? OODA Loops. US Air Force pilot, so you have the game.
The first thing you need to do, the first O is observe the environment. That's what landscape and climatic patterns are about. What the landscape is? How it's changing? Then you need to orientate yourself around it so that's doctrines about, and then you need to decide where you're going to attack and then you act and then you just keep on looping around the cycle. I was quite excited by this, I would show it to others and they would go, "Oh, it doesn't matter." Strategy's all about the importance of why. Problem is there are two whys, there's the why of purpose and the why of movement, they are very different things. If you think about a game of chess, my why of purpose might be to win the game, my why of movement is do I move this piece or that piece, and it's through movement that we actually learn. Assuming that we can perceive the environment, otherwise, it's just outcome bias and all those sorts of things.
I went back to Fotango, I thought, what's our purpose? Well, I produced the purpose, so it was enough to mess, but that's ok. As we went round the cycle, we get better, so my next question was, how do I observe the landscape? Well, we had loads of maps. We had systems maps, have you seen a system map before? I presume everybody has. Business process maps, we used to have mind maps, we used to have all sorts of maps, but that led me to another question. What is a map? Here are three graphs that are the same. Nottingham, London, Dover, connected by M1, M2, same graph, same graph.
Here are three maps and these are all different, the reason why the maps are different is because I've added this thing, a compass, and now space has meaning. That's the thing about a map, which separates it from a graph, is that space has meaning, if I take a map and I move a piece, it changes the context and what that map means. Space has meaning because we have an anchor, we have the position of pieces relative to the anchor, so this is north, south, east or west of that, and we have something called consistency of movement. If I want to go from Thebes to Thermopylae, which direction would I go? Northwest. If I go northwest from Thebes and I ended up at Athens, what does that tell me? The map is possibly wrong, upside down, or maybe the compass is wrong.
I looked at my systems map and I took one component, CRM, customer relationship management, and I moved it. How does that change this map? It doesn't. If I took an atlas and I took Australia and I shifted it next to London, would that actually change that Map? Yes. Why doesn't it change this map? Well, because it's not a map, in fact, the only thing that mind maps, business process maps, systems maps, and all the other maps I had, had in common was none of them were actually maps. We keep using that word and I'm afraid it doesn't mean what we think it means.
How to Create a Map
How to create a map? Well, I start off with a systems diagram, I give it an anchor at the top. In this case, I put customer and then I describe position through a value chain. A customer wants online photo storage, which needs website, which needs platform, which needs computer, which needs power, and of course, the stuff at the bottom is less visible to the customer than the stuff at the top.
I've got anchor in position, now, we need to add movement and simply add an evolution access. It turns out the capital of all different forms where the data knowledge practices or activities has a common way of evolving. In the case of activities, we have the genesis of the novel I knew, custom built examples, products and rental services, commodity and utility services. I simply created a map and that was the first map that I did in 2005. Ok, so what? Well, the first thing a map helps with is communication. I'm going to use a cup of tea as an example, here's a map for a tea shop. Business has a need to sell cups of tea public, we hope have a need four cups of tea, that requires a cup of tea, hot water, hot water needs cold water in a kettle, kettle needs power.
The first thing is we're focusing on the user needs, the users can be many forms: business, public, your staff, regulators. You share this map with others, the first thing will happen if somebody say, "Oh, you're missing staff." Then somebody else will go, "Oh, we don't want none of those staff. We want robots at staff or something along those lines." Then somebody else will come along and look at this map and they will say, "Well, each of these nodes are stocks of capital and each of the lines are flows of capital. What we can do, we can add metrics to it and from this we can build PNLs." Then somebody from operations will come along and say, "Why are we custom building kettles? Why don't we just use standard kettles?" Then somebody from marketing will go, "It's all about brand exclusivity." The point about the map is it doesn't matter whether your HR, finance, development operations or whatever, we can all talk about the same space with the same instrument. Business alignment issues disappeared for me.
There is no just within groups but between groups, this is an example to do with weighing scales. Particular department has to produce a count for another group, it gets this count through weighing machines. What happens is it gets lots of paper forms and it's too time consuming to count up the paper forms. What it does, it weighs them to calculate the number of paper forms, puts them into a system and reports that number at the end of the month to another department. It wanted to spend a lot of money converting its manual weighing scales to digital, it's part of a digital transformation program. Exciting.
I had to look at this and I said, "Ok, what you're counting is paper forms, where are the paper forms from" They said, "Oh, they come from goods in." You go along to goods in and say, "Where are you getting your paper forms from?" "Oh, they come on from distribution sites from all over the country, about 20 of them." Ok, go and visit one. "Where are you getting your paper forms from?" At the distribution site, "Well, we print them out." "You're printing these paper forms?" "Yes." "You're sending them to this group?" "Yes." "Do you know what they're doing with them?" "No." "Ok. Where are you printing them out from?" "Our CRM system, which our users fill in online."
"The users fill in a CRM system online and you print out the paper to send this other group to count the number of paper forms printed out?" "Yes." All of this could be replaced by select count staff from table. These people aren't stupid, what's happening is they're optimizing their local area. I'm seeing the whole picture, does spending millions on a digital transformation program with new shiny additional scales make sense? No. Ok, so once you learn to communicate, then you start to discover patterns and there's about 200 of these of which about 30 are economic patterns or climactic patterns, 40 are to do with organization known as Doctrine, the rest are all gameplay.
Anticipation
We start off with the observing climactic patterns. These are the rules that influence the game. The first pattern that you learn with your map is everything evolves, if there is supply and demand competition, it is moving from left to right. The second pattern you learn is that we have inertia to change because of preexisting capital. Classic example of this is Blockbuster Netflix, who was first with a website? Blockbuster. Who was first with video ordering online? Blockbuster. Who was first with experimenting with video streaming? Blockbuster. Who went bankrupt first? It wasn't because of lack of innovation, they out innovated everybody. Why do you think they went bankrupt? What was their problem? Shops. It was late fees. Do you remember late fees? Some of this will be a generational thing? We used to get these things called video cassettes. We forget to take them back because we were drunk, and they charge us more money. There are no late fees in streaming.
The next thing you learn is as things evolve, they enable higher order system, so efficiency enables innovation. Those higher order systems we call the adjacent unexplored, new spaces to be discovered very much in the genesis phase, but out of it, you get new sources of value of worth. When electricity, which started off with the Parthian Battery and evolved eventually with Tesla and Westinghouse, utility provision of electricity, we've got all sorts of things. Television, radio, computing, the American Electro-Therapeutic Association. Wake yourself up with a daily shock, all sorts of weird and wonderful things.
All of those components evolve because the supply and demand competition, and as they evolve, their characteristics change. It could be computing, it could be money, it could be penicillin. Starts off in this uncharted space, it’s chaotic, uncertain, unpredictable. We don't know what it's for, eventually, it becomes industrialized, ordered, standard, boring, dull, in the case of drugs, generic. Because of that characteristic change, agile as in extreme programming is very good on the left-hand side because it reduces the cost of change because change is the norm, but it's terrible on the right-hand side compared to Six Sigma because Six Sigma, it's focused on reducing deviation, which is what you want. Both of them are pretty hopeless compared to lean in the middle where you should be focused on learning and reducing waste. What you learn is there's no such thing as one-size-fits-all.
If you say that at a conference and people go, "Well, not agile everywhere, burn him heretic." I'm sorry, I'll give you an example, HS2, high-speed rail. James Finley, CIO, HS2, they decided to build HS2 in a virtual world, first of all, because it's cheaper to dig up a virtual world and go, whoops, we got that wrong, than it is the actual countryside, so they built the entire system in a virtual world. This actually went to the public accounts committee, got praised because it was delivered ahead of schedule and under budget. Wow.
He started off with a systems diagram for building HS2 in a virtual world. James's problem was this, should I outsource the lot? Which is what we normally do in government. Should I use off-the-shelf products everywhere? Should I build it all in a house with agile techniques or should I use some sort of combination? Outsource this, building house this, use products here.
The problem with the combination is even in this simple diagram, there's 387 million possible permutations. Which one do I choose? He created a map. Now, it's very simple, you outsource the stuff on the right-hand side, you use off-the-shelf products in the middle, you build in house agile techniques on the left-hand side, you use appropriate methods. I'll give you a test, anybody from finance here? Is it a fair statement, to most people in finance, IT sounds a bit elvish? Yes. I assume that is a quiet stoic yes. I'm going to pretend you are all from finance and I'm from IT and we're going to talk about self-driving cars. What I've done is I've taken a systems diagram for a self-driving car and translated it all into elvish. Now, I want us to work and collaborate together, should we outsource or build our own A and B? What do you think? I want your input. It's easy, we're trying to work. That's the mapping version, should I outsource or build our own A, exactly the same diagram? What should I do with A? B?
Turns out that A is actually GPS, it's a good thing we decided not to build, B is a world perception server, so that's a quite useful thing to build. Once you get through patterns and we remember this 13, we've just done a few. You get to anticipation. This is what you take the landscape, apply the patterns, you can discuss what's going to change. I have a map here we are in 2005, we knew platform compute would evolve to a utility. We knew we'd have inertia, we knew it enable higher order systems to appear, and hence there are multiple points that we can attack. Do I want to differentiate on our photo service? Do I want to build our compute as a service or platform as a service? Or do I want to wait until somebody else plays that game?
Organization
Anticipation is one thing, you understand your landscape, you apply the patterns, you now have to organize yourself around this, this is where we get into doctrine. Doctrine are the universally applicable principles regardless of context, they work everywhere, so they are things you should do. Climactic patterns you can't stop, you can use them to anticipate change, but you can't prevent supply and demand competition, well, legally. Doctrine, this is the Emergency Services Mobile Communication Platform, first time I met them they said, "Here's a 600-page specification document." I went, "What's the user need?" People looked at me at horror.
You start off with a map and the first thing you do with a map is you focus on the user needs. In this case, this is emergency communication for police and ambulance users, need emergency function, point to point communication, job dispatch. That's not enough because underneath is, there's a whole range of other components involved, you need to think small, as in know the details.
One of the things about maps, is they're quite useful as a means of learning so, you share the maps with others. Immigration, police, border control, we share the maps, we discover, we have duplication going on, we're building the same thing. For example, user registration, we might have six people building systems for user registration, of course, there's buyers in terms of some people think it's a commodity, some people are custom building their own. One of the beauties about maps is you can challenge that.
The worst example of duplication in government I've ever found is 118 workflow systems doing the same thing, we've managed to build prisoner registration in 118 different ways, they say is nothing compared to the private sector. If you want waste, duplication and bias, the private sector rocks, I've got a bank who've managed to build risk management over a thousand times, we stopped counting. They're all at the complaining, we can't get anything done. I'm not surprised but this is nothing compared to that one industry which duplicates some waste more than anybody else. Do you know which industry that is? Our industry.
How many of you have ever built a user registration function? Keep your hands up if you've done it more than five times. We love rebuilding the same thing over and over again, we make Skyrim modders look good. One of the things you use maps for is removing duplication and then you get into interesting things like fist. This is from the U.S. Air Force, fast, inexpensive, simple, and tiny, this was used to build the harvest Hawk combat aircraft and that went from paper to combat operations in 18 months, fired its first shot in 19 months. If you know anything about military hardware, really fast and it's very simple. What you do is you take your bat and you break it down into small contracts, small components, which is what they're doing FIST and people then go, "Oh, microservices." Yes, that's a good idea."
Because we know no one-size-fits-all methods and we've got a map broken down into small components, we can now use the right methods in the right places. Once you've done that, you may as well organize with teams around this, small teams or cell based structures, microservices and cell based teams. Yes, that's a good idea. Then what you discover is there's no such thing as one-size-fits-all culture, because it doesn't matter if it's marketing, finance, operations or engineering for culture you need here is not the same as the culture you need here, this is a system called pioneer, settlers, town planners. Pioneers build, operate and maintain in that space where things are constantly changing. Settlers steal from pioneers and convert it into useful products and they're very good at listening and they build, maintain, operate in this space and town planners steal from the settlers and industrialize the components.
If you want to read more about that, GCHQ has a wonderful document called Boiling Frogs, all creative commons shared, go help yourself. Really good ideas. Let's go back to Fotango, I just want to show you how we were organized. That's how we were in 2002, me at the top, clueless and we had silos, one of the things we had with silos was lots of fights between different departments, about how we do stuff. I came up with an idea of what we should have is small teams, product owners, we did that in 2003. What do you think happened? We had more fights. What was going on? I looked to the teams and I realized that some of the team were focused on new developments, some were more sort of what we call core. In 2004, I split the organization into two parts, starting with IT spreading into marketing and finance.
Has anybody heard of bimodal? This is bimodal 2004. What do you think the net effect of that was? Absolutely, utter out warfare, that was disaster, it almost killed us. What was going on was Core would build core services, development would build on top, this stuff would evolve. Then they would go to Core and say you need to look after this, and Core would go, "Where's the documentation?" The fight would explode, so burn him, heretic, all arguing, nothing ever evolved. What then happened is Dev went and built new things on top of Dev. What I got was increasing instability in the entire system, open warfare between the two groups and nothing evolving.
Anybody been down the bimodal route. Have you got there yet? Oh, you will. Yes, this missing needle. I reorganized the entire company into three parts: pioneer, settlers, town planners, let people self-select where they belong to. You can think of that as tribes if you wish, and we had groups of attitudes. Attitude down as in pioneer, settlers, town planners, attitude like engineering, finance across, you can think of that as guilds if you want to. Then we had small teams with the right attitude, you can call that squads if you wish to. What we also introduced was a system of theft.
The groups would invade each other, pushing the pioneers on and so we created this cycle, assist them with theft within the system, which mimicked evolution. That's leading edge, I consider leading edge thinking 2006, so that's 13 years ago. Then with a map it's very simple, all that’s doing is replicating evolutionary flow within the system, flow's an important concept. I need to explain something and I'm going to use an insurance company as an example.
This is process flow, this insurance company, they need compute. They order serve goods in modify mount racket. They had a bottleneck around modifying the service, they came up with a plan to put robotics in to automate the modification, get rid of the bottleneck. I spent six months working on this, came up with an entire business case, SWOT diagrams and all, $2 million of investment, return of investment under one year. I came in and this took 15 minutes, I got them to map it. We started off with user needs compute, they put it in product, I would argue, then it was more utility, but ok, order server, server goods in. Server is a commodity, but computer isn't, ok, we'll let that pass. Then they added rack now to modify.
Anybody notice anything funny about that diagram? Why is racking custom bill? I said, "Why are your racks in custom build?" Oh, we custom build our own racks, we have a company do that for us. Oh, what are the modifications you're doing to service? They don't fit our racks. We have to take cases off them and drill new holes and add new plates to get into fit into our racks, that's why you need robotics. You could use expanded racks, shock, that's an example of evolutionary flow. What they're trying to do was optimize process flow, I see this all over the place. Once you do that with racks, should go compute, you're an insurance company. Don't build a private cloud or whatever, use utility compute.
That should process flow, you should be optimizing, not this one. It's very common, the most common thing I find is people optimizing process flow and then making more efficient things which are utterly ineffective. I had a particular Telco, this is 2010, they sat me down, they showed me the private cloud effort and it was 1.2 billion and I looked at this and I said, give you the same result for 25 million, and they were like, "Wow, how?" "Very simple. You pay me 25 million, I will sit on a beach for five years drinking Margaritas and then I will find you up and say we failed, and that way you'll have saved all the rest of the money." Anyway, they didn't like that.
Going back to weighing scales, I mean department count, what they're trying to do is optimize this process flow. Oh, sensible, you're trapped in that world, these people aren't daft, they just can't see the whole picture. Of course, really, that paper forms have evolved, they should be optimizing electronic records.
Leadership
Now, we get to leadership. Because if you can see the landscape and you start to anticipate change and you start to organize yourself around it, you can start to manipulate the environment. This is all about context, specific forms of game play. You can see where to invest, we learn, we can manipulate and there's about a hundred of these, we can use open approaches to drive things, more industrialized, fear, uncertainty and doubt where people have inertia, we can use constraints.
In 2005, we came up with a game play, we assumed that somebody was going to do computers, utility, I thought it was going to be Google, it turned out it was Amazon. The next year we built basically a platform as a service with billing to the function. All JavaScript front and backend and I better explain that funny symbol there. That symbol is known as IOC, it's an ecosystem model, it's very simple, IOC, you take a product, you turn it into a utility, you get everybody else to build on top. You don't look at their data, you just mine the consumption of your service to spot future patents. If I come up with computers, a utility, you'll build on top, you're all building kitten internet or something daft, except for you building big data. I'll, notice you're growing, you're not. I know there's something interesting in that space so I mind produce the new utility service other than everybody else builds on top, except for you, you grumbled that I've eaten your business model.
It's very simple, you get others to innovate for you, you mine the metadata to spot future patterns, you commoditize new component services. This was part of the zim key play back in 2005, 2006 and the point about this model is your rate to innovation, customer focus and efficiency now simultaneously increase with the size of the ecosystem. The bigger the ecosystem gets, the more innovation you're seen to be doing because others are doing it for you, the more customer focus you become because you're mining metadata to give people what they want and also the more efficient economies of scale. Do you think Amazon's tough today? Do you think they're hard to compete with? Is their ecosystem growing? What they're going to be like in five years, then? You're going to wish they were as easy as they are today.
That was the game play back in 2005, 2006. Yes, people do this compute machine learning engines. Basically, what you're using is this sign is a sensing engine. You don't do that stuff, you get everybody else to do it for you. Then you act, which is what we did, building the world's first platform as a service, rapidly grew. This was back in 2006, and then our parent company had some big consultants come in and say the three things that we were doing, cloud, 3D printing and the use of mobile phones as cameras. This was 2005, 2006 was not the future, the future was 3D TV, we should shut it all down spend $1 billion on 3D TV. Anybody here have a 3D TV? Do you use it? No. I don't like big American consultancy firms, strategy firms, but it didn't matter for me.
Let’s see, the thing is maps gave me a way of learning, I've never learned from past business cases in Swartz, I do from maps all the time. I went to Ubuntu, w mapped it out in 2008, I ran strategy and the whole cloud strategy for Ubuntu, I spent half a million and it took me 18 months. We were about 3% of the operating system market and we took over 70% of all Cloud by 2010, they pretty much still dominate the space. Does anybody remember that? It was all red hat, Microsoft red hat, Microsoft, and then suddenly in Cloud, it was all Ubuntu?
Then I started doing stuff with government, wrote the "Better for Less" paper for Francis Maude, I'm actually a member of Labor. This led to things like spin control and helps support in the creation of GDS, this is back in 2009, Liam Maxwell, good friend of mine, heavily use mapping. Government is now unfortunately with Amazon along with other friends who Matt, Adrian Cockcroft and so forth from Netflix. This is just one service, just simply mapping it out, they say 425 million, 1.5 billion is a lifetime. Generally, you find you can actually save money by hiring more civil servants and just firing U.S. strategy consultancy firms. This is James, he uses the RNLI to save lives.
Serverless
That gives me 12 minutes left, roughly tell you all about Serverless. I'm going to start, go back in history, this is where we started. Applications built in compute in the hardware itself, plugs, exciting stuff, then it evolved. We came up with systems like LEO, Lions Electronic Office, we had applications built on an operating system, no longer plugs but on the hardware. Then this evolved and we came up with the first products like the IBM 650. Now these products had a characteristic, high MTTR, high mean time to recovery, which means when my machine went bang, it would take me months to get a new one, which means we built novel architectural practices based around this, so things like scale up, capacity planning, disaster recovery, N+1, evolved and we created a new faction, because it's not only activities but data knowledge practices evolved, novel emerging, good and best. We've got good architectural practice and we used to go round laughing at people because their email server run out of space because they hadn't done the capacity planning. Oh, you silly Billy.
Then we got language frameworks, applications, emerging coding practice on a framework and an operating system. That all evolved and it looked like this and we were all happy and then Cloud happened, that's the entire history of Cloud at the bottom. It is just simply the shift of compute from product to more utility, but it has a big effect. Every time something trends transfers across one of those boundaries, the product to commodity, you get what's known as co-evolution of practice. The reason for this is we can go from high MTTR to low, which means I don't have to wait months, so I can get new machines in seconds. Now, we distribute systems, we design for failure, we use chaos engine, we can do things like continuous deployment because we're not waiting for three months for the machines to turn up.
Of course, executives got very excited about this, this utility stuff and so they would go, "Make my stuff cloudy." People would stick their legacy on Amazon and Amazon would have an outage in the early days and people would run around screaming, "The end of cloud is nigh," to which you would go, "Shouldn't our architecture evolve as well," and they would go, "Burn him heretic." That's because they had inertia created by best architectural practice for use of compute as a product, nothing more. Of course, this stuff evolved.
Eventually, we gave it Patrick and he gave it a name. We called it DevOps and we used to run around going, it's all about user needs, iterative cycles, automation, collaboration, and people would go, "So as ITIL," to which we would go, "Burn him heretic." The operating system is industrialized now to more of a commodity and now it's happening with the framework and we call it Serverless and yes, it still has servers down here. It's a code execution environment where we have a spectrum where we consume multiple services. Some are more serverless than others, but you get companies like iRobot, 23 million robots, IT expenditure per month, $15,000, wow. You've got all these companies building on top, it's really exciting and, of course, we're getting a new tribe, a new faction, and a new co-evolved set of practices. That stuff is the future, this stuff here is all the legacy to which people say, "Hang on, DevOps, how are you saying DevOps is the new legacy?" To which the answer is, "Yes. Burn him. Containers for the win”. That's why we've got this stuff going on, serverless, containers.
The two tribes regarded each other suspiciously in the glow of their blazing production environments. Look, the honest truth is all the stuff below, that line of code execution is just going to become less visible, we won't care. Containers, infrastructure, the whole lot. Who cares? Just write code. If you want to compete in this world, you need to move up the stack.
One of the new practices that are forming, if I take user need and applications are actually a pipeline to the novel to the more commodity, then what you've got is Amazon charging up serverless code repositories, API markets, Amazon and Microsoft. On the left-hand side, this is where we get the emerging practices, exciting things like serverless security. Security is completely different in the serverless world. Market reporting, management of capital flow, conversational programming, I'll just deal with one of those mainly capital flow.
Do you remember I said with a map? Each of these are stocks of capital and each of the lines are exchanges, you can add metrics and create P&L for this? That's the cup of tea example, we'll just replace this with functions. We can start monitoring and measuring capital flow inside out applications, that changes the way we operate things, how we monitor things. It gets suddenly gives refactoring has financial value because we know if we shift this function from over here to here, it's going to reduce this cost, we can tell what that change is.
Observability of capital flow is just a good thing, you're getting lots of companies starting to develop in this space Epsagon, capital flow itself, Lumigo. It's all about now measuring the flow of capital within applications and eventually tying that to value. It introduces entire new business models.
The other one is conversational programming, this is really early stuff, Aleksandar is working on this stuff. This is where you were taking AI and things like, for example, Alexa and serverless and building environments such as Jenkins, where you literally can talk to Alexa and get it to build your environment. He's got some wonderful videos demonstrating this where he's talking to Alexa saying, I need a website which collects traffic information. It goes and builds him the basic infrastructure to do this. Now remember it's early stages, but it's higher up the stack. Meets your future data center, head of operations and lead developer, you're already getting used to them, they're probably in your home.
Conclusion
To quickly recap, we started off with strategy. Why I had none because I had no maps. Why maps matter? How they're useful for communication? How you can learn patterns. Then we got onto how you can use maps and patterns to anticipate change, how you can organize yourself and how you can do basic gameplay. Then we took that all together to try and describe the serverless environment, the changes that are actually occurring. Where you are getting this change of practice, co-evolution of practice, why you are getting this new faction? I'm afraid tribes have got a tribe, there are some people who think, "Oh, it's all part of DevOps." No, it is, it will copy, it will core-op the practices, but it will give its own identity in the same way that DevOps did with i2. We haven't yet evolved enough in IT to learn to manage evolution.
Then we talked about the importance of those change of practice things like capital flow and eventually, you're going to see conversational programming and that's all kicking off now so the battle in terms of who will dominate serverless is happening right now. At the same time, the laggards are just daunting Cloud, it's hilarious, it's like the Telco company. I hear people say, "Oh, we're going to go DevOps and infrastructure as a service” and that's great, it'll take you seven years to get there. That's how long it took Netflix, by the time you get there and get rid of your data centers, you'll have just built the new legacy. You need to focus not on the past or the now, but where the industry will be.
All this mapping stuff is creative commons, you can help yourself, I've got a 600-page book. I haven't finished it, I will do at some point just nick it all, it's all creative, common share alike. The other thing to know about maps, all maps are imperfect, don't worry about creating a perfect map, you can't. This is a map of France, it is not a perfect map of France. If you were going to create a perfect map of France or try to, it would have to be one to one scale, which means it would be the size of France. That's pretty useless as a map because that would actually be France itself, I'm not making any comments about France. Lastly, "Crossing the river by feeling the stones." This is a statement from Deng Xiaoping, famous economist, Chinese economist, and leader. It's all about having purpose and direction, taking small iterative steps and understanding your landscape as you go along, which is what maps are all about.
See more presentations with transcripts
