Join David Anderson in this insightful session from Prodacity as he delves into the transformational journey of adopting a serverless-first approach and the value flywheel effect. David, a seasoned software architect, shares his extensive experience and practical insights from working in large companies like Liberty Mutual and Globalization Partners.

‍

David Anderson (00:14):

This is my first Prodacity, so I'm really grateful to be here and I think it's an unbelievable community. I think some of the desire to change and the stories I think are brilliant. I've had so much learning today alone.

(00:24):

I'm going to talk to you about accelerating towards serverless first with the value flywheel effect. I'll explain some of the terms as we go through the conversation. My name's Dave Anderson. I'm a practicing software architect with a company called GP. And again, I'll explain that as we go, but first probably, let's hit the first terminology here.

(00:46):

Serverless. I hate the term serverless. It is an awful word for something. I mean, just to be very clear, there are lots of servers under the hood. It's not magic, but I often hear about the serverless first, and I'll get into this later on. The idea of serverless always brings the wrong questions. How do we do that?

(01:07):

It's the wrong question. The right question is when do we modernize? It's not should we or will we? It's when do we modernize? I've been saying this for many, many years. There's a wave of disruption coming that we're right kind of in the middle of around software development, and what that is is modernization. And the start of that wave was the move to cloud. For me. I'm new to the DOD and some of the government cloud - things that Bryon was talking about. But once you move to that cloud platform, you've already started working it in a different way and ultimately you will lead to modernization. And for me, the serverless mindset, which is really you rent before you buy, buy before you build, is what that is. And I'm going to talk about that today.

(01:54):

So something about myself...prior, I was in a CTO role with Liberty Mutual and I was located in Belfast and my journey started in 2013. I was at the table when there was me and maybe two or three other people as technical leaders for Liberty Mutual globally. We were at the table when we started speaking to AWS about the move to public cloud. The Liberty Mutual, as you well know, was a hundred plus year old company, very old, traditional established insurance company with the global presence. And for me, there was a couple of really, really key things that we started to put in place then. One is to have your cloud provider as a partner. And again, just to be clear, there was lots of other cloud providers that we worked with as well, including Google, Microsoft, et cetera. I'll not list them all, but have your cloud provider as a partner, not as a vendor. This is absolutely critical.

(02:47):

Two, serverless first. This mindset is code is a liability. The biggest thing that I realized back then is I can't have engineers building code all the time. They can't keep coding. We're going to build ourselves into trouble. How can we get at "code is a liability" mindset and offload work to the cloud provider? That was the big - how do we stop builders from building was huge change and mind shift change. But at the same time, when you actually build something, build it really well. No quick and dirty stuff. Build with really solid architectural standards and then give teams the autonomy, give them a clear purpose, and as Adrian Cockcroft says, "get out of their way." So that was a lot of the things that we started to put in place, and I started doing that in 2013. And I call this the second transformation, which is the modernization.

(03:34):

I did write a case study on this with AWS that's published there. If you just Google Liberty Mutual AWS, there's a whole bunch of stuff about that journey. And I was super privileged and proud to drive that journey. When we started that I had no idea it would be serverless first. We just wanted to find a better way to build software and this is what we discovered. I currently work for a company called GP, Globalization Partners. Well, what does GP do? It's a HR company or HR tech. It's called an employer of record. Basically there's almost 200 entities across the world. If you want to hire someone in any other country, GP makes that happen through contracts, payment benefits, et cetera. So it's really a way to accelerate globalization. And we have a SaaS platform that we're building completely serverless first.

(04:24):

We've actually defined a brand new category in business called Global Growth Technology. This is companies and organizations who want to grow globally using technology. See, the GP are market leaders, but really what I find is super interesting is we're building a well-architected, serverless first, event-driven SaaS. That's absolutely a business accelerator and I want to talk about that more as we go on. But that's just some context on what I'm currently doing.

(04:51):

What brings me here is, after I did that probably nine years with Liberty Mutual, driving that modernization journey, I decided to capture the handbook. One of the forwards there, Adrian Cockcroft, when I moved on from Liberty, he said, you got to write a book. You have to capture what you did. I haven't seen anyone else drive a modernization story like you did, so please write a book. So, I did, with my two co-authors who were also architects that worked along with me. And I also had Simon Wardley who - I'll talk about Wardley Mapping - which is the technique we used - also wrote a forward. And this was published with Gene Kim's IT Revolution. So for me, this is really the handbook of how we drove - how we turned Liberty Mutual into a serverless first enterprise, which believe you me, wasn't easy. There were lots of hazards and rabbit holes, but it was a good journey.

