TL;DR: The traditional SDLC breaks in five predictable places (the wall between dev and ops, the long wait for feedback, manual steps, late bugs, and rigidity), and DevOps answers each with shared ownership, automation, and rapid feedback.
- The SDLC names the phases a system lives through; waterfall is just one ordering of them, and the 1970 paper behind that diagram already judged it risky.
- After release, maintenance absorbs 80 to 90 percent of all lifecycle cost.
- Every failure mode has a DevOps counter: one team, daily integration, delivery pipelines, infrastructure as code, and live monitoring.
- DORA’s four key metrics make the claim measurable, and the research ties strong delivery to better business results.
- The price is real culture change, not a tool purchase.
Every DevOps introduction draws the same staircase: requirements, design, development, testing, deployment, maintenance, one phase per step. Few mention that the 1970 paper the staircase is credited to already judged the model risky, or that the phase where software spends most of its life is the one nobody demos. This article is the written half of the Whiteboard Architect episode on where the traditional SDLC breaks. Watch the full episode on YouTube, or read on: every date and number below is checked against the cited sources.
The opening board: the staircase, with feedback months away. Its credited author judged the model risky from the day he published it.
What DevOps Actually Is
Strip away the logos and DevOps is one idea: development and operations stop being two teams who hand work over a wall and become one team that owns software from first requirement to last production incident. AWS describes it as a combination of cultural philosophies, practices, and tools that removes the barrier between the two traditionally siloed sides. The ordering matters: culture and practices first, and the tools are how the new way of working gets fast, not what creates it.
The name is younger than the ideas. The first DevOpsDays conference was held in Ghent, Belgium, in 2009, founded by the consultant and practitioner Patrick Debois, and the word itself is a blend of development and operations, as Wikipedia’s DevOps article records. There is also no official definition to appeal to: an academic review found no consensus on what DevOps covers, so treat any definition, including this one, as a working agreement rather than a standard.
| DevOps is | DevOps is not |
|---|---|
| One team owning software from requirements to production | Two silos passing work over a wall |
| A way of working: culture first, then practices and tools | A crate of tools you install and call done |
| A working agreement, since reviews find no consensus definition | A standardized framework with an official body |
The SDLC Is Not Waterfall
Most conversations go wrong one step before the interesting part, by treating the SDLC and waterfall as the same word. They are not. The systems development life cycle names the whole journey: every phase a software system lives through between first concept and final retirement.
The Wikipedia article on the SDLC is blunt that “the SDLC does not prescribe how engineers should go about their work to move the system through its life cycle.” Waterfall is one answer to that open question: run the phases in strict sequence, each completed before the next starts, progress flowing in one direction. The V model, iterative, spiral, and agile are other ways to walk the same lifecycle.
So when someone says “the traditional SDLC is waterfall,” they mean the classic staircase: requirements, design, development, testing, deployment, maintenance. Winston Royce’s 1970 paper, the one that diagram is credited to, presented the picture as flawed: with testing only at the very end, he called the model risky, and the extra steps he proposed to fix it never took mainstream hold. The honest story starts with the diagram’s own author objecting to it.
| Question | SDLC | Waterfall |
|---|---|---|
| What is it? | The lifecycle concept: every phase between concept and decommission | One sequential way to walk those phases |
| Does it fix the order? | No, it prescribes no particular order | Yes, one phase finishes entirely before its successor begins |
| Who else walks the lifecycle? | V model, iterative, spiral, agile | Overlapping variants only in later modifications, such as sashimi |
The 1970 association is real but backwards in the popular telling. Winston W. Royce’s paper is the first formal presentation of the stepped diagram, and he used it as the risky baseline: testing only at the end, feedback only after everything is built. He proposed five additional steps around it, including doing the program design twice and involving the customer earlier, and those proposals, not the naive staircase, are what he actually advocated. They never took mainstream hold, so the industry kept the part he warned about. The phased idea itself is older: Herbert D. Benington’s 1956 account of the SAGE system is commonly cited as the earliest phased presentation. And the word “waterfall” appears nowhere in Royce’s paper; it is usually traced to a 1976 paper by Bell and Thayer, though that attribution is less firmly sourced. The Wikipedia article on the waterfall model carries all three threads.Where did the waterfall diagram actually come from?
No. Six (requirements, design, development, testing, deployment, maintenance) is the classic textbook count and the one this episode walks, but counts vary by source. Wikipedia’s SDLC article, for example, describes eight phases, from conceptualization and requirements analysis through design, construction, acceptance, deployment, and maintenance to decommissioning, and it notes that phases can overlap and iterate in practice. Other sources count five or seven. The honest framing: the six step staircase is the version most introductions draw, not a definition any standard enforces. One correction worth carrying out of the phase table: development is often called the longest phase, and for the build itself it frequently is. But the phase with the documented claim to “longest” is the one after the arrow leaves the diagram. The requirements spec has its own lineage, formalized as IEEE 830 in 1984 and living on as ISO/IEC/IEEE 29148.Is six the official number of SDLC phases?
Walking the Six Phases
The staircase deserves one honest walk, because two of its steps hide the whole DevOps story. Here is what each phase actually produces, in the classic order:
| Phase | What happens | What comes out |
|---|---|---|
| Requirements | Analysts and stakeholders pin down functional and non functional needs | The specification (SRS), the shared reference the customer and the builders agreed on |
| Design | High level design for how the parts fit, then detailed design for each part’s internals | Design documents that guide the build |
| Development | The system gets built; often the biggest block of pre-release time, though that is a pattern, not a law | Working code |
| Testing | Unit, integration, system, then acceptance and UAT, all after the whole system exists | A verdict on the build |
| Deployment | Long done by hand; each manual operation adds delay and the risk of human error | Software in production |
| Maintenance | Fixes and changes for the rest of the system’s life | The version people actually use |
Maintenance Is Where the Money Goes
Board 6 of 13: where the money goes. Maintenance, not the build, takes 80 to 90 percent of lifecycle cost.
The staircase drawing usually stops at deployment, as if the story ends when software ships. The money says otherwise. Wikipedia’s software maintenance article calls maintenance “the last and typically the longest phase of the cycle,” puts its share of lifecycle cost at 80 to 90 percent, and attributes the rising difficulty to lost expertise and decaying architecture. The system your team will spend most of its career touching is the one that already exists.
The ISO/IEC 14764 standard counts four kinds of maintenance, and most introductions list only the first three:
| Type | What it addresses |
|---|---|
| Corrective | Fixing bugs found after release |
| Adaptive | Tracking a changing environment around the software |
| Perfective | Improving what already works |
| Preventive | Correcting latent weaknesses before they surface as incidents |
Where the Traditional SDLC Breaks: Five Failure Modes
Run the staircase the waterfall way and it cracks in five predictable places. None of them is about laziness or bad developers; each is a structural property of sequential, siloed delivery:
| # | Failure mode | What it looks like |
|---|---|---|
| 1 | The wall | Code is built on one side of a divide, then tossed to operations; neither side sees the other, and only ops holds production knowledge |
| 2 | The long wait | Requirements are fixed before work begins, yet users discover their real needs only once software runs; that discovery lands as months of rework |
| 3 | Manual steps | Verification, release, and environment setup all run on human labor, so shipping is slow, mistake prone, and infrequent |
| 4 | Late bugs | Bugs surface only once the system is whole, when they cost most to repair; verification is back-loaded |
| 5 | Rigidity | After the build begins, any change of direction is paid for twice: rework, or a restart |
The long wait and the late bugs compound each other. Because feedback arrives months late, requirements signed in month one get corrected in month nine, at the most expensive point in the process. Microsoft’s DevOps guidance gives the fix a name: continuous integration catches bugs early in the cycle, which makes them less expensive to fix, and shift left testing exists for the same reason. AWS is just as direct about crack three, describing DevOps practices as automating processes that “historically have been manual and slow.”
What DevOps Changes, Crack by Crack
DevOps is best read as five answers aimed at five cracks, not a list of unrelated practices. The mapping:
| Failure mode | DevOps answer | What it looks like in practice |
|---|---|---|
| The wall | One cross functional team | Development, operations, and test work together under the motto “you build it, you run it,” credited to Werner Vogels |
| The long wait | Continuous integration | Code integrates into the shared branch at least once a day, with each integration running an automated build and tests |
| Manual steps | Continuous delivery and infrastructure as code | A deployment ready artifact always exists; environments are defined in files and rebuild identically |
| Late bugs and slow recovery | Monitoring and logging | Real time telemetry on what users experience; trouble is caught before or as it reaches them, driving restore time down |
| Rigidity | Small, frequent releases | Small, frequent increments keep plans and risks manageable, so market shifts bend the roadmap instead of breaking it |
The wall comes down organizationally before it comes down technically: the point of “you build it, you run it” is that the people who understand why the software behaves as it does are also on call when it misbehaves. The other four answers work the same way in miniature; each replaces a scheduled-later activity with something continuous. We go deeper on the vocabulary in our CICD interview questions guide.
Continuous integration is a discipline, not a server. A cadence of integrating work at least daily is considered good practice precisely because it keeps every change small enough to test, instead of stockpiling months of divergence into the integration phase the staircase scheduled for later, a fate the literature calls merge hell. Each integration runs an automated build with tests, so a broken change announces itself within hours. Continuous delivery keeps the pipeline loaded after that: the artifact heading for production is always built, tested, and ready, so a release becomes a business decision rather than an engineering event. Infrastructure as code extends the same logic to environments. Instead of a runbook of manual steps that drift machine by machine, the target state is described declaratively in version controlled files, and every environment rebuilds the same way, which removes the risk of manual misconfiguration.What do continuous integration and delivery actually change day to day?
Measuring the Claim With DORA Metrics
Board 10 of 13: DORA’s four keys, split into speed and stability, with the 2021 and 2022 updates footnoted.
If DevOps were only philosophy, this is where the article would hand-wave. It is measurable instead. DORA, DevOps Research and Assessment, published by Google Cloud, pinned down four key software delivery metrics: two for speed, two for stability. Per Google Cloud’s four keys writeup, the research ties strong delivery performance to better business outcomes, and elite performers were “twice as likely to meet or exceed their organizational performance goals.”
| Group | Metric | What it tells you |
|---|---|---|
| Speed | Deployment frequency | How often you actually ship |
| Speed | Lead time for changes | How long from commit to running in production |
| Stability | Change failure rate | The share of deployments that cause failure |
| Stability | Time to restore service | How fast you recover when one does |
The set has not stood still: 2021 brought a fifth metric, 2022 removed the elite tier in favor of three clusters, and the current DORA guide presents five, with failed deployment recovery time and deployment rework rate joining the keys. The framing survives every revision: speed and stability are measured together because the research finds they move together, not against each other.
Any introduction that skips the price is selling something. Microsoft’s own DevOps guidance is blunt: “without a shift to a DevOps culture within the organization and its people, you won’t gain the full benefits of DevOps.” The automation has to be built, and then maintained, because a pipeline nobody maintains becomes the new manual process. Monitoring is an ongoing commitment, not a purchase. The deepest cost is organizational: shared ownership means changes in who decides, who is on call, and who is blamed when production breaks. What the trade buys is faster feedback loops and shared ownership; what it costs is real change in how the organization works. Teams that treat DevOps as a tooling line item typically buy the tools and keep the wall.What does DevOps cost?
Three corrections carry most of the value, because most introductions get them wrong. First, retire the habit of labeling every plan driven project a waterfall run: lifecycle and model are different nouns, the SDLC names the phases, waterfall is merely one ordering of them, and blurring the two hides that agile and iterative approaches traverse the same phases. Second, the build holds no guaranteed title to longest phase; it is a common pattern before release and no more, while the documented claim to longest belongs to maintenance. Third, the maintenance standard counts four categories, and the routinely dropped fourth is preventive: remedying weaknesses before they turn into incidents, which is also the activity closest to what DevOps asks of a team daily. One more caution: resist attaching a date to the motto “you build it, you run it.” Sources credit Werner Vogels with it, but none supplies a year, so any dated telling is embellishment.Which DevOps gotchas should you avoid?
Walked sequentially, the traditional SDLC concentrates risk at the far end, where feedback arrives late and corrections cost most. The history is less tidy than the mythology: the author credited with the staircase objected to his own diagram, and the work after release dominates lifetime cost. Each structural failure has a structural answer, from shared ownership to infrastructure as code, and DORA’s metrics make the promised gains checkable. The transformation is cultural, and culture is the expensive part.
Board 13 of 13: the recap. Five cracks, five answers, one price: culture change.
Continue learning
- DevOps Interview Questions and Answers: Topic Guide: test yourself on the concepts this episode introduced, from the lifecycle to monitoring.
- CICD Interview Questions and Answers for 2026: go deeper on the integration and delivery practices that answer the long wait.
- AI History: Booms, Winters, and Revivals: the previous Whiteboard Architect companion, on the cycles behind today’s AI wave.
This lesson first appeared on iqraa.tech.
More whiteboard lessons on the Whiteboard Architect YouTube channel.
Top comments (0)