Is SDLC a framework or a methodology or a process?
It’s none of the above. It’s a lifecycle. The clue is in the name.
As such, it’s a somewhat orthogonal concept to everything else. Because it’s descriptive, not directive.
It’s probably closest to being a framework — in that it’s very large and loose. And you could build a methodology out of it.
SDLC is basically a catch all term for longer term software or systems planning — it is most popular when used for Corporate Information Systems.
What is a lifecycle?
Life cycle is probably easiest to understand if it’s followed back to it’s biological origins[^9].
[^9]: All sorts of things are considered to have lifecycles including stars, cultures and empires. But lifecycles clearly have their roots in biology. It is after all the study of “life”.
Human beings, for example all share a common lifecycle. It is well established. Medical science uses all aspects of it. Schools, marketing departments and insurance companies use various portions of it.
The Human Lifecycle looks like this:
- We start as two separate gametes
- We are conceived and become zygotes
- After five days we become a blastocyst
- The blastocyst hatches and becomes an embryo
- Which then become a foetus
- You go through the process of “birth”
- After which point you’re considered to be an “infant”
- Who then grows up into a toddler
- Which becomes a child
- Young Adult
- Middle Adult
- Old Age
There are expected timings, based on historical statistics for “each phase”. These can be compared across time and between population. How exact these timing can be expected to be varies by stage.
All biological entities have a life cycle. Frogs, trees, fungus.
It helps us understand these things. It helps us plan. It helps us manage. It helps us see problems.
There are developmental markers in human children. We use these to help children who may be struggling.
And there are predictable timelines in all kinds of crops, helping known how long our trees will take to bear fruit.
The concept of SDLC is an attempt to apply the same concept to software or systems development. It’s based on the belief that every software or systems development initiative shares a sufficient similar lifecycle that what happens in one will be applicable to all.
It’s based on the idea that there is a time before a system is first deployed into production (it’s conception and ultimate birth) — and that systems enjoy a youth, proceed into a kind of middle age, and are ultimately decommissioned (death).
Windows XP is now both dead and buried. Windows 7 is now not only officially in old age but in palliative care.
Euthanasia is clearly legal in the SDLC universe as Windows 7 has already been declared “End of Life” as of 14 January 2020.[^2]
[^2]: In some ways though this is more like the old tribal tradition of casting out the older members, as Windows 7 will continue to function, but without the protection of the tribe (Security Updates) it’s going to fall victim to the first hungry wolf it encounters(virus)
Where the confusion sets in — why SDLC looks like it might be a methodology
If you look at some basic SDLC models you will see lifecycle phases such as “Requirements Analysis”, “Systems Design” & “Systems Development”
These look a lot like Waterfall phases. Probably because they are.
And this is where people get confused.
They mistake these SDLC phases for “the” SDLC, and also miss the part that these are the life cycle phases for a Waterfall Project.
And then try and apply these same phases to an agile project, which has the effect of making that agile project, well, a waterfall projects (but perhaps with JIRA® and stand-ups.
The problem is however that unlike say a human being or a frog where the lifecycle just sort of happens, (largely predetermined by our DNA), people tend to feel that they can dictate the lifecycle of a software system. In effect taking on the role of some kind of divine creator.
It’s some what meglomaniac if you think about it…
Anyway, whilst it makes complete and total sense to plan for your systems potentially inevitable demise, it makes a lot less sense to insist that you know exactly how long puberty should last.
Never forget that **real **lifecycles are based on facts and observations. On homogenous samples across long periods of time. By people really good at that sort of thing. The entire insurance industry was founded (and continues to thrive) on this concept.
Whilst our personalities might all be as individual as snowflakes — our bodies don’t know this and tend to follow some fairly well established patterns.
Our educational systems are based on the same principles.
“Based on our experience, we know that humans at this age are now able to assimilate these skills and concepts and take this long to do so.”
And even then, working all with the same species, there are exceptions. Fast learners and slow learners and even children that are far ahead in one are (say reading and writing) but deeply behind in maybe maths or physical development. Even with hundred of years of data on the same species there are confounding outliers.
Lifecycles are useful without a doubt, but they have their limits. And when they’re treated as “the objective” rather than informational guidelines, that’s when things start to go very wrong.
If you and your organisation use or are planning on using SDLC the first question you really to need to ask is “how alike are our projects really?”
Because only things that are very alike should share the same lifecycle.[^0]
[^0]: And of course, if you try and overfit a single lifecycle to a diverse set of things, you end up with something so abstract and general as to be useless — such as “Born”, “Alive”, “Dead”
But this doesn’t entirely stop people from trying.
Because there are, or at least there were, so called SDLC Methodologies created. The one that comes to top of mind is “SSADM” which was quite popular with the UK Government in the early 1980’s
Purely as an example SSADM focussed very much on the pre-writing-code part.
Stage 0 – Feasibility study
Stage 1 – Investigation of the current environment
Stage 2 – Business system options
Stage 3 – Requirements specification
Stage 4 – Technical system options
Stage 5 – Logical design
Stage 6 – Physical design
SSADM is therefore, simply a variant of the Waterfall Framework. Waterfalls within Waterfalls really.
SSADM is basically “Lean Start-up for Grandpa’s” — as it focussed on solving the problem of “should we build it” rather than “actually building it” — that was pretty much regarded as an after thought. It’s very much routed in the belief that “coding is the same as manufacturing” — which was basically the mindset that inspired people to create agile as a rebellion against this idea.
(Agile is fundamentally the enemy of “Software Engineering” — Software Development is nothing at all like engineering. Which any actual engineer will gleefully tell you.)
If you compare the SSADM and Lean Start-up it’s quite clear that one was designed for the civil services — with a deep emphasis on analysis and making very considered and controlled changes at a glacial pace — and the other (Lean Startup) with finding a good market fit for a product in a fast moving competitive landscape.
Life Cycle Stages and Activity
The point that most people seem to miss though is that the concept of SDLC does not demand that we use Waterfall. It is however perfectly understandable however why people think this — especially when you look at generic and (overly) simplistic models which simply look like Waterfall with a “maintenance” phase added after deployment if you’re lucky.
It does not have to be the case however.
A “Scrum Project” for example could be considered to be “in development” for the entire time that you’re sprinting.
When applying SDLC to agile or scrum initiatives it’s rarely useful to “split out” things like “testing” — as this is an ongoing integrated part of the process. It was only separate in many historical SDLC’s because it was a separate phase in waterfall. It’s not part of the concept itself.
Remember life cycles are descriptive, not directive.
So depending on your environment, “Deployed” might not make sense either!
If you’re building up (for example) an SAAS web application — which is updated with new functionality every month. Then deployment is an ongoing activity, not a once off phase. Thus new terminology needs to be created. Perhaps “ongoing development” simply becomes “bug fixes only”
We do not code -> test -> deploy in separate phases. Instead we are “in active development” unless we’ve met some business goal.
You might also choose to follow more design lead approach where you are alternating between “development” phases and “assumption validation” phases where you are simply collecting and analysing data on what you have just deployed in order to see if you’re finished.
**Bottom line — the classic “Waterfall Phases” are not “the” SDLC. **
You see them around because somebody in 1982 was describing / drawing the SDLC for a Waterfall Project.
To apply the same steps to a completely different framework does not make any sense at all. In fact it’s dangerous and misleading.
In the same way that a human, a frog and a Californian Redwood all have completely distinct lifecycles, every organisation (and quite possibly every sub system inside that organisation) should have a set of lifecycle stages that make sense for that organisation or system.
The Fungibility Issue
Bottom line here is that SDLC can be applied well and usefully, or it can be applied mindlessly and stupidly.
Lifecycles are useful for things that are alike. They help us plan for the inevitable.
It is however not that practical to declare a single lifecycle as “best practice” and then insist that everything single thing follow the same stages. We may as well insist that humans live as long as bowhead whales (200+ years if you’re curious).
Useful Applications of SDLC (in my opinion)
I think that SSADM got the focus wrong. SDLC is most useful when we consider the entire lifecycle of a software system or product[^1]
By this I mean not so much the software development phases themselves but rather everything else — as an example of something that might be more compatible with an agile way of working consider:
- We are considering the need to build a system
- We are figuring out what problem exactly the system should solve
- We are negotiating a suitable budget and timeline for our system
- We are building confidence that such a system can be built
- We are building the system
- The System is now in production and generating value
- The System is still under active development
- The System is in maintenance mode
- The System is now at end of life
- The System has been entirely decommissioned and we had a party
It’s very useful for senior management to have some indication of the expected lifetimes of systems as well as having plans for data retention and migration once we reach stage 9 (in the above model) — it also helps co-ordinate with other functions inside the average enterprise, such as those people deploying PC’s, Servers and Helpdesks. Not to mention working with vendors whose products the internal systems are likely based all of which have their own lifecycles.
Finance people also find SDLC useful for purpose such as capitalisation and depreciation. Especially if they’re running in a traditional CAPEX / OPEX type of accounting model.
The final useful bit in the SDLC concept is thinking of it as Systems, rather than Software.
This focuses people on planning for the non software parts of systems change. The hardware, the hosting, the policies, the procedures, the people and yes the accounting.
SDLC is best employed when it encompasses a far larger remit than just the development of the software.
Kind of like Design Thinking really 😉
[^1]: Although when this kind of concept is applied to Products, I tend to refer to it not as SDLC but rather as Product Strategy a more general set of practices and principles with application outside of pure software systems. SDLC is a very IT centric view of the world.