(05:46):

So is there any party who's familiar with Wardley Mapping? A couple? Cool, good stuff.

(05:53):

So I kind of want to talk through...this is a Wardley Map. I probably discovered this technique I'd say in about 2013, 2014. And this was the secret sauce to what myself and the architects did. This is how we figured out what to do, and I'll just explain the structure of it. It's basically a value chain, where your customer...your anchor, is the top node, and this is like a value chain as it depends on. So your executive stakeholder wants time to value; time to value depends on clarity of purpose. Clarity of purpose depends on environment for success, and so on. The things at the top are more visible. The things at the bottom are less visible. As technologists, usually the things at the bottom are more difficult, but they're usually hidden from the top.

(06:39):

And what's really interesting is this evolutionary axis from left to right. So every single component, be it a capability, a technology, will evolve from left to right. So I'll talk through the states. The very left is Genesis. If something's in Genesis, it's like "we don't know what this is. It's magic. I've never seen it before. This is incredible. This has blown my mind." Eventually they move to custom, which we now understand a little bit of this, we can build it, but we're not very good at it yet. And the customer, they don't really know they need it yet. When something moves on to product, it's now a customer need. Customers will ask for this thing. We're starting to get better at it. Then eventually things move into commodity where this is just the cost of doing business. A great example is compute. If you think of how computers evolved - like they're magic.

(07:30):

There used to be photographs in newspapers of the bank and the computer saying, this is front page news. The bank just got a brand new computer and it was wheeled in on a truck. Then to move to custom where maybe in the seventies, we've got different components to different companies. We built our own sort of custom computer. Then products probably like the PC era where they're going thick and fast and now we're in the kind of commodity where you just spin up a VM in the cloud, you don't even think about it. You don't even care which provider it is. So what we're going to talk through in this talk is moving these things from left to right. How do we evolve these capabilities, and what's the pattern?

(08:07):

So for me, this is the kind of modernization journey. And I'll just talk to some attributes for me that describe modernization.

(08:16):

So again, it's a fluffy term, but for me, "teams," and I'll talk about teams through this presentation, the whole, because I think it's teams focused, it's not individuals. Teams can deliver on demand. Teams can evolve technology quickly. New generative AI comes out like ChatGPT, the team can pull that in really quickly and use it. The teams think about commercial responsibility. They think about how can we grow the organization, not bottom line, how can we save money? It's IT as generating revenue, not cutting costs.

(08:46):

High quality standards: there's a laser focus on high quality standards and independent teams, the teams can move by themself. For me, that's modernization. I don't really care about serverless, DevOps, Cloud...they all point to the same principles. I'm very agnostic in how you do this, but the outcomes are really important. And platform due diligence is really important. As we talked about today, platform engineering is absolutely crucial and we will get into that as we go through the talk.

(09:17):

So for me, the framework that I use through Liberty Mutual and also applying now in GP, is the Value Flywheel, which is what the book is based on, the Value Flywheel Effect. And for me, a couple of things here...it's really about joining business technology strategy. How do you make a single strategy, accelerate, and move forward?

(09:35):

There's a couple of phases here. Clarity of purpose, find your North Star. It's really important that teams know what the North Star is. Two, challenge. you want challenge to appear in the teams. People shouldn't be afraid to ask why something is needed. That's psychological safety. Create that environment for success. Three, next best action. What can we do today that will move this forward? We don't want to get into analysis paralysis. How can we work in code and XP? What can we do right now?

(10:02):

And then four, long-term value.

(10:04):

What can we do to build in a sustainable way? No quick fixes. How can we have a problem prevention mindset? Let's prevent problems from happening before they occur. And that is a flywheel and purpose.

(10:15):

Once you start to move through this, you get better at it. You go faster and faster. One of the things we talk about is slow is smooth, smooth is fast. Practice these things, and then that's where you start to get your momentum. It's a flywheel because what you want to get rid of is inertia. What's going to slow this down? And I often hear this described as a rocket ship. Once you start working in this way, you don't stop. You continue getting faster and faster. And for me, the technique Wardley Mapping, that's what I used to create perspective to figure out what do we need to do next?

(10:45):

And again, I thought it was great talk by Nathen [Harvey] earlier. There's a super quote here by Nicole Forsgren from Accelerate: "Whatever the mission, how a technology organization performs, can predict overall organization performance." I remember literally waiting on the publication of this book because I was following the work from Nicole, Jez [Humble], and Gene [Kim]. When I finally got the book in my hands and I read this, I almost shouted. I thought this is exactly what I need to share with my stakeholders. IT is not just the call center. It drives the success of this company. And for me, that happens across all organizations.

