This week we look at the topic ‘Can Wardley Maps predict the future? We did a Wardley mapping 101 last time, explaining the basics. This is the second installment in our Wardley mapping series.
One of the things that we say is that Wardley Mapping is a superpower that helps you predict the future. What do we mean by that?
It’s like a fortune teller. But it doesn’t tell you when exactly something’s going to happen. It’s about the state of mind that Wardley mapping puts you in. We’ll run through a couple of examples, to demonstrate how we’ve done it in the past.
What do you think about the statement: ‘Wardley Mapping helps you predict the future?’.
Wardley Mapping is not gazing at a crystal ball
Mark McCann
I think it’s fairly accurate. It’s something we’ve seen time and again. It’s not like reading the runes or gazing at a crystal ball. You just have better situational awareness. So you can make reasoned and predictive choices about what’s going to happen. You can start to see trends, patterns, and how things are emerging. So you know when you should take action. Or step back and let things evolve naturally on their own. And take advantage when they become available to you.
Michael O’Reilly
I like Wardley Maps, but I also like the Wardley strategy cycle, and the various segments within it, at a high level. Things move fast, things progress and things evolve.
Innovate, Leverage, Commoditize
But there’s a gameplay Simon Wardley refers to as ‘Innovate, Leverage, Commoditize’. If you look at a particular map and situational awareness. And you look at how evolved the key components are in that map. Then you think about the ILC and how things progress, you can start to look at predictions. And start to ask yourself hypothetical questions. If this evolves or moves in terms of ILC, how does it impact that today?
There’s a phase in that strategy cycle on climatic patterns. In other words, even if you were to do nothing, how is this going to work? What things are likely to change? So it’s probably on the advanced side of Wardley Maps. But the more experience you get, the more you can find yourself in those conversations, which are really useful.
Dave Anderson
It’s a what if? But it doesn’t predict the exact date. We’ve got five examples that we have experienced through our careers that have been interesting. And we’ll talk through them now. For me, it’s not about when this is going to happen. It’s more about when this thing happens, how will our strategy be affected? Every year at AWS re:Invent, AWS makes a new announcement and you hear of a company going out of business. You don’t want to be in that situation.
1. Conversational Programming
Our first example is conversational programming. Simon Wardkey did a map about eight or nine years ago, on conversational programming looking at when you will be able to ask your computer to write a programme. At the time we were thinking this is far fetched.
But we’ve seen the emergence of Chat GPT, where people are literally saying: ‘Build me a website’ and boom it pops out. Looking at that map years ago, you thought, if that happens, what things in my job as a programmer do I not need to know anymore? What can it help me with? For me, it was a ‘what if?’ That was a game-changing idea when we first saw that map years ago.
Mark McCann
It’s about positioning yourself appropriately on the value chain. If these things become real and become commodities and available to everybody, where’s the value? We’ve seen the same thing with Serverless. And we’ve seen the same with the move to the Cloud. When these things evolve and become widely available and easy to do, where is the value?
Position yourself high up the value chain
So you need to make sure you position yourself as high on that value chain as possible. If that’s your strategy. So if conversational programming becomes really easy to generate lots of code, what’s the higher value thing that you could do? Are your testing practices in good shape? Do you understand the needs of your users and the value of what you’re trying to accomplish? You start to see the collaborative, facilitated practices become more valuable. Because writing and generating the code is going to be faster and more of a commodity than it is today.
Dave Anderson
You still need to be able to do it and understand it. But writing beautiful code is not enough. I am going against the opinion of my younger self.
Michael O’Reilly
Chat GPT 3 and Chat GPT 4 are getting better. In terms of a Wardley map, you are representing something that is custom. That could be code or knowledge of a particular framework. But now it has moved to a tool or commodity that can produce something fairly similar and good. You still need the expertise to validate what it’s producing. But your capital flow has improved, as you can do something faster.
So ask yourself, what does that free up? Where should you spend your time for more value add? How do you react to move further up the value chain? You could think about adding value to the code. Or focusing more on the business and if the product is having an impact. In other words, let me produce something that has value and work on the next higher-order capability.
Challenging current thinking
Dave Anderson
One of the things that Simon Wardley is brilliant at, is challenging current thinking. When he produced that map he challenged us to think higher. He talked about Worth-Based Development or FinDev. And that became FinOps. Which is thinking about the cost of building early. And now that has become an important FinOps practice for cost optimization. So it’s about the ability to use mapping to challenge thinking and push ahead to the future.
Conversational programming has moved on the map. Now there will be code liabilities generated. We often say code is a liability. So who’s going to manage those liabilities, if you are producing a lot of generator code? How do you manage and cope with that? There are new emerging needs coming out of that evolution.
2. Generative AI
A second example is Generative AI. I remember when the Machine Learning (ML) push started, around eight years ago. Everyone got excited about ML. I remember having conversations with engineering teams who wanted to build an ML Pipeline. They wanted to bring in open-source tools to do it brilliantly. And you can think: ‘Yes, you could do that. But do you really want to compete against AWS, Google, or Azure?’. Because that’s not smart. You can see the value chain in the AI or ML services as well.
Only this week, AWS released their Generative AI suite with Bedrock, which commoditized all those ML tools. You might have invested a lot of money, five or six years ago and built something better than SageMaker. But now you are behind. Why? Because the product providers have come over the top of it. I remember mapping it out years ago and thinking we could focus on an ML platform. But let’s focus on getting really good at ML engineering and how we deploy and handle models. In other words, how do we deal with the Well-Architected ML Model as opposed to building a platform? That was a good move and mapping helped that as well.
Mark McCann
I remember those conversations, I think the focus on ML Ops and the Well-Architected, Machine Learning Analytics lens directed us to the building blocks and foundations that allow you to rapidly iterate and deliver AI Machine Learning capabilities. Because the underlying components are going to change. And you’re not going to compete against AWS, Google, or Azure.
Don’t fall into the sunk cost fallacy trap
Dave Anderson
Maybe you can build something slightly better today, than the cloud provider. But that’s not going to last very long. You might get six months or a year out of it. And then you have hit a sunk cost fallacy. It’s about figuring out what your specialties are.
Michael O’Reilly
I remember we did a map, a number of years back, and had a very similar conversation. There was a lot of uncertainty around the data. Corporations like to hold on to their data, and they don’t like feeding it to third parties, because it’s about building out their capability. And you’re thinking, what if you had these foundational models? You could purchase the base model, and then enrich it internally. Looking back now I realise we were pretty accurate.
Mark McCann
The same arguments have come around again with Chat GPT. Enterprises don’t want to give it any of their data. So now you see the likes of Amazon Bedrock come forward. So with your own data, services, and ecosystem, you can train the models yourself, without exposing them to a larger LM.
Michael O’Reilly
I don’t want to open a can of worms. But I’m sure, on the map somewhere, there’s an ethical point around these large language models.
3. Well-Architected
Dave Anderson
Returning to the topic ‘How does Wardley Mapping help predict the future?’, the third example is Well-Architected, I think this is a good one. Because I remember we spent loads of time thinking about the question: ‘What’s architecture?’. And what do we do in architecture? Then we started thinking about the well-architected framework from AWS. And there are well-architected frameworks in Azure, and Google as well.
There are three elements:
- The framework and knowledge itself
- The process you put around that
- And then the tool for running it
There are two specific things that I remember talking about. Do we try and update the knowledge in the well-architected framework? And do we try and write a better tool? Because before the well-architected tool came out, it was very manual. And I remember thinking should we write something to make that easier? So we mapped it out. And we focused on the process, which became SCORP. We knew that if we locked a lot of custom knowledge into well-architected, we would lose the updates from AWS. And if we tried to write some wacky tool ourselves someone else will write one and that would be a wasted effort. So that was a was a good map.
Mark McCann
Early on, we were aware that you don’t custom-build your own cloud guidance framework. And fall into the trap of thinking that we know better than 1000s of validated and proven use cases from multiple customers.
Dave Anderson
We knew we didn’t know.
Predicting future movements with Wardley Mapping
Mark McCann
With that map, we predicted some of the future movements. We could see the investment that cloud providers were putting into this knowledge, frameworks, guidance, and advice. And we could see that it was evolving rapidly. And we could see it through our own connections. Because with some of these things, you can validate and satisfy yourself by talking to people about what they are thinking. And you start to sense and see some of the literature, presentations, or terminology change.
They are points of interest that validate your thinking, your map, and if it is going the way you think it’s going. We’ve seen the evolution of the well-architected tool on AWS And we’ve seen the evolution of new services and capabilities like Security Hub and the Reliability Hub. It’s automating a lot of the well-architected checking.
SCORP made us efficient and reduced duplication
Michael O’Reilly
With that one in particular, what stuck out on the map was the amount of duplication going on. There were lots of teams running well-architected reviews and solving the same problems. So we knew there was bound to be a way to make it more efficient and reduce the duplication and time to value for the things that squads weres trying to do. We came up with SCORP to get teams to line up and share what they’re doing in a collaborative, well-architected process.
Dave Anderson
Heuristics has always been a thing. You need a platform to get good at telling you when something’s wrong, or how to tell you before something fails. We guessed that such a solution would come out. And now we have Trusted Adviser telling us stuff, which is interesting.
Mark McCann
A lot of those tools have emerged. We could have spent a lot of time building fast feedback loops to tell us if we were well-architected. But by mapping it out, we could see that the ecosystem was going to provide these capabilities that we build on top of and leverage.
Dave Anderson
The future-facing element isn’t that we knew this tool would be built. But we knew what tools not to build.
4. Serverless
The fourth example is serverless. It’s probably an obvious one. As we mapped out the stack, and Simon mapped out it a long time ago, you could see some of the things that weren’t going to last. Some of the platforms were interesting and cool, but we knew they were going to go away again. It was about being high up in the compute value chain. And that was a map that was drawn for us, I would say,
Mark McCann
As early adopters, there were pain points for our teams. But we had the map beside us so we knew to you say, let’s just wait. Let’s wait until that pain point is solved for us by the ecosystem or the cloud provider. We could have gone off and custom-built something. Or we could have gone down a non-serverless route. But we decided to take that hit for now and wait until the system evolved. And served up that quota limit and remove the frustration. We decided to take a look at the map and take a step back. And wait for the ecosystem.
Influence the change that’s needed
With future-facing stuff, you can influence it. You can reach out to your partners to say: ‘Hey, we’ve got this pain point. So you can start to actually help evolve some of the components by having a conversation about the pain point. And that you are trying to evolve this thing so what is the direction?
Dave Anderson
It’s not like AWS would reveal what they are building. So hold tight. They don’t tell you. You hear about it when you are sitting at AWS re:Invent. They are very good at keeping secrets. And quite rightfully not leaking products, which would never happen.
Michael O’Reilly
The Serverless Map is quite interesting. Even looking at it today, at an industrial level, there’s still a lot of evolution taking place. Across the board, there is a moderate adoption of Serverless.
Dave Anderson
The concept stays the same, but the services are evolving.
Michael O’Reilly
At the micro and org level, it’s there and it is real. At an industry level, it’s still very much evolving, which is interesting.
5. CDK (Cloud Development Kit)
Dave Anderson
The last quick example is CDK (Cloud Development Kit). We knew CloudFormation was a pain. We could see there was a need for a higher-order pattern. And we map it out to show there would be higher-order building blocks. And when that came out, we jumped in immediately, because we were kind of waiting for it. We knew something like that was coming So when it arrived we were ready to throw the kitchen sink at it.
Mark McCann
Absolutely. Because you have good situational awareness. You can wait until the appropriate time. You don’t have to go off and waste energy, cycles and money trying custom build something. Wait three months and you’ll get what you’re trying to achieve.
Dave Anderson
That had a very soft launch as well. There wasn’t a fanfare at re: Invent. I think it came out in June.
Sensing change
Mark McCann
I think when you map this stuff out, you can start to think about how your sensing engine can get intel on whether these things are going to happen or not. There are lots of different ways you can do that. Like following Twitter feeds and looking at blogs. And looking at who they’re hiring and following the industry experts. They’re points of information that can help you see how things will evolve. To predict the way things are going to go. There are multiple levels of maturity in your map and how you think it’s going move and where the evolution is going to happen.
Dave Anderson
So we’ll continue the series. To sum up, you can use Wardley mapping to predict the future but it’s not going to give you an exact date. What it can do is give you an example of what it will look like if it happens. So you prepare yourself for when it does. And then when the press release comes out, you’re like, boom, we’re ready. We saw that coming. So it’s the no ‘surprise approach’ to building situational awareness.
That’s the craic. We’ll continue to chat next time around. Have a look at the blog on TheServerlessEdge.com. And follow and like us on Twitter @ServerlessEdge and on YouTube. And don’t forget to check out our book: The Value Flywheel Effect. Thanks very much, everyone.
Transcribed by https://otter.ai
1 thought on “Can Wardley Maps predict the future?”