The software development lifecycle (SDLC) is changing. You must start working differently with the Modern Cloud. It’s no longer a straight waterfall/ABCD or beginning with an established system like SCRUM and iterating. Instead you must discover how to move to a fast-flow state. We have discovered a lot of things over the past couple of years. In this article, video and podcast, we discuss and share our three Software Development Lifecycle Phases for the Modern Cloud.
Set up for success before you start iterating
It’s good to structure your SDLC and understand the high-level phases. We talk about engineering excellence. How do you know how you’re doing as an organisation if you need consistency or structure in releasing software? First and foremost, it’s good to acknowledge the shape and structure of your SDLC in your organisation. 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 in setting up for success. Set up for success properly before you start iterating quickly.
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, you can do these things quickly and spend time on domain-driven design instead. You should have done those things in the past, but you probably never got to them because you were busy setting up infrastructure, for example. Now we can focus on design because the heavy-lifting items have gone away. So, we concentrate on our responsibility, which is a subtle but important change.
Phase 1 of the Software Development Lifecycle – what are we going to build?
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 several techniques to use upfront. We go through a product discovery phase and we use impact maps, for example, for the shortest route to success in solving this problem. Are we thinking and modelling in business terms using ubiquitous language? Then, we go into domain-driven design. Before that, do we understand the problem? Do we have a Northstar? Sometimes, you’ve kicked off the project, but the issue needs to be better defined. Then there’s debate on what the problem is. The discovery can include agreeing on the North Star and what we’re trying to solve.
Some of the techniques that we used in the past business process management systems are starting to reemerge, especially with collaborative tooling like MIRO or Lucid Charts. You can utilise 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 is just the tools and techniques for doing it.
These are blocking phases that you could sit on for months. If no one knows these things, it’s good to acknowledge that you are in the dark. And it’s not that you don’t understand, nobody knows. That’s a significant distinction to make at this phase. It’s the big picture. Does what we’re doing relate to the problem we are solving? What language are we speaking?
Phase 2 of the Software Development Lifecycle – what’s the Architecture Foundation?
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 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.
It is critical to define the domain and bounded context and understand where the boundaries are. Comprehending the capabilities of the things you will collaborate with is vital.
Get to grips with capabilities like data flow
For example, in 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? 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 business dimensions you must factor in early on, like your reporting or your business intelligence. So, the earlier you do data modelling stuff, the better.
It is critical to determine if a particular business owns a data entity, so if anybody else wants to use it, you must get it from this single bounded context. And what will business intelligence dashboards look like for the item you’re about to build? You must work backwards from the metrics appearing in some dashboard when you deliver the capability, feature or product.
That’s the first two phases of good modern SDLC, with domains, bounded context and your first consumable features. You may even think about some of your example maps. How are you going to test the areas of impact? It sets you up for an excellent technical architectural phase.
Phase 3 of the Software Development Lifecycle – the build and pathway to production
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 accounts or pipelines. It’s not a big, upfront architectural design; your first evolvable architecture can bring your valuable feature to production.
Don’t write a 100-page document on all the things you can do. You have an idea of what you will 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 ensure you haven’t missed a block. It’s thinking about your big non-functional things and having confidence that you’ve solved them early because it’s expensive to return to them later.
Get the most complicated problems out of the way first
It doesn’t have to take a long time. If you’ve done the first phases correctly, you will have a grip on your first consumable feature, the threat model and the well-architected review. As an evolutionary architecture concept, getting the most complicated problem out of the way first is good. Being prepared is a good investment for the subsequent phases. It’s a different way of working as it’s not a big design where you make every decision up front. That can mess with people’s heads if they are used to doing that. There are two types of people: people who want everything designed upfront and people who don’t want anything designed upfront. The truth is somewhere in the middle!
Modern organisations leveraging flywheel capabilities have guardrails, controls and checks and balances built into the ecosystem. So, in this phase, you must ensure 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 provide feedback.
When you talk with a team, you must explain that there are many things we must turn on 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. It doesn’t have to involve architects; the team can do it. Architecture can be leveraged if there’s something genuinely new or reasonably complex that you have yet to encounter or if it’s new to the org. Architecture should be there to enable the team to do this. Otherwise, it is self-serve and autonomous.
Have clear success measures
You have your business architecture and a good grip on the dimensions and technical architecture; then, you get into your build phase to get your first consumable feature out to production. So now you must think about implementation. Every implementation is different and will have its approach and requirements. You must understand testing, enterprise patterns, and EDA and ensure teams can elaborate on 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 correct space and zone.
We are sticklers for telemetry observability, which is part of well-architected. There’s never any excuse for releasing without good telemetry and being clear on your success measures. So you can see if things do what they need to do. In the third phase, the engineers go and build. Be deliberate and methodical about building a reliable pathway to production.
Summary of the 3 Phases of the Software Development Lifecycle
In summary, there are three phases:
- 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?
- Finally, the build and pathway to production or build the workload and get it out with observability and quality baked in, etc.
Slow is smooth, and smooth is fast.
Some people think it sounds slow. However, you must figure out your problem, make sure your foundation is proper, and build the most straightforward thing possible. Get that right. Once you do that, you’re into ‘smooth is fast’. And then you speed up. It does sound counterintuitive. But it takes a lot of work to retrofit those things we discussed in the ideation and foundational phase.
You mitigate the risks of project or product failure because you’ve set everything up and you’re into fast feedback. Get the smallest possible thing out as quickly as possible. We call it the first consumable feature, something 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 and can observe and see a stable pathway to prod.
You’ve gained a good grip on business architecture, and the business and product understand what you’re doing. Then you are ‘smooth is fast’, where you 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 daily to obtain feedback and build rapidly. You’ve taken care of your risks, you’re working to the organisational standards, you’re well-architected, you’re secure, and you’re in good shape.
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 critical input metrics that your business stakeholders and users expect?
Why do you need to adopt the 3 phases of the Modern Cloud SDLC
So, if we play devil’s advocate, why do you need to do this? Remember the old agile concept of building the right thing and building it fast? Hopefully, our method stops you from doing the wrong thing. There’s so much power in the modern cloud today, and you have so much at your fingertips. If your team does not know what they’re doing, they could create a lot of damage by not doing this early on. You must measure twice and cut once because of how the cloud is. If you don’t put critical things in place, you could go a long way down a path before you realise something is wrong, and you will not know what happened. You mitigate risk by putting stuff in place early. It’s a different way of working.
With the slow is smooth phase, you get rapid feedback from real users, customers and business input. You can work out the next highest priority item to develop as a team 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 is vital.
Things never stand still with Modern Cloud
With the cloud, things never stand still, so there may be emerging threats or cost optimisations that you can take advantage of. New capabilities or services come online from your cloud provider and your ecosystem. You can think about how to adapt them. You define your Software Development Lifecycle. If you have six or seven teams, building four things, you want those four things to behave and feel the same. You don’t need four completely different things.
Having a standard on how you build is crucial so you are working in the same way. And that helps you as an organisation. You can observe how teams are progressing through the phases, and it tells you what you need to invest in from a support or provision perspective.
So that’s the craic! Our article is an intro to Modern SDLC. Once you get the foundations of being in the cloud, you have questions about modernisation and what it looks like. So we will do more articles on that soon.
Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge and LinkedIn The Serverless Edge