(11:22):

And again, it's not about the technology, the specific things. It's about having a map. Do your teams know where they're going? Does your leadership know where it's going? Does your technical strategy point to something, or are you just jumping on the bandwagon? For me, it's about being deliberate in how you work.

(11:39):

I want to work through some of what I call mechanisms from the book - from this framework. So the first one, for me, in order to achieve good clarity of purpose, we use a thing called the North Star mechanism. So North Star is really about...it's not just about building, it's about creating a business capability. How do you create capability in what you're doing? For me and what I'm starting to see in GP at the minute, teams own the workload, soup to nuts, complete ownership of the workload. They know what their business KPI is as well as their non-functional KPIs. And that's a single vision. And we actually create domains in a domain driven way to be very clear what that separation is. The North Star framework is something I found hugely valuable. This is from a company called Amplitude. This came out probably around six years ago. It's a little bit like impact mapping. If you've seen impact mapping, there's a couple of really important concepts in here.

(12:38):

Number one here, the North Star magic. I'd often ask a team, what's your North Star metric? And you'd say something like, "oh, speed to market." No, no, no. "Oh, we want to have five nines." No, no, that's not your North Star metric. Or what are you here to do? And often teams don't know. So usually this workshop helps them identify that. Once you have a North Star metric, you can then look at your mid to long-term impacts...where will that lead us to? And then you can reverse that back into what are the input metrics? What are the things we do today, that can drive the North Star metric? And then finally, how does the work drive these input metrics? What you'll see here, a lot of the strategic KPIs the teams have, are often lagging metrics. And really what you're working to do is, ask a team, "do you know what your lagging metric is, and what are the lead metrics that we can use to feed into that?"

(13:30):

It's a brilliant exercise. And I would sit and do this with the actual development team. And it's really interesting going through that. They almost always at the start, don't want to do it. This is like, why do we have to do this? But you're ending up and they have a really clear definition of what they're here to do. And often one of the things I hear people say, well, would the business do that? And for me, that's one of the phrases that I really dislike because if people say, well ask the business, it's really not taking ownership of what you're trying to do. So I'd love to just ban that term completely. Say let's not talk about the business anymore.

(14:05):

And again, there's a really nice story. As an aside, this is one of the case studies in the book, it's company called Cloud Guru who later were acquired by Pluralsight. If you've ever done any cloud training, you've probably done a Cloud Guru. They started an online cloud training probably about nine years ago. As they started to become more successful, they started organizing this conference called, I think it was Serverlessconf. They had one in - they're based in...I think they're based out of Melbourne, Australia, and used to have Serverlessconf in New York, I think it was. And they're starting to build this community of modern cloud developers. And in 2017 they asked Simon Wardley to do a talk at their event. So Simon's a brilliant speaker; he's an English researcher. He came up with the Wardley Mapping Technique. He does his talk. And then they asked him afterwards in the speaker's room, "that's an interesting technique. I wonder, could we apply it to Cloud Guru?"

(15:03):

So literally, in the speaker's room on a piece of paper, he mapped out their entire business, and he pretty much said to them, "okay, your user is an engineer." And I'll not excuse the bad handwriting. This is the actual photograph. "Your user's an engineer, what do they need? There's a fear of not being left behind. Train your engineer. Everything else is just a distraction. Laser focus on training engineers and moving their ability from left to right, and what do you need to do to do that?" And he explained this idea of a flywheel effect, and they actually did this - after that conversation, probably a 15-minute conversation, they stopped a lot of their community building or dialed it down, and focused. And they sold that company for $2 billion, I think it was in 2019 I think it was. So they do go back to that. They say that was their kind of "aha moment" where they focused on their clarity of purpose. Again, I talk about it, and there's a full case study in the book about that.

(16:01):

Some of the things I hear from teams when I try to do a clarity of purpose and North Star is, teams often say we're product-led, ask the product manager, she'll tell you or he'll tell you. What product-led means is that the customer defines what we build, not the product manager. It's a very subtle difference; it doesn't mean you say, "well, we don't care about the customer." It means everyone cares about the customer. So that we often say to the teams, you need to understand your North Star if you're product-led. Another one is, "we don't have time." Well, building the wrong thing is super costly and expensive. I mean it's the measure twice, cut once. So if a team aren't clear what they're building, but they just want to build, it's time to stop them. Teams often say, "we just want to get started, let's go." I'm not saying that you can't build incrementally, but you don't have to do all your design upfront. You can build what you know and keep evolving, and do your North Star, which will set you right.

(16:59):

