Does the World of Waterfall and Heavy Governance Need an Integrated Platform? A Long Answer to a Question from the SI Field

A while back I demoed for a team preparing to rebuild, after 25 years, one of the five largest systems in Korea. Nobody in the room needed DevOps explained. The meeting opened like this:

"Our CI/CD is structured. Delivery is fully automated through a toolchain. We have the tools and the knowledge. Skip the concepts. Tell us what gets added on top."

And near the end, the PM leading the project summed up their position:

"We don't do agile in SI. Requirements analysis, design, implementation: traditional waterfall. We spend a year on planning alone, and governance is very strict. Our real concern is handing what we manage over to the development and operations organizations."

I kept turning that question over on the way back. It's a challenging question, but a fair one, and a fair question deserves a longer answer than the one you can give in the room. This is that answer.

Taking the question apart

"Do we really need this?" actually stands on three premises.

1. We're waterfall, not agile, and isn't this an agile tool?
2. We already own all the tools, so what's left to buy?
3. Our governance is already strict. Isn't management already covered?

If all three premises hold, so does the conclusion: you don't need us. So let's examine them one at a time. I'll say upfront that I think all three have problems, and interestingly, the most important clue sits in the word they brought up themselves at the end: handover.

Premise 1. "This is an agile tool"

This premise confuses categories. Agile is a methodology. DevOps is infrastructure.

CI pipelines, source control, automated deployment, change traceability: none of these presuppose two-week iterations. A commit triggering a build producing an artifact doesn't ask whether the work item came from a backlog or a WBS. If the sprint board doesn't fit, don't use it. Some of our customers have never turned the sprint feature on, not once.

That much clears up the category confusion. The more important observation is this: waterfall is precisely the methodology where the absence of this infrastructure blows up most expensively.

Waterfall structurally defers integration risk. Two to three hundred engineers build their own modules for over a year, and the system comes together for the first time in the test phase. The integration cost an agile organization pays in two-week installments, a waterfall organization pays as a lump sum, in the most compressed stretch of the entire project. Without daily builds and an automated integration pipeline in that stretch, the period labeled "testing" on the plan becomes, in practice, the period of discovering integration failures for the first time. Nobody who has worked in this industry long enough has been spared that sight.

So the causality runs opposite to the common assumption. You don't do CI/CD because you're agile. Waterfall without CI/CD is the most dangerous combination there is.

Of course, this organization has CI/CD. So setting premise 1 aside doesn't settle their question. The real argument starts now.

Premise 2. "We already own all the tools"

True. They have an issue tracker, repositories, a CI server, deployment automation. Put the feature lists side by side and there aren't many boxes we can add.

But the premise carries a hidden assumption: that the sum of the tools equals a platform. I think that's wrong.

With N tools, there are up to N×(N−1)/2 integration points between them. Five tools, ten points. Each point demands API tokens, webhooks, schema mappings, and above all, someone to maintain it. On a three-year project, those ten seams get three full years of opportunities to break. One tool ships a version bump and the integrations around it wobble. The labor of wiring and re-wiring these seams exists in every organization, and appears on no organization's org chart.

An issue tracker only knows the territory it owns. CI has no idea what the deploy tool is doing; the deploy tool has no idea which requirements shipped alongside. Each tool running fine on its own and the context between them being connected are entirely different things. The former you can buy. The latter you cannot.

At this point someone else in the room raised a good objection: "Bundling is fine, but some teams only need issue management. Isn't this overkill for them?"

My answer was this: adoption can be partial. Integration cannot.

A team that only needs issues should use only issues; unused features simply don't appear. But the difference between "an issue tracker" and "an issue tracker on a shared graph" shows up the day another team's pipeline needs to reference that team's issues. A failed deployment auto-linking to its issue, a change-request approval acting as a pipeline gate: these hold only when the pieces share a plane, and they cannot be retrofitted later through integrations. Features can be added afterwards, but this kind of property either exists from the start or it doesn't.

Which is why an unused capability is not a cost but an option: when the organization changes, when the methodology shifts (say, agile elements creeping into the operations phase after the rebuild), nothing about the tooling or the data has to be torn out.

