Serverless Craic Ep51 Introduction to Modern Software Development Lifecycle

The Software Development Lifecycle - how does it apply to modern cloud?

We are kicking off this episode with the term modern SDLC. The software development lifecycle (SDLC) is changing. When you get into this new way of working, you start differently. It's no longer a straight waterfall/ABCD, or starting with an established system like SCRUM and iterating. So how do you get into a fast flow state? We have discovered a lot of things over the past couple of years. In this episode, we talk you through the phases of the modern software development lifecycle.

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

Welcome to the next edition of Serverless Craic. We are back for the New Year! We are kicking off with the term modern SDLC. The software development lifecycle(SDLC) is changing. When you get into this new way of working, there's a different way of getting started. It's no longer a straight waterfall/ABCD, or starting with an established system like SCRUM and iterating. So how do you get into a fast flow state? We have discovered a lot of things over the past couple of years. In this episode, we talk you through the phases of the modern software development lifecycle.

Michael O'Reilly: 1:28

It's good to structure your SDLC and understand the high level phases. We talk about engineering excellence. How do you understand how you're doing as an organisation if there's no consistency or structure in how you release software. First and foremost it's good to acknowledge a shape and structure to your SDLC in your organisation.

Mark McCann: 2:12

The modern climate is different. Many techniques, capabilities and services that we leverage, have been democratised. You can stand them up rapidly but it still takes time to be methodical and deliberate setting up for success. Set up for success properly before you start iterating quickly.

Dave Anderson: 2:38

With traditional software, there were things you spent a lot of time doing such as deployment pipelines. You could have spent months doing that back in the day. Now these things can be done quickly, so you can spend your time on other things like domain driven design. You should have done those things in the past, but you never got to then because you were setting up infrastructure, for example. We should have always done design, but now we can focus on it because the heavy lifting items can have gone away. So we focus on our responsibility which is a subtle change.

Michael O'Reilly: 3:40

You must assume there's a vision or endpoint for your business. People have invested in someone to write this software because there's a good idea or problem to be solved. The first phase of your SDLC is business architecture. How does your software model the real world? There are a number of techniques to use upfront. We go through a product discovery phase and we use impact maps, for example, for the shortest route to success to solve this problem. Are we thinking and modelling in business terms using ubiquitous language? And then we go into domain driven design.

Dave Anderson: 4:26

Before that, do we understand the problem? Do we have a Northstar? Sometimes you've kicked off the project but the problem hasn't been well defined. Then there's debate on what the problem is. Sometimes the discovery can include reaching agreement on the North Star and what we're trying to solve.

Mark McCann: 4:56

Some of the techniques that we used in the business process management systems of the past, are starting to reemerge, especially with collaborative tooling like MIRO or lucid charts. You can use those techniques to sketch out the business process around the problem you're trying to solve. Or the people you're going to collaborate with for delivery. BPM is not a bad word in the modern cloud world, it just the tools and techniques for doing it.

Dave Anderson: 5:43

These are blocking phases that you could sit on for months. If no one knows what these things are, it's good to acknowledge that you are in the dark. And it's not that you don't know, nobody knows. That's a really important distinction to make at this phase.

Michael O'Reilly: 6:01

It's almost big picture. Does what we're doing relate to the problem we are solving? What language are we speaking? You should come out of this phase with your first consumable feature. What's the first thing we want to build and get out in front of people? It's good to spend time on that upfront, and not leave it too late in your overall SDLC. You're usually working into a bigger ecosystem or platform, or you are at the beginning of that journey. So it's good to think about how to model the domain that you're in and make good decisions on how your stuff fits in with the system and category.

Mark McCann: 6:59

It is critical to define the domain and bounded context, and understand where the boundaries are. Understanding what the capabilities are of the things that you're going to collaborate with is vital. For example, what way is data flowing through that? And have you modelled the data? Or what's the handoff? And what's the transformation of the data through this new domain. Or is that new bounded context that you're starting to deal with?

Michael O'Reilly: 7:28

It is critical to do the data model critical as early as possible. With modern architectures, like SQL or DynamoDB you need to think about your access patterns up front. There are other dimensions of the business, you must factor in early on, like your reporting, or your business intelligence. So the earlier you do data modelling stuff, the better.

Dave Anderson: 7:56

It is critical to figured out if a data entity is owned by a particular business, so if anybody else wants to use it, you must get it from this single bounded context.

Mark McCann: 8:13

And what are business intelligence dashboards going to look like for the item you're about to build. You must work backwards from the metrics that are going to show up in some dashboard when you deliver the capability, feature or product.

Michael O'Reilly: 8:30

That's the first phase of good modern SDLC, with domains, bounded context and your first consumable features. You may even start to think about some of your example maps. And how you are going to test and the areas of impact. It sets you up for a good technical architectural phase. We talk about well-architected and this phase is where we start to make this a reality. We run well-architected threat model exercises, to think out our pathway to production in terms of acoounts or pipelines.

Mark McCann: 9:16

It's not a big, upfront architectural design, it's your first evolvable architecture that can get your valuable feature out to production.

Dave Anderson: 9:33

Don't write a 100 page document on all things you could do. You have an idea of what you're going to build, so as an architect, have you thought about the five pillars, the threat model perspective, or the risks and mitigations? And by using your developer platform, can you provision quickly? It's about getting set up to make sure there isn't like a rock that you've missed. It's thinking about your big non functional things, and having confidence that you've solved them early. Because it's expensive to go back to them later on.