And one of the big ones is "the leadership is unclear." That's a real problem. If the leaders are unclear what you're building, then you have a bigger problem. Sometimes the team maybe don't understand the big picture, that's not great, but you can deal with that. But if the leadership are unclear on their expectations for the team, like the mission's not clear, that's a problem that you want to sort it straight away. So these are some of the things that I uncover by doing this kind of North Star exercise. Super valuable.

(17:27):

So the next mechanism, the move, the environment for success, is engineering excellence. I think this is a brilliant mechanism. So as we all know, remote work has completely changed the environment. The idea of going into the office, having a look around, all getting in the huddle, that's now completely changed with remote/ hybrid, it's completely changed. We build systems, but the system is not your code. The system is sociotechnical. What's equally as important is how the team functions, how the team interact with other teams, how they speak to maybe platform teams. So you need to think of the entire system, which is code and teams.

(18:06):

One of the things that I found being super valuable is create enabling constraints. How can we almost reduce the tool set of the team to help them move really fast? And one of the ways we've done this is through team topologies. Bryon mentioned this earlier. I think this is an unbelievable mechanism for structuring how your teams are organized. One of the questions I'd often ask a team, say a team or building a document system, and say, "okay, what's your goal?" "We're building a document system because that's part of our value stream." Brilliant. And then they'll say, "but we think this is kind of cool, so we want another team to use it because we're going to build a platform." Brilliant, okay, that's interesting. "That'll save us a lot of money, but we're going to help them because complicated." And then you say, "right, well you're now three types of teams. You're a streamlined team, you're enabling team, and you're a platform team. So you've now got three missions in this team, which is it?" So if you design your organization like this, your platform team can focus on building capabilities for your internal users. Your enabling team can focus on helping other teams. You got to be tough on teams to say, "just pick one type and be super clear on that - laser focus."

(19:16):

One of the things that we're - this is a GP example, but it applies anywhere - is each value stream has a bunch of domains. Each of these domains has got a specific business KPI, and the team own this mission. For me, this is just basic sort of event-driven or domain-driven design. But there's almost like the Conway's Law...bake your architecture into how you structure your teams. I don't want to say actually name your teams after the domain because teams like to make their own names up, but you know what I mean. But have very, very clear ownership of these domains. You don't want a domain owned by two teams because it never really works.

(19:52):

And an expectation for teams is you want to build high performing teams, so it's about getting right sized, decoupling, decentralize - have them pretty much as a cell, as responsible for everything they need. Very clear guardrails, that fast-loaded production, which means that they can deliver super fast. And again, that DevOps mindset, you build it, you own it, you run it. I mean, this is for some teams coming out of enterprise, this is tough because this is a very different way of working. But once you put the...it's very hard to have a team working like this on their own in an enterprise. But once the entire company changes this mindset, then you start seeing real fast flow.

(20:31):

So some of the things I've seen through engineer excellence is the idea of team first. Team first is tough. For me, a lot of leaders will think of individuals: "oh, Jimmy's a great developer, he's a 10x developer." No, think of the team. The team delivers software, not the individual. So I think it's really important to think in teams. Again, the vision, it's super important it's a clear vision for the organization and the teams have a part of that vision. Autonomy, which is one of the hardest ones, to have the team move really fast on their own. Sometimes that means you'll have to let them make some mistakes, but again, that's part of their autonomy. Let them learn. Focus on the learning and how the team learns. Previous speaker talked about the importance of retrospective. Retrospectives are absolutely critical and blameless postmortems. Let the team experiment, fail fast, and then figure out what went wrong and course correct.

(21:20):

Mastery. Encourage learning in the organization, whatever that means...conferences, training, un-conferences, even reading material, books, online training. Encourage teams to have pride in what they're doing, like good craftsmanship.

(21:35):

Business domains. Those domains that the teams are building, have them line up with the actual stakeholders in the organization. We should...in GP we have...the CEO talks about domains. Which for a non-technical CEO, talking about domain-driven design I think is incredible. But you want the executive in the company talking about the domains and be very clear, they are the business domains.

(21:59):

And then ways of working. You often see...I think there's a lot of bad practice around agile and product management. That's a whole different talk within itself. But we need to be super focused on helping teams address and sort of give feedback if there's bad ways of working that could be improved. There's a lot of dogmatic, agile, and product management practices that I think are getting in the way of teams.

(22:31):