Premise 3. "Our governance is already strict"

This premise is the most interesting one, because it's true. And the fact that it's true is what ends up flipping the math.

Strict governance is, in the end, a system of evidence. Which requirement changed, when, why, and who approved it. Which review gate a change passed. Which sign-off chain produced the version now in production. When an audit arrives these questions must be answered, and this organization does answer them. The question is how.

I've watched that answer get produced in fragmented environments, more than once. Someone screenshots the issue tracker, exports commit logs from the repository, pulls build history off the CI server, digs approval documents out of the workflow system, and stitches it all together by hand in a spreadsheet. Evidence breaks once at every boundary between tools, and every break is bridged by somebody's overtime.

Which leads to what is probably the most important sentence in this essay: on a fragmented toolchain, governance gets more expensive in exact proportion to how strict it is. Strict governance is not evidence that you don't need an integrated platform. It's evidence that you're paying that much more in fragmentation tax.

If requirement → change request → approval → commit → build → deployment are connected events on one graph from the start, evidence is not an artifact you produce but a byproduct of doing the work. Audit response turns from a documentation project into a query. This is not an argument for relaxing governance. It's an argument for making the same strictness a property of the system instead of an exercise of human discipline.

The year-long planning phase has the same structure. The requirements definitions and design decisions produced in that year begin to age the moment they freeze as snapshots on a document server. Requirements change during implementation. They always do. Each time, the distance between document and code grows, and the number of people who know that distance shrinks. Planning artifacts connected to the execution graph mean that three years later, the answer to "why does this code look like this?" is still a few clicks away.

And the word they brought up themselves — handover

Everything so far answers the question they asked. What follows answers the one they didn't: the concern the PM named at the end.

The last phase of a waterfall SI project is not deployment. It is an inter-organizational transfer of context. The moment a system built by 300 people over three years passes to the operations organization, the organization that built it dissolves. The people maintaining the system for the next decade will face exactly the same questions as the auditors above (which requirement produced this screen, which incident drove the last change to this module), except this time, nobody left in the building knows the answers.

In a fragmented environment those answers exist as snapshots somewhere in the handover documentation. The documents are already stale on the day of transfer, and their authors have moved on to the next project. The operations organization inherits, along with the system, the job of rediscovering those answers from scratch.

When context lives on one graph, the nature of handover itself changes. It stops being a ceremony of delivering artifacts and becomes a procedure of transferring access to living context. For a once-in-25-years rebuild, the stakes double: the context accumulated in this project is the maintenance asset for the next 25 years. Will that asset survive as document and spreadsheet snapshots, or as a graph that traces from issue down to commit and build log?

Even an organization unmoved by everything I said about premises 1 through 3 will, I think, run the numbers differently in front of handover. An integrated plane has one thing no combination of individual tools can replicate: it can be handed over whole.

What we can't do

For this argument to earn trust, its limits deserve the same precision. These are things we conceded in that meeting.

The platform cannot independently verify what is actually running in production. It knows what the pipeline shipped, but observing the true state of the runtime is a structurally different problem. Our limitation, and every CI/CD platform's limitation.

It doesn't replace methodology either. How to cut the phases and where to place the gates remains the organization's judgment. The platform's job starts after that judgment is made.

And how much better do things get in the stretch where 200 people work in a compressed crunch? That's a matter of measurement. We have figures from using our own product, but no figures yet from an SI floor at that scale. Something to measure in a pilot, not to claim in a meeting.

Where the three premises converge

Back to the three premises. "Isn't this an agile tool" was a category error; waterfall needs this infrastructure more desperately than anyone. "We own all the tools" confused the sum of tools with a plane, and the difference gets invoiced for three straight years alongside the integration matrix. "Our governance is strict" is true, and on a fragmented toolchain, that strictness gets more expensive precisely as it grows. All of it converges on handover: in an industry where the building organization dissolves at the end, few infrastructure decisions matter more than accumulating context in a form that can be handed over.

You don't have to change your methodology. What has to change is the condition where context lives only in people's memories and document snapshots.