“Let’s just start fresh.”
In the arena of COBOL application modernization, these words have been uttered many times over the years by technologists, business executives, and even board directors. While the phrase does have great power to lift the spirits (at least for a while) of everyone involved in a big, complex project, at CloudFrame we’ve seen the longer-term results of such “new starts” often enough to know that deeper consideration is warranted before embarking on one.
In this multi-part series, we’ll explore why organizations feel the need to go “greenfield”, where such projects most often go wrong—and whether a better way exists.
The challenge of application modernization is, in a very real sense, a business problem rather than purely a technology problem. The need for modernization typically arises as a corollary of a wider program of digital transformation—in short, it becomes urgent when everything else around the application has modernized already. Things have changed since the application was originally designed and implemented, often decades ago: customers have different expectations, competitors have different offerings, internal processes have evolved, and regulations have been rewritten.
Why greenfield?
A legacy application, though, is like a battleship sunk in a tropical sea: over decades, a vast and complex reef of interdependencies and modifications grows on and around it as accrued technical debt keeps it weighted steadfastly in place. The challenge for the project team is often daunting, as the original coders may have long since retired, documentation may vary widely in quality or availability, and the long list of requirements it was built to fulfill may be partially forgotten. What’s more, it’s often the case that fundamental data structures are no longer relevant, and so on top of the application modernization, a long (and likely painful) data migration will also be required.
Where even to begin? And how to judge the risks as you proceed?
Naturally, most organizations start by considering a range of options. They may look at simpler (though lower-impact) alternatives like encapsulating certain functions and their data within APIs—thus easing future integrations with other systems—or rehosting the legacy application on faster and more accessible infrastructure. Many of these options, though, are merely stop gaps, and while they minimize risk, they fail to create the transformative impact expected from full modernization.
Starting over with a clean sheet of paper is thus extremely tempting. It means—so goes the logic—that instead of attempting to fully understand and then manually transform old COBOL into new Java (a typical choice today), a team can skip all that risk and effort and instead do something that they’re familiar with and can control: specifying requirements and building an application to meet them. Architects love this too, seeing it as a way of ridding the organization of a huge amount of technical debt and inflexibility. And as for program managers, well, there are few who can resist being able to present an attractively-positive-ROI project to their executive leads—and on a spreadsheet, greenfield projects promise exactly this.
Risks Abound
All too often, though, greenfield is a siren song, tempting—but full of its own variety of risks. To get a sense of them, try for a moment to flip the perspective. Instead of seeing a legacy COBOL application as merely a thing that needs to be modernized, see it as a fully-functioning machine that met all the requirements of its makers—certified before it moved into production and validated extensively afterward. The application has had all its rough edges smoothed away through steady incremental modifications over a long span of time.
This validated, evolved, and polished system, inflexible though it may be in the present year, is what a greenfield team is attempting to build fresh.
The risks that spawn from this basic truth include severe estimation errors, unidentified (but often critical) requirements going unmet, poorly understood interdependencies with other applications and data stores, and even the emergence of competitive threats that can’t be addressed while the project pushes slowly along, monopolizing the attention of the team as it does so.
A final risk to consider: like any big project with a significant amount of investment dollars and executive buy-in behind it, a greenfield application modernization effort has its own hard-to-stop momentum, and by the time a program manager has realized that the wrong approach has been picked, it might be too late to redirect it. “Damn the torpedoes. Full Speed!”
In our next post, we’ll help you get ahead of this hard-to-stop momentum by unpacking the various ways greenfield projects can go wrong.