So, the next mechanism we'll talk about is serverless first. This is probably the one that I think is pretty interesting. Again, it's that idea about rent, buy, and then build. So I talked a little bit about serverless being it's a bad term. For me, it's a complete mindset shift. I've spent probably the last 10 years trying to persuade software engineers that you don't have to code everything. It's a very difficult conversation. Some engineers will feel sort of almost defined by the fact that they write code. It's still important, but it's not always the right answer. For me, that's the mindset shift we talked about. I really like this diagram. Now, I talk about AWS because I'm most familiar with it, but it's the same for all the big cloud providers. Serverless is an operational construct. So if you look at this kind of spectrum, and the way I think of serverless first is as a strategy, on the left, we've got things that have more operations.

(23:38):

So this slide's a few years old, but I haven't been able to get an updated copy because things like for analytics, you've got Hadoop, messaging, you've got EBS on-prem, storage, maybe on-prem database, maybe MySQL on-prem. You get a VM on-prem. And if you look at the spectrum on the right hand side, you've got things with less operations. You've got things like Lambda, which is Function as a Service. You've got DynamoDB, S3, step functions. These are things that basically are an API. There's an entire team with the cloud provider that run these. So, there's no operations required on the right - there are very little operations. There's much more on the left. What I advise teams is, start on the left. One of the big learnings I had, doing this for years, was we would often start on the left and evolve to the right, evolve to serverless. So what we started to say to teams is start with Lambda and build your software in that way. If for some reason it doesn't work, there's some requirements that you just can't meet, fall back to something like Fargate, or ECS, or containers. So that's - serverless first means try the managed service first, and if for some reason it doesn't work, fall back gracefully, fall back to something that has maybe less operations or more operations. So really the goal here, it's not to use a service, it's to reduce operational burden.

(25:04):

So what this gives the teams, they're in more control. For me, this is the perfect definition of DevOps. The team are in total control of their platform, and they iterate and evolve rapidly because there's no handoffs. You've got scalability. I mean I have teams at the moment who came from enterprise Java and they're building event-driven, serverless workloads, and they can straight away, out of the box, handle thousands of transactions in like a minute or a second. So again, you get the scalability out of the box.

(25:37):

One thing that's difficult for teams is, you have to start thinking in events. So you think in an asynch manner as opposed to synchronous. That is a massive mind shift change. But again, that's where to get that scale. And again, it's about simplicity and agility. You want the teams to be very clear on what they're building.

(25:55):

Again, I mentioned event-driven. One of the things that's quite nice is, you can start asking teams to build single-purpose functions, build a function to do one thing, do it well. You can start isolating environments. What I currently have is entire teams have their own, maybe have their own AWS account for their own cloud account for their workload. Complete network isolation. Again, that's the modern account strategy. You can now start again the ephemeral infrastructure. One of the teams asked me a few weeks ago, we need a performance test environment. No, you don't. Spin up an environment, run your performance test, and bring it back down again. So there's no kind of ongoing support of your performance environment.

(26:36):

The whole idea of an internal developer portal, a backstage is not very popular, but again, there's a few alternatives. The idea of having a single pane of glass for your engineers with your scaffolding, your documents, all your policies in a single place. And again, using open telemetry for distributed tracing. Observability becomes a challenge in this environment. But the industry is starting to catch up with open telemetry. Again, very different way of working.

(27:00):

One of the things that things we started to talk about was the concept of unlearning. Again, with GP, I'm probably working with around 50 teams at the minute, and I would say the majority of those teams have come from enterprises. Whether you just had maybe either regular cloud or even on-prem, there's a lot of things you have to undo - ways of working. I actually find, interestingly, if you bring people new to the industry into this technology, they just pick it up straight away. If you're someone like myself who's old and around enterprise Java for years, you have to change how you think about things. Run locally is hard. It's hard to say to engineers, you can't run locally, you can't bring the cloud to your workstation. You just bring your practices to the cloud. That's a massive shift in how we think.

(27:48):

Testing and verification is different. The testing pyramid is almost turned into a testing kind of diamond. Behavior driven. When somebody finds a defect, the thing I look for in a team is they don't think, "here's a bug." They'll say, "which behavior did we miss that caused that bug? "It's a bit like a postmortem. When you blame this postmortem on something, it's not the action that caused the defect. It's what piece in the design - what behavior did we miss?And then follow that through. That's a very different way of thinking. And again, teams have full responsibility for the workload is a very different way of thinking. And again, embracing evolving architecture, very different ways of working.

(28:34):

So you can talk about team topologies...the way we're currently structured, I talk about...there's almost the line of shared responsibility.

(28:45):