Michael O'Reilly: 10:18

It doesn't have to take a long time. If you've done the first phase correctly you will have a grip on your first consumable feature, the threat model and the well architected review. As an evolutionary architecture concept, it's good to get the hardest problem out of the way first. Being prepared is a good investment for the next phases.

Dave Anderson: 10:49

It's a different way of working as it's not big design where you make evey decision up front. That can mess with people's heads if they have done that in the past. Because there are two types of people, people who want everything designed up front, and people wo don't want anything desgined up front. The truth is somewhere in the middle!

Mark McCann: 11:06

Modern organisations leveraging fly capabilities, have guardrails, controls and checks and balances built into the ecosystem. So in this phase, you want make sure you have your infrastructure code, static analysis and security checks and balances. Or at least be aware of them and understand how the ecosystem can feedback.

Dave Anderson: 11:30

When you talk with a team, you need to explain that there's a bunch of things that we have to turn when we get to production. So it's not a one time check that goes away. If this thing is not done, it will ping on a dashboard.

Michael O'Reilly: 11:50

It doesn't have to involve architects, it can abe done by the team themselves. Architecture can be leveraged if there's something genuinely new, or reasonably complex that you haven't encountered or if it's new to the org.

Mark McCann: 12:09

Architecture should be there to enable the team to do this. Otherwise it is self serve and autonomous.

Michael O'Reilly: 12:16

You have your business architecture, a good grip on the dimensions and technical architecture, then you get into your build phase to get your first consumable feature out to prodction. So now you must think about implementation. Every implementation is different, and will have its own approach and requirements. You must understand testing, enterprise patterns and EDA, and make sure teams can elaborate and apply them in their implementation. At the end of this phase you should have workloads working conversions through dev tests out into production, built with well-architected business architecture. So you can be confident that you're in the right space and zone. I'm a stickler for telemetry, observability which is part of well-architected. But, there's never any excuse for releasing without good telemetry and, being clear about what your success measures are. So you can see if things do what they need to do. In the third phase the engineers go and build.

Mark McCann: 13:53

Be deliberate and methodical about building a reliable pathway to production.

Dave Anderson: 14:05

In summary there arethree phases. There's the ideation or what are we going to build? And let's figure out what the problem is? What's the architecture foundation and how do we set up our non-functional items correctly. And finally the build and pathway to production or build the workload and get it out with observability and quality baked in etc.

Michael O'Reilly: 14:38

Slow is smooth and smooth is fast.

Dave Anderson: 14:45

Some people think it sounds slow. However you must figure out your problem, make sure your foundation is right and build the simplest thing you can possibly build. Get that right. One you do that you're into 'smooth is fast'. And then you speed up. It does sound counterintuitive. But it's hard to retrofit those things we talked about in the ideation and foundational phase.

Mark McCann: 15:10

You mitigate the risks of project failure or product failure, because you've set everything up and you're into fast feedback.

Michael O'Reilly: 15:25

Get the smallest possible thing out as quickly as possible. We call it the first consumable feature, or something that someone can use, or put in front of a customer or operator to get feedback. You are in a position where you've got telemetry you can observe and you've got a stable pathway to prod. You've got a good grip on business architecture, the business and product understand what you're doing. And then you are 'smooth is fast', where then can start to take feedback, release small features frequently, iterate and get rapid feedback with A/B tests and good modern techniques. You are leveraging your pipeline, you can deploy ten times a day, to get feedback and build rapidly. You've taken care your risks, you're working to the organisational standards, you're well-architected, you're secure and you're in good shape.

Mark McCann: 16:39

And critically, you're getting product feedback from real users. Are you on the right track or is it completely off piste? Or is it aligned to the product vision, your Northstar and the key input metrics that your business stakeholders and users are expecting.

Dave Anderson: 16:59

So it we play devil's advocate, why do you need to do this? Remember the old agile concept of build the right thing and build it fast? Hopefully it stops you building the wrong thing. There's so much power in the modern cloud today and you have so much at your fingertips. If your team don't know what they're doing they could create a lot of damage by not doing this early stuff. You must measure twice and cut once because of how the cloud is. If you don't put key things in place, you could go a long way down a path before you realise something is wrong, and you will not have an idea of what happened. You mitigate risk by putting stuff in place early. It's a different way of working.

Mark McCann: 17:50

With the slow is smooth phase you get rapid feedback from real users, customer input and business input. As a team, you can work out next highest priority item to develop because you're focusing on business and product value. What is the 'next best action'? You've built observability and telemetry so you have metrics to measure success against tangible empirical things. Fast feedback vital. With the cloud, things never stand still, so there may be emerging threats or cost optimizations that you can take advantage. Or new capabilities or services come online from your cloud provider and also in your ecosystem. You can think about how to adapt them.,

Dave Anderson: 18:46

You definie your SDLC. If you have six or seven teams, building four things, you want those four things to behave and feel the same. You don't want four completely different things. It's crtiical to have a standard on how you build so you are working in the same way.

Michael O'Reilly: 19:24

And that helps you as an organisation. You can observe teams are progressing through the phases and it tells you what you need to invest in from a support or provision perspective.

Dave Anderson: 19:40

So that's the craic! Our episode is an intro into modern SDLC. Once you get the foundations of being in the cloud, you have questions on modernization what it looks like. So we will do moe episodes on that. Have a look at TheServerlessEdge.com or blog and follower us on X@ServerlessEdge.