Serverless Craic Ep44 Can Wardley Maps predict the future?

Can Wardley Maps predict the future, is our topic this week.

In our last episode, we talked about Wardley Mapping. We did a 101 last time, explaining the basics.

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 the state of mind that it puts you in. We run through a couple of examples, to demonstrate how we've done it in the past.

1. Conversational Programming
2. Generative AI
3. Well-Architected
4. Serverless
5. CDK (Cloud Development Kit)

If 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.

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.

Wardley Mapping can be used 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 this is 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. 

Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube

Transcript

Dave Anderson: 0:05

Hi folks. Welcome to the next edition of Serverless Craic with Dave Anderson, Author and Contributor at The Serverless Edge and Architect at G-P.

Mark McCann: 0:13

Mark McCann, Author and Contributor at The Serverless Edge and Architect at G-P.

Michael O'Reilly: 0:18

Mike O'Reilly, Software Architect with G-P, and Contributor at The Serverless Edge.

Dave Anderson: 0:26

In our last episode, we talked about Wardley Mapping. And we decided to do a few sessions. We did a 101 last time, explaining the basics. 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 eg. in September. It's the state of mind that it puts you in. We'll run through a couple examples, to demonstrate how we've done it in the past, I can where we can run through a few examples. What do you think about the

statement: 1:11

'Wardley Mapping helps you predict the future?'.

Mark McCann: 1:15

I think it's fairly accurate. It's something we've seen time and again. It's not like reading the runes, or gazing on a crystal ball, you just have better situational awareness. So you can make reasonsed 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: 2:00

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. 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 you find yourself in those conversations, which are really useful.

Dave Anderson: 3:21

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 when this thing happens, how will our strategy be affected? Every year at AWS re:Invent, AWS make a new annoucement and you hear of a company going out of business. You don't want to be in that situation. Our first examples is conversational programming. Simon Wardkey did a map about eight or nine years ago, on conversational programming. Where 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: 4:16

'Build me a website' and boom it pops out. And Iooking 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 sawthat map years ago.

Mark McCann: 4:48

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? 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 you testing practices in good shape? Do you understand the needs of your users and the value of what you're trying to accomplish? So 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: 5:55

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: 6:15

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 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 yourself further up the value chain. You could think about adding value to code. Or focusing more on the business and if the product is having an impact. In other words, let me produce something

Dave Anderson: 7:23

One of the things that Simon Wardley is brilliant that has value and work on the next higher order capability. Conversational programming has moved on the map. Now there will 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 be code liabilities generated. We often say codes is a thinking about the cost of building early. And now that has become an important FinOps practice for cost optimization. liability. So who's going to manage those liabilities, if you So it's about the ability to use mapping to challenge thinking, and push ahead to the future. are producing lot of generator code? How do you how do you manage and cope with that? So there are new emerging needs coming out of that evolution. 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: 8:58

'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 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: 10:01

I remember those conversations, I think the focus on ML Ops and the Well Architected, Machine Learning Analytics lens focused us on 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.

Dave Anderson: 10:31

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: 10:42

I remember we did a map, a number of years back, and having a very similar conversation. There was a lot of uncertainty around 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, but 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: 11:25

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 it to a larger LM.

Michael O'Reilly: 11:46

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.

Dave Anderson: 11:55

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 Early on, we were aware that you don't custom build your own 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 cloud guidance framework. And fall into the trap of thinking lose the updates from AWS. And if we tried to write some wacky that we know better than 1000s of validated and proven use tool oursevles someone else will write one and that would be wasted effort. So that was a was a good map. cases from multiple customers. We knew it we didn't know.

Mark McCann: 13:37

With that map, we predicted some of the future movement. 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 have and that 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.

Michael O'Reilly: 14:32

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 efficienct 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: 15:12

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: 15:28

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: 15:46

The future facing element isn't that we knew this tool would be built. But we knew what tools not to build. 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: 16:20

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 paipoint 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 an non serverless route. But we decided to take that hit for now and wait until the system evolves. And serves up that quota limit or that thing that was frustrating. Let's take a look at the map, and let's take a step back. And wait for the ecosystem. With future facing stuff, you can influence it. You can reach out to your partners to say: 'Hey, we've got this painpoint'. 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: 17:19

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 happened.

Michael O'Reilly: 17:38

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 Serverelss.

Dave Anderson: 17:53

The concept stays the same, but the services are evolving.

Michael O'Reilly: 17:57

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.

Dave Anderson: 18:14

The last quick example is CDK (Cloud Development Kit). We knew CloudFormation was a pain. And 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: 18:46

Absolutely. Because you have good situational awareness. You can wait at 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: 19:03

That had a very soft launch as well. There

wasn't a fanfare at re: 19:06

Invent. I think it came out in June.

Mark McCann: 19:09

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's 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 are going to evolve. To predict your 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: 19:49

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 this is what it will look like 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 good situational awareness. That's the craic. We'll continue to chat next time around. Have a look at the blog on the TheServerlessEdge.com. And follow and like us on Twitter@ServerlessEdge and on YouTube. Thanks very much.