So if you have a streamlined value team at the top, I talked about enabling constraints. So what I work with my teams now, there's pretty much four managed services I want you to use Lambda Dynamo, API Gateway and EventBridge. There's a few others, but that's your main building blocks, purposely restricted. It's not like the CNCF diagram, with like 600 technologies. It's a very small focus. That means the team can focus on their event design, their API design, and their domain design. What does this workload have to do? Not all the underlying tech. They can focus on business capability and that means they can own the workload, soup to nuts. So that's the streamlined team of likely around say five, six, seven people.

(29:33):

Where the fun starts, is the enablement teams. This is where I sit. So people like architecture, QA, cloud infrastructure, their enablement teams. So what I would do is help the teams become well architected, help the teams build that quality in.

(29:49):

We have software engineers and test advise the teams on how they verify. They don't verify for the team, they advise the team how they should verify. So you have a series of experts giving enablement. And then the platform team, for me, ideally that's a cloud provider. Someone else will do that. Someone else does compute, someone else does network. If you do need to have an internal team, they're building that capability, but you really want that outsourced or offloaded to the cloud provider if possible. For me, that's that shared responsibility. That means the cognitive load of the value team, the stream team, is quite low so they can focus on what they need to build. If you expect the team to do all of this at the same time, it's a huge...that leads the burnout in my experience. But this is different for software engineers. Dave Farley wrote this great book on modern software engineering, which I would highly recommend.

(30:41):

And for me, here are some of the characteristics I would think about for engineers. Engineers need to be experts in cloud principles. Whatever you decide for your platform, you really understand the first principles of cloud. And leaders also need to be very familiar with cloud principles. The idea of system design is now back in fashion. We need to think about event driven architecture. How do we design our systems? I want teams to think commercially: "how much is that costing? What value are you delivering? If we're going to spend so much building that, are we going to get that back in revenue?" It's almost like worth- based development or even finops, having engineers think about how much something costs to run, how much it costs to build, and how much it will generate. Very different for some enterprise developers, but again, you have to have that commercial conversation: "should we build this? Should we refactor this? Or is it good enough?" Be super smart with learning, teaming, and inter-teaming. What's that social technical map look like? Who do the team need to work with? I need it to be very mature. I mean, sorry to use a colloquialism, but I can't have developers throwing hissy fits because something's not working. We need to kind of get with the organization and kind of step up. And again, some of the principles, builders need to own it, rapid feedback loops, and that idea of modular, simple development. For me that's an efficient way to build.

(32:06):

That describes engineers with high agency and low barriers. For me that's very different with where even developers were 10 years ago. So they're probably thinking, well what do I do as an architect? Again, I'm an individual contributor or an architect. So what I tend to do is help teams with event storming, help them tease out their design, help them with North Star. We do North Stars usually on Miro or Lucid. We'll figure out...we'll go through that diagram I showed you earlier. Help out with the low-level event-driven stuff like bonded contexts, architectural patterns, and maybe even the example mapping - advise them how they should verify. These are all I would say, you're enabling the team. It's facilitation, helping the team find the right answers. They'd often say to me, "can you sign off on this?" Say "no, I'm not going to sign off on that. I'll give you feedback, but you own it." And I don't want people saying "the architect is a blocker." "No, no, your workload, but I can help you make it better, make it more resilient."

(33:07):

So some of the things that I find, and I would almost call this dogma, that when you build in a service first manner that next best action, the things that I see, it can slow us down slightly. I've heard people talk about the DevOps guy. DevOps is not a role or it's not a department. It's a way of working. If you think of team topologies, it's about that ownership. So there's nothing that I find more challenging then when someone says, "I'm a DevOps person, or this is the DevOps team." That's not what DevOps is.

(33:37):

"We need a platform." Yes you do, but don't feel you need to build it. Think about could you assemble that platform or could you create that platform from something else? What I'm seeing at the minute is teams getting very excited and they want to build stuff and say, "no, don't build that; there's a service that'll do that for you." Whatever that is, get people to think differently. Build capabilities over services. Services lock you in. Think about the capability you're providing and don't assume you have to build it.

(34:07):

This is a big one I talked about; code is king. I think certainly probably a few years ago I've seen a lot of executives saying that coding is the future. Everyone must code. Code is the answer. Success is not measured in code. And the mantra I've been saying for years is code is a liability. The system is the asset. The system is the thing we're creating. Code is just how we get there. The less code we write, the better. Every line of code has to be written, maintained, secured, verified, deployed - massive cost in a line of code. So if a developer says to me, "we've just written 10,000 lines of code," it's like...that's not good work. That's not being smart. That's just not thinking.

(34:51):

