We discuss our ‘Adaptation – the Value Flywheel’ talk at Map Camp. And we look at Wardley Mapping as a concept and review an example that Simon Wardley uses. We apply the concept to the Value Flywheel. This shows Wardley Mapping working in the practical implementation of ongoing technical strategy.
Wardley mapping at Map Camp
We are talking about Wardley Mapping at Map Camp. Simon Wardley and the Wardley mapping community have an event called Map Camp. And I presented a talk. It was an interesting day, with lots of really good feedback on Twitter, etc. I was part of the resilience track. And the title of our session was ‘Adaptation’. I mapped the Value Flywheel. But in a moment of complete ‘stupidity’ I decided to live map our Adaptation using the Value Flywheel idea from our book.
Yeah, it definitely resonated. I saw lots of people taking pictures and sharing it. So it was good.
I thought it was a bit of a masterstroke in relation to the mapping but, because I think when you’re in the office, all the maps are on the walls, aren’t they? You’re normally getting people around a whiteboard, and you’re talking about a problem like position movement and placement. And then you’ve got the photograph. And you take the photograph and then digitise it.
Whereas with tooling and the fact that we’re at home, the collaboration sessions are digital. How many people were leveraging something like VS code for mapping? It doesn’t seem like there’s a lot of people that do it. I know, there’s a lot of online tools: Lucid Chart, online Wardley map, and VS code. But certainly, from sort of the feedback I’m seeing is a lot of people were: ‘Oh, okay, that kind of accelerated that process’. Or, you know, you modernised it slightly.
Live Wardley mapping
I think the first time I saw somebody live mapping was Adrian Cockcroft, last year at Map Camp. I think it’s definitely more popular. But I think a lot of people are having that ‘Aha’ moment, ‘that’s really interesting’ and ‘that’s a really good technique’. And I think one of the challenges we had early days when we were talking or using it was a tendency to go too formal too quickly.
But I think now we know how to use the tool properly and we know how to keep the conversation going. It’s not getting in the way as much as something like Mira or Lucid Chart when it was more informal and you could drag stickies around and stuff.
Yeah, definitely. I mean, if anyone is interested in that tool, its Twitter handle is @mapsascode. It’s like a little language for doing your maps. It’s the same engine behind online Wardley maps. There is a guy called Damon Skelhorn, who wrote it and it’s available on GitHub. But there’s a nice plugin for Visual Studio Code, which works really well. But if you don’t want to do that (not everyone wants to install an ‘ide’) you can go to onlinewardleymaps.com and just go and play about with it. Initially we thought was too formal, but I think it works well. Plus, you can give someone the code and they can play with themselves which is good.
And the way you’ve used it in this talk was brilliant by uncommenting as you went and using it to really illustrate the narrative and illustrate your content.
Mapping the Evolution of Cloud up to Serverless
It’s probably worth showing the map itself that is used for Wardley Mapping at Map Camp. There was an original map which was this one here, which is probably worth touching on first. This isn’t my map. This is one of Simon (Wardley’s) maps. Simon has been using this map for a long time to talk about the evolution of Cloud up onto Serverless. It’s kind of, I think, what do you reckon Mark, this is at least five years old. I’ll just talk through this really quickly.
For anyone who doesn’t know about Wardley Maps the anchors is at the top with the user. Then you have these four phases: Genesis, which is brand new, Custom Built, you can build something but you aren’t quite sure how to replicate it, Product, you are getting good at building it, and it’s ready for prime time, and then Commodity, which is just the price of doing business.
Wardley Map Inertia Points
So he talks about Compute moving over to Cloud. And then there’s the propensity with DevOps, which will start to move to the right, this is good architecture practice, the operating system, and then the run time. So he is saying, there’s an inertia point here at the run time going to Serverless. A second inertia point going to Cloud.
Once that happens over in serverless, that opens up something called emerging practice, which opens up new need, or new value for the user. And often the user doesn’t really know that they need this until it appears. There’s a little pattern to this map, that has been used quite a few times. So when Simon draws this map, he often will change what this need is, there’s a couple of different needs he puts in here. But the pattern of this, and the fact that Serverless unlocks it because you don’t need to worry about a lot of the stuff down here.
Just clarifying on the on the inertia point, when you look at this map, you’re saying that five years ago run times were slowing down the adoption of these emerging practices. We are starting to see the effect on the industry of moving fast, reducing undifferentiated heavy lifting, and removing time to market blocks.
Serverless and emerging practices
We have seen this as we’ve been able to navigate through that inertia barrier in the work we’ve been doing especially with Serverless. And witnessed that it has opened up emerging practices, it has improved our time to value and our speed. It has allowed us to think differently about what is the new emerging value, what is the new need, that we can go and address as an organisation, as a business, or even individually. So we have lived this map, effectively over the past six or seven years.
And worked with many, very good engineers who are still stuck at this inertia barrier down here. And, you know, people may spend their entire career being stuck on that inertia barrier and still have a successful career. But you spend an awful lot of time just trying to get over and burst through that wall and sometimes it doesn’t happen.
You can see that the title of this was ‘Serverless 2030’. These things take time, and there’s lots of inertia to change. There’s lots of legs and traditional practices and techniques. And there’s lots of value in them as well. So it’s not like overnight they can go serverless there’s an evolutionary journey that the people, teams and organisations need to go on to be able to grasp the value in the top left corner here,
‘Adaptation: The Serverless Edge and The Value Flywheel’
The reason why I think this is interesting and why it was so valuable for us is that this is a higher level technical strategy. Your technical strategy isn’t, ‘let’s move to Lambda’. It’s right up the value chain looking at how we can reduce operational load, to move faster, so we can unlock those new needs. So you have a higher lens that is closer to your business.
That probably brings us nicely into the map itself. This is a snapshot of the map I used for Map Camp. The title of the track was ‘Adaptation: The Serverless Edge and The Value Flywheel‘. The video itself is worth watching. But I’ll give a quick two minutes.
Innovate, Leverage, Commoditize Cycle
The whole idea is based on an: Innovate, Leverage, Commoditize Cycle. And the thing you often see happening is that companies will innovate, they will leverage value, but never get to commoditize. Which leaves you kind of locked. And that’s when you get into technical debt. We can’t go fast, yada, yada, yada.
They become prisoners to their past success.
We anchored this map with a senior executive, like a CEO. This is pattern we have seen many times. There’s a layer across the top here, which is ‘clarity of purpose’ and things that we have here, like operational efficiency, time to value and business growth, have needs around cost management, digital modernization, customer need and even secure rapid experimentation. These are things that might be top of mind for the CEO.
This layer here belongs to the IT Department or Technology Leaders: if we need those things then we need Self Service Cloud, be able to build quicker, we need better data, we need better security. These are things that you need to do in direct response.
Problem Prevention Mindset
But really, what we’ve experienced is another layer, which is your problem prevention mindset. Things like well architected engineering excellence, standardisation, sustainability. They’re the real things that no one asks for. But they actually enable a lot.
For example commoditize can affect your long term value. And then towards the bottom here, the enabler for all of this is the idea of Wardley mapping (at Map Camp), is the idea of challenging to make sure there’s movement. And really, the concept of the Value Flywheel is that there’s clarity of purpose first. You challenge through your map, you figure out your next best action, which is your leverage, and then you move things over into this long term value. Which then creates space for further innovation up at the top there.
Underpinning it all is that environment for success. That’s very important. Psychological safety is a big thing that enables this to happen. It’s very hard to challenge if you’re going to get shouted out every time you raise a question. That’s the reason why environment for success is one of those key elements there that underpins the entire Value Flywheel.
Equilibrium of expectation
The commoditize piece is an interesting one to get into. I always think of this one as a scaling thing. As you’re moving with speed, and producing more and more throughput, and you carry that over the longer term.
But then you’ve got to think about the fact that teams move, and your developers move and leaders move. But as they move, you should be able to go from one workload to another, and it should be reasonably consistent. You shouldn’t find something that’s not in a good state, or you’re worried about making a change, or something’s brittle or you are wondering about being able to assess the impact of what I’m doing right now?
And I think, when you get everybody on this on a level playing field, there’s an equilibrium of expectation in terms of standards. You know, we talk a lot about well architected and you could argue that it’s a commoditized set of best practices that get everybody aligned to. If you get everybody working to that standard, you should be able to move at speed and create the foundation for things like SRE etc.
I certainly see where you went with that map. It definitely has a nice balance to it, in relation to moving responsibly and with a degree of rigour and discipline.
It’s not a stick to beat teams with around problem prevention. It’s about enabling and empowering them and taking them on a collaborative journey.
The role of a Technical Lead
The three of us worked together for 15 years. For me the commoditize box is interesting because I can’t think of a time when we didn’t have some mad idea of bringing in something like threat modelling, whole team testing or some cloud strategy, like sustainability. As a technical leader it is your remit to do that.
But people say: ‘why are we doing this, it’s not my objectives?’ We need to do this because this is going to make everything else easier. And always the hard battle is to get something like this kicked off. As a Technical Lead, sometimes you have to just plant the flag and say, ‘no, we’re doing this!’. But then, a while in when people start to see the benefit as it lifts a lot of cognitive load.
As a Technical Lead, it’s your job to assess when the organisation is ready for that change. Because if you push something when people aren’t ready, it’s difficult. The trick is knowing when to push those things and connect them to the the executive vision.
Architect Elevator Approach
We love Gregor Hohpe’s ‘Architect Elevator’ approach. We have a lot of scar tissue around how to articulate the things we’re trying to do around problem prevention and long term value. It’s about but selling it to the right levels in the right way. Getting the buy in from the teams on the ground. Getting the right pitch for the execs as well and trying to do that across all the different floors of the elevator architect is fun.
But what it effectively does is drag a lot of this stuff over to ‘commoditized long term value’ and frees up that space for your next thing, your innovation and thinking. I think you have that next on the map, Dave.
When you start to move those things to the right eg. cloud self service. Even serverless first brings a lot of these things across to the right. You free up space for enabling capability and whatever’s next.
Serverless First Mindset
A lot of people were watching the mapping video. And they didn’t realise that what this is, is really Serverless First, because you’re using that serverless first mindset to move things from the next best action into the long term value zone, because you’re able to move things quickly. There’s some older architectures that could take a year to move stuff but you can do it faster with serverless.
I think there was a lot of discussion as a lot of people still think serverless is lambda. Serverless is a terrible name. But there’s a phrase needed to describe a modern way of building software in the Cloud. I don’t think it’s been coined yet. But it really lends itself well to that problem prevention mindset.
The importance of enabling capabilities and building blocks
It’s all the enabling capabilities and building blocks that allow you to go after the next thing and go after that value that is critical. And you can probably get by for a while not doing that. But sooner or later, it’ll catch up. And it’ll catch up in a big way, you know, a security issue or a massive cost overrun, or, you know, some quality issue or just a slowdown in your time to value. We wanted to invest this a lot, so that our teams could go fast and our teams could have a good environment to work in.
The three big ones that you see in the news are big security breach, massive cost, or reliability, ie. something falls over. And those rarely happen in isolation. They’re usually as a knock on effect, because people haven’t drawn out this type of strategy here and given engineers room to practice well architected techniques.
What you can see as companies move away from traditional modes of architecture….
We are agile now so we don’t need architecture!
Observability and visibility
The big things through that evolution from product to commodity are observability and visibility of certain things. How many times, in the past, have seen third party consultants come in to quantify your technical debt and recommend investing in an IT resource to move from this platform to another platform. When in actual fact you know the correct thing to do would be to tie the technical debt or legacy system to actual value?
So, this thing’s down for half an hour a month? Is it really worth investing time to correct these issues? Or should we we invest that time in modernising and moving it into the next space to bring it in line with future state and get ourselves more capability?
You need to start quantifying certain things, like the value the system, the ROI, the performance, how long does it take you to make a change? Do you have the people that can change that system? People don’t factor in developer happiness. So all this stuff kind of factors in here.
Serverless isn’t easier, but it is better
Gillian, my wife says, serverless isn’t easier. But it’s better. It’s not easy to do this. It’s hard to do all this stuff. But it’s a better way of doing it. It’s a more sustainable, it’s a more rewarding and more more impactful way of going about your day.
In fact, I’ve written a blog post about ‘finding your why’. A lot of our teams don’t know and didn’t know how the thing that they were doing was going to impact the bottom line, the business or their team. They were just working on tickets!
If you don’t understand what your system is doing and how it’s actually adding value, you may come up with things like: ‘we need to move from spring to react and go single page apps into microservices’.
Understand your purpose
But if you don’t understand the why you don’t know if that’s a good decision or not? Should your time to be spent elsewhere? Is there a quicker path to what you are trying do? Serverless certainly gives you a platform for operating in that way and not making those sort of blind decisions.
Whenever we started mapping out of our all of our teams and mapping out your tech stack, the first question we will ask teams is: ‘what’s your purpose?’ Why does this team exist? Do you know? Do you care? And I was always fascinated to see the various answers from a team of 10 or 12 people, but why they think that team existed.
So that’s the craic! We have our blog on theserverlessedge.com, and we’re @ServerlessEdge on Twitter and The Serverless Edge on LinkedIn. So a lot of the thoughts and stuff we’re talking about we will reshare quite generously on those channels. And have a book about this stuff with IT Revolution due out in November. So subscribe to our channel or follow us on Twitter as it’s probably the best place where we’ll put everything out.