Map Camp is series of events including workshops and talks about Wardley mapping techniques. It’s a community event driven by real practitioners.
Last year the title of our Map Camp talk was ‘Adaptation – the Value Flywheel’. We look at Wardley Mapping as a concept. And we apply the concept to the Value Flywheel. This shows Wardley Mapping working in the practical implementation of ongoing technical strategy.
.
Adaptation and the Value Flywheel at Map Camp
.
Wardley mapping at Map Camp
Simon Wardley and the Wardley mapping community have an excellent annual event called Map Camp. It is always an interesting day, with lots of really good feedback on Twitter, etc. Last year we were part of the resilience track. And the title of our session was ‘Adaptation’. I decided to live map our Adaptation using the Value Flywheel idea from our book.
Simon Wardley
Maps tend to be on the walls when you are in the office. People get around a whiteboard and talk about a problem like position movement and placement. And then you photograph the map on the whiteboard. And you take the photograph and then digitise it.
We have modernised our map sessions with the tools that are available. And the fact that we’re working from home more, means that collaboration sessions are digital. There are a lot of online tools available: Lucid Chart, Online Wardley Maps, and VS code.
Live Wardley Mapping
Adrian Cockroft was the first person I saw live mapping at Map Camp, last year. It’s getting more popular. And a lot of people are having an ‘aha’ moment. One challenges we had in the early was a tendency to go too formal too quickly. But now we know how to use the tool properly and how to keep the conversation going.
Mapping Tools
The mapping tool we used in our talk is on Twitter @mapsascode. It’s a language for doing maps and is the same engine behind Online Wardley maps. Damon Skelhorn wrote it and made it available on GitHub. There’s a nice plugin for Visual Studio Code, which works really well.
But if you don’t want to do that and not everyone wants to install an ‘ide’, you can go to onlinewardleymaps.com and play about. Initially we thought it was too formal, But now I think it works well. Plus, you can give someone the code to play with themselves, which is good.
We used it well in this talk by uncommenting as we went. And using it to illustrate the narrative and our content.
Mapping the Evolution of Cloud up to Serverless
It’s worth looking at the map that is used for Wardley Mapping at Map Camp. It 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 at least five years old.
Simon Wardley’s Map showing the evolution of compute to cloud
For anyone who doesn’t know about Wardley Maps the anchor is at the top represents 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
Simon talks about Compute evolving to Cloud. And the propensity of DevOps to move to the right. Along with good architecture practice, operating systems and run time. He identifies that run time is an inertia point for moving to Serverless. And a second inertia point going to Cloud.
Once serverless happens, it opens up something called emerging practice. Which in turn 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. When Simon draws this map, he often will change what this need is. And there are a couple of different needs he puts in here. But it’s about the pattern of and the fact that Serverless unlocks it.
Serverless and emerging practices
We have seen this unlocking happen. As we’ve been able to navigate through the same inertia barrier in the work we’ve been doing with Serverless. And we have witnessed it opening up emerging practices. It has improved our time to value and our speed. And it has allowed us to think differently about what is new emerging value and what is new need. And we can go and address that as an organisation, business, or individually. So we have lived this map, effectively over the past six or seven years.
We have work with many good engineers who are stuck at this inertia barrie. And people can spend their entire career being stuck on that inertia barrier. And still have a successful career. But you spend an awful lot of time trying to get over or burst through that wall and sometimes it doesn’t happen.
The title of this was ‘Serverless 2030’. These things take time because there’s lots of inertia to change. There’s lots of traditional practices and techniques. And there’s lots of value in them as well. So it’s not like they can go serverless overnight. There’s an evolutionary journey that people, teams and organisations need to go on to grasp the value in the top left corner of the map.
‘Adaptation: The Serverless Edge and The Value Flywheel’
The reason I think this is interesting and valuable is because this is a higher level technical strategy. Your technical strategy isn’t, ‘let’s move to Lambda’. It’s up the value chain looking at how to reduce operational load, move faster and unlock new needs. So you need a higher lens that is closer to your business.
That probably brings us nicely onto our map. 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 if you have the time.
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. They become prisoners to their past success.
We anchored our 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 we have things here, like operational efficiency, time to value and business growth And 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. to be able to build quicker. We need better data and 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. Towards the bottom of the map, the enabler for all of this is Wardley mapping. Or the idea of challenging to make sure there’s movement. And that is the concept of the Value Flywheel. 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 long term value. Which then creates space for further innovation up at the top of the map.
Underpinning it all is having an 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 the key elements 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 throughput, 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 where you’re worried about making a change. Or something’s brittle and you are left wondering about being able to assess the impact of what you are doing.
When you get everybody on this on a level playing field, there’s an equilibrium of expectation in terms of standards. We talk a lot about well architected. And you could argue that it’s a commoditized set of best practices that get everybody can get 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.
The role of a Technical Lead
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 in your remit to do that.
But people react by saying: ‘why are we doing this, it’s not in my objectives!’ And we show them that we need to do this because it is going to make everything else easier. The hard battle is getting something like this kicked off. As a Technical Lead, sometimes you have to plant the flag and say, ‘no, we’re doing this!’. But then, in a while 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 from articulating the things we’re trying to do for problem prevention and long term value. It’s about selling it to the right levels in the right way. And getting the buy in from the teams on the ground. As well as getting the pitch right for the execs and trying to do that across all the different floors of the elevator.
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 and your innovation and thinking. You start to move those things to the right eg. cloud self service. And serverless first brings a lot of these things across. You free up space for enabling capability and whatever’s next.
Serverless First Mindset
Serverless First is using a serverless first mindset to move things quickly from the next best action into the long term value zone. There’s some older architectures where you could take a year to move stuff. But you can do it faster with serverless.
Alot 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
The enabling capabilities and building blocks that allow you go after the next thing and that value, are critical. And you can 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. It could be a security issue, a cost overrun, a quality issue or a slowdown in your time to value.
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 a knock on effect. Because people haven’t drawn out this type of strategy here and given engineers room to practice well architected techniques.
Observability and visibility
The big gains from evolving product to commodity are observability and visibility. How many times, in the past, have third party consultants come in to quantify your technical debt and recommend investing in an IT resource to move platform. When in actual fact you know the correct thing to do is tie technical debt or legacy to actual value.
If a system is down for half an hour a month, is it really worth investing time to correct these issues? Or should you invest that time in modernising and moving it. And bring it in line with future state to get ourselves more capability?
You need to start quantifying the value in the system, the ROI, the performance and how long does it takes to make a change. Do you have people that can change that system? And factor in developer experience and happiness.
Serverless isn’t easier, but it is better
As AWS Hero Gillian McCann 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 sustainable, rewarding and a more impactful way of going about your day.
We have written blog post on ‘finding your why‘. A lot of our teams 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.
When we started mapping our teams and tech stack, the first question we ask 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, on why they thought 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. A lot of our thoughts and what we’re talking will be generously shared on those channels. And The Value Flywheel Effect book with IT Revolution is due out 29 November. So subscribe to our Serverless Craic YouTube channel or follow us on Twitter as it’s probably the best place where we’ll put everything out.
Top comments (0)