People often say the systems are complicated. "This system's so complicated" like it's a badge of honor. That's a failure of architecture. One of the things that architects - good architecture could do, it doesn't need to be the architect, it could even be engineers in your team, you should describe the system, have ubiquitous language that we talk about the system in a consistent way; we reduce risk, and make sure people understand the frame of reference. If a system is complicated, there's a failure somewhere. It means it's just not communicated correctly.

(35:20):

And this is one of my favorite ones that often people think engineers are lazy. Often engineers are overwhelmed because we've asked them to do so much of the stack, and we haven't told them why. It's like, I probably spent a lot of my time pushing back on leadership saying, "you're asking that team far too much and you haven't told them why. This is not a good way of working." So I think this is some of the things that, and again, this is probably more directed at leaders in traditional enterprise, but again, I think it's hopefully there's some good lessons. These are my observations from the field I would say.

(35:59):

So the next one is a problem prevention mindset. And for me, the mechanism here is the well architected mechanism. And this is probably my favorite one. No prizes for guessing why. So one of the things that we talk about in GP, and again even with Liberty, and I've seen this in many companies I work with, is the idea of continuous compliance. And I love some of the content this morning about the ATOs, et cetera. We're moving too fast for an annual audit report. I mean just as an aside, I spent...in Liberty when I was doing a lot of stuff around risk and audit, people would say, "well the auditor or the InfoSec will never let you do this." What you do is you work with those central functions, get behind the process, and understand the control, and let's eradicate the process so we can really have a really tight implementation of the control.

(36:54):

So we're moving too fast for an annual audit. So what I find is developers are able to deploy. If you think of DORA, if you have an elite team that are deploying on demand, you've no idea, you just don't have time. You've got to bake compliance in. So what you'll often find in cloud is you'll detect and auto remediate things. If there's an S3 bucket that's open, you just delete it as soon as you detect it. And so how can we be very proactive? And there is a wealth of information in, again, all cloud providers, but like AWS is what I'm more familiar with. There's no end of good practice where solution architects from the field are baking back in the heuristics that they find out into a central framework. And again, also, it reduces operational burden. People often ask me, "can you write an architecture strategy for this company?" It's like, just download one for free from your cloud provider.

(37:47):

There's a beautiful white paper. It's probably maybe the maturity of 10 years. It's all the good practice you'll ever see. Just use that. Don't burden your architects by asking to write architectural standards. Just download one. And if you need to tweak something, tweak it. But take the base reference from the experts, the combined knowledge of thousands of architects over maybe the last 10 years. Use that as your well-architected standard.

(38:12):

So again, for me, the AWS well-architected framework is what I use, and how I use this is in a process called SCORP. And SCORP again stands for security, cost, operations, reliability, performance. It's not very snazzy, but it was a lot easier to say than the well-architected framework. So this is the framework from AWS and there's five pillars here. Each of these pillars has several questions and each question is a bunch of best practices.

(38:48):

There's a very similar framework for Google, which is structured pretty much the same way. There's also one for Microsoft and they're all very similar, slightly different names, but it's all the same stuff. They're all three of them are brilliant. So what I do, and what you would normally do, a lot of people would think if you ask AWS for a well-architected review, they'll come in and give you an assessment, which is maybe is nice for audit. But what I started to do back in Liberty, was make this an agile practice for the teams. Have the teams do this every sprint. So every two weeks, the teams have a dashboard of their metrics and then as an architect I ask them about, okay, "what do you think of performance here? What about do you any risk mitigations? Any incidents?" So we actually take this as an ongoing practice. So there's continuous improvement and gamification baked into this well-architected framework.

(39:40):

So some of the things that I would say, things I want to hear from software engineers, and these are some of the signs that - the tells I would have is, when things are working, I would do a lot of threat modeling using Microsoft's stride from the SDL. And one of the threats there is repudiation. And most developers don't know what repudiation is. It's like did something happen? So one of my signs is if I hear a regular software engineer, not a security professional, say "we're not happy with repudiation, we think we want to strengthen it." Think okay, now we're getting somewhere.

(40:14):

Cost. An engineer will be slightly peeved that something may be costing five cents more than it should because they know when it scales, that's going to cost a lot of money. So people refactor stuff to take a few cents off the bill. From operational, if the teams are doing really well, they'll have a runbook, which they're proud of and then they're super proud of it. They're so proud of it they want to show and tell - show other teams their brilliant runbook. Brilliant. That's good

(40:40):

Reliability. We tend to have teams doing chaos testing. A good sign for me is AWS don't have this feature. So we built a way of doing it ourselves. So they're actually ahead of the cloud vendor.

(40:52):

