The team have previously looked at Modern Cloud from the CEO and Digital Product Leader perspectives. This week they look at Modern Cloud Architecture for Developers starting with the need to map out your tech stack to find the inertia holding your org and customers back.
We’re continuing our conversation on Modern Cloud. There are a couple of previous episodes: an overview of the CEO’s perspective and an overview of Product’s perspective. I figured we would look at the Developer perspective today. This ties in with our ‘next best action’ or ‘bias for action’ concept. For developers, there’s a certain environment that you need to be in. One thing we find useful is to Wardley map your tech stack. Sometimes when you meet with developers, you don’t know what’s working or not. By mapping out the tech stack, it’s easy to spot things that are in the wrong place.
Modern Cloud Architecture starts with mapping your tech stack
In modern cloud architecture, capabilities are evolving and merging rapidly. So mapping out your tech stack and understanding what’s available in a modern cloud environment is very valuable. You can have a conversation with your teams on the components of the tech stack and see if there are more advanced modern cloud capabilities to take advantage of. Is there a managed service capability that can offload some of the burden in our tech stack? Through Wardley mapping you assess your users, their needs and what to do to meet those needs. If you go through your value chain of components and your tech stack you can assess what you really need. Can you leverage DynamoDB, step functions or some other evolved modern cloud capability to meet those needs?
There are two parts that are interesting in relation to the user of your application and the components. Number 1, you can spend a lot of time in your logging framework only to realise that it’s lowdown in the stack and nobody really cares. And secondly, you may have something that is custom and complicated that you spend a lot of time on. But as you say, Mark, there’s potentially a more evolved version. For example if we’re using a custom MySQL database that we installed, could there be a cloud native equivalent that’s a more evolved version? And what could that capability evolve to? It is hard to see that from within a team.
Understand the full value stream
I want to add a couple of extra points to this. It’s a cracking exercise to involve business or product people who don’t understand the full value stream. Typically in organisations, investment is done at the UI or UX level. Perhaps they want to make a change but don’t really understand the level of complexity that’s involved. A map can be a vehicle for a conversation to get investment to replace a legacy part of the platform. With mapping, you can’t change everything there and then, but you can plot a path. It’s a good way to set goals, look for opportunities and work towards those goals. I like to do that very early with squads and look for opportunities for the year ahead. What areas need investment for modernization or to move up a level? It’s a really good approach to have a joined up and holistic conversation.
It keeps you grounded in the real needs of your users. With modern cloud architecture you can feel like a kid in a sweet shop if you’re technically minded. All these capabilities are available that you want to explore and leverage but the map keeps you focused.
The more maps that you do, the more tricks you learn, for example, when you identify skills needed for a particular value stream and how much investment your organisation needs to build individuals with those skills. By looking at the full value stream, you can have a conversation on the broader picture ie. If we move towards this commodity, can we invest in those skills and move faster? I can’t speak more highly of this technique!
Find quality developer patterns
As well as having that conversation as a team, you’re implicitly putting the concept of evolutionary architecture into everyone’s head. In other words, it’s okay to keep changing. There isn’t a sunk cost fallacy where we hang on to something for years, because we built it. What you also need from your tech stack is rapid delivery. You want your engineers to deliver features into production quickly. There’s lots of ways to do that. One way is by using decent developer patterns like CDK patterns.
Composable building blocks are critical for rapid delivery. With modern cloud architecture and Product Leader and CEO needs, speed is key. You need proved patterns to compose your solution from. With the emergence of infrastructure as code, CDK, SAM and other infrastructure code capabilities, you can bring expertise and patterns to your teams to rapidly stand up solutions. For example a single page app pattern is a building block that can be deployed. Or an API gateway that connects to a new SQL database with step functions in the middle to do workflow. Pattern collections have exploded over the last couple of years. With modern cloud, you should be able to find a well proven pattern that you can leverage or customise to your needs. And you are rapidly delivering value.
Ensure quality in your pattern choice
Use someone else’s boilerplate code and spend your time in design and discovery. Rapid delivery is a massive breakthrough. Sometimes people think rapid means poor quality! And if you’re going to build with those patterns, then you need to build quality in! You actually need to start by having a high standard of technical excellence to make sure those patterns have quality attributes, in the first place.
If you don’t have quality baked in, it’s going to fall apart quickly. If you don’t have engineering excellence, and you’re not doing unit testing, integration testing, security scanning, logging and audit traceability as part of your automated pipeline, you can’t go fast.
Building squads with continuous learning
When you are talking about modern cloud architecture, serverless and leveraging managed services, a lot of things shift left. There’s a lot of responsibility on the squad to assemble things to meet certain standards in the organisation. Building up squads is a huge aspect. In previous conversations, we’ve talked about supporting teams by creating a psychologically safe environment to learn and set up for success. We are talking about opportunities to improve reliability or stability, and doing it in an open way that all feeds back into patterns, run books and playbooks.
So as a group or a collective, we become stronger and more effective. We are talking about well architected and doing it more frequently using our SCORP process to let teams assess where they are. Are we happy with how things are or what else could we be doing? What could we be doing better? That is important in modern cloud environments. When you are building squads, you start off with the basics and get your observability set up which takes time, and you will go slow. But it’s amazing, because after one or two months, you begin to see the philosophy creep in and before you know it you’re ten times what you were at the start and you’ve got all the confidence in the world. The engineers are empowered and they’re very creative. With continuous architecture you’ve got everything you need to confidently pivot and deliver rapidly.
Invest in continuous education
It’s an investment in continuous education. Things move fast. New features and capabilities are emerging every day. The SCORP process, well architected reviews and being aware of what’s available is a constant thing. As a developer, you’ve got to invest in continuous education and continuous learning. We’ve benefited massively from following the right people on Twitter and subscribing to YouTube channels to watch videos as well. It pays dividends. If you have mapped your tech stack, have situational awareness and if you are leveraging modern cloud properly, you can apply the features that are being announced today. That is the differentiator for your team and for your business.
You can have a cloud stack with developers dealing with old stuff and monoliths. Or you can have a modern cloud stack, where you are asking developers to go fast, build quality in and you’re supporting them with training, the SCORP process and well architected. You are actually investing in the team to help them create the best application they can. It all fits together. And guess what? You have happy developers! Nicole Forsgren describes it in her ‘Accelerate’ book: if you invest in your team to make them go fast and safely, then employee engagement shoots up. It’s quite hard to explain because some people see it as money spent. But the business benefits at the other end.
So that’s the craic! That’s our developer slant! We could talk about it all day. Check out the blog at TheServerlessedge.com. Follow us on Twitter @ServerlessEdge. The book is out for pre-order! Get ‘The Flywheel Effect’ from all good booksellers, including Amazon and Barnes and Noble. Alright, thanks very much!