And performance. There should always be an engineer who - the engineer should always be not happy with something. There's always a part of the system they're not happy with. Could be the database, a service call, whatever...a page load time, there's always something. They're never happy or we are never happy with performance. And then for the business KPI, brilliant ask for me is "can you help us tell our story?" Here's our metrics, we're pretty happy. Help us shape this into something. That's a sign for me that SCORP is working and it takes a while to get to that, but that's the behaviors you want from your teams. One of the case studies in the book is around the BBC So the BBC...I thought the presentation earlier was brilliant - there was a few different technologies in the BBC over in the UK. There was a Kubernetes project which didn't do too well, but this was a serverless project. And before the Kubernetes project could launch to production, these guys were up and running, serving billions of requests per month; deploying like 22,000 platform builds to pre-production. 170 releases in a month. So this is the BBC news site. Hit bbc.com/news/uk and look at the news there, mobile, web, tablet, the whole shibang, is in this single serverless system. So you think of their ability to scale. If there's big news like a Royal Family news or something, or something in England, everyone hits the BBC. So their traffic was through the roof. The issues to really affect them before they went serverless because they were trying to build a headroom if there was a big event.Now the system just scales when they need it. Again, the case study is in the book.

(42:32):

So the final mechanism is technical leadership, and this is probably my secret sauce. And for me, this is really wardly mapping. Have your technical leaders think about Wardley Mapping. Have them sit and analyze your capability, and figure out how can we evolve capabilities, what do we need to do? What mechanisms or technologies will help us evolve capabilities in our tech stack? Super technique as well for platform engineering. One of the things that I was involved in this past couple of years was Simon, again, he's based in the south of England. In 2011 he did a big research project on the state of the industry, trying to predict in 2011 what would happen in 2020. He did this again in 2021, trying to predict what would happen in 2030. And what he did is I think he had maybe 12 research groups, he had government, military, e-commerce, telecoms, finance, gaming, et cetera, all these different industries. And we all Wardley Mapped for probably about six months, and then kind of the synthesis of all that mapping. And he wrote a single report, if you only Google Wardly on industrialization, the report is available for free. Not being biased, but it's a brilliant read.

(43:55):

So he's describing the change for modern companies, and I think this is fascinating. He talks about traditional versus next generation; procedures versus guiding principles, top down direction versus the swarming of people; unstated principles versus enforced principles; hierarchical versus non-hierarchal structure. Awareness is a focus for leaders - systemic. Shifting responsibility versus maintaining responsibility. Business model is output driven versus outcome driven. Comms is about mass influence. Comms through my ethics. Learning expert tuition versus gameplay, remote first. Influence executives over external; executive power versus executives and external. Sustainability. Greenwashing versus a core belief. Technology for AI replaces jobs and tasks versus AI replaces tasks. So it's that AI compliments human function over replacing and one of the findings is the traditional companies will decline, the next generation will grow. I think thinking in that evolutionary way is super interesting. That's a great report to think about "what are some of the capabilities and behaviors?" For me, Wardley Mapping helps create focus. It's a difficult skill to master, but it's worth putting the time. And again, in the book we talk about this an awful lot. There's lots of examples and mapping, and a lot of tips and tricks that I've learned over the years, to do this.

(45:34):

So you probably think, well once you take all that kind of value chain, and shift everything to the right, we're done. That's it, we're done. But, what's the next thing? If your stakeholder needs time to value and once you deliver on demand, what's next? Well now you start thinking, well why are we modernizing? What's the emerging capability? What's the thing that's going to give you an advantage over your competitors? Speed is only like - that's a base. Usually it's a reaction. We're too slow. We need to get faster. What happens when you get faster? I can't tell you what that future capability is, but you probably know. If we can deliver on demand, what's the thing we would do next? Is it leveraging AI more? Is it exploring alternative areas? I don't know. It depends on what your mission is, but once you have that speed, that then frees you to explore what that future capability is.

(46:27):

So that's the value flywheel. And again, this is a framework that I've created out of over almost 10 years experience and making this actually work in very large companies. It's an interesting approach, but it's worth digging into. So that's the book, the book's published on IT Revolution. It came out just at the end of last year. Again, what I would maintain is first create that serverless mindset, and then drive modernization. I have a blog there, TheServerlessEdge.com where we blog and we have a Serverless Craic Channel, which again, I started for fun. We have short podcasts, we talk about these concepts. So certainly I'll be around for the rest of the day. If you see us come up and have a chat, I'd be more than happy to. I find it fascinating to speak to other technical leaders on their journey and what's challenging and because lots of help out there. It's just a matter of finding it and tapping into it. So I would definitely give us a connect, a follow and subscribe. And that's me. Thank you very much.

‍