In our previous post, we covered the most common reasons why an enterprise faced with a COBOL application modernization challenge might choose to start again from scratch with a “greenfield” requirement, design, and build project. We mentioned some of the risks arising from this approach, and in this second part of our series, we’ll take a closer look at these. Forewarned is forearmed, and being able to understand and explain the potential dangers of greenfield may help you direct your organization towards alternatives with better risk-reward trade-offs.
Requirements uncertainty
“What exactly are we replacing?” is a more complicated question than it seems. Most COBOL systems that are candidates for modernization have had operating lives measured in decades, and many things have happened during those years: original documentation gets buried in the archives (or thrown out in office moves), developers and project sponsors leave for other opportunities or retire, and tweaking and performance tuning have been going on since it was first implemented.
Applications are artifacts that embody the knowledge and assumptions of an organization. When starting fresh, there’s a real risk that much of that will be lost if the system itself is the only remaining reference point. What did the application builders assume that we forget to think about now?
While requirements gathering for greenfield modernization remains an essential step, it is fraught with uncertainties and difficult-to-answer questions: What were the original requirements of the system? Were they all written down, or were some of them tacitly “understood”? Are all of the requirements still valid today? And how do requirements freshly gathered from today’s users map to the system’s actual functionality—in other words, does what seems like a net new requirement imply that a module should be built to order without reference to the old system, or was that requirement addressed by some feature of the original system, or via a forgotten interdependency with a different system?
Estimation errors
Naturally, such uncertainties make estimation a much more difficult task. Technologists are an inherently optimistic group to begin with, and their program managers all too frequently tend to gloss over delivery risks in the quest to present executives with projects featuring attractive returns on investment.
The unique complexities of greenfield modernizations add to this in-built estimation risk: not only are the requirements themselves hard to uncover and hard to lock down with any sense of comprehensiveness, but the sheer scale of such programs generates uncertainty through the variety of data types, data models, processes, and code functions that have to be addressed, and through the usually unexpected breadth and depth of the testing and validation efforts that will be required to certify a brand-new and mission-critical system.
Consistency challenges
Because of their size, greenfield modernization programs are often broken into distinct projects defined by the functional areas of the original code they’re intended to tackle. Yet while this makes the whole program more manageable, the fact that different design and coding teams may be used on other projects means that how the COBOL is analyzed, understood, and then re-expressed in a modern language may vary significantly. What began as a single huge COBOL application may find itself reincarnated, for example, as an array of microservices built with a hodgepodge of styles and assumptions—a set of puzzle pieces that might not all fit perfectly together.
Opportunity costs
A final risk is more subtle—but it can be devastating. Greenfield modernization programs are typically massive in scale and duration. As they proceed, they command a large percentage of an organization’s technical and business analytical resources and focus a large proportion of its executives’ attention. While all that focused effort is happening, the world is not sitting still. Markets are evolving, new competitors are emerging, and customer expectations are changing. Being able to respond to these shifts promptly can mean the difference between running a profitable, growing business and piloting an also-ran into irrelevance.
Time matters: modernizing a mission-critical application is important, but it’s just as important to accomplish it swiftly and with minimal burdens on the organization’s overall capabilities.
The Greenfield Decision
When an application modernization must happen, decision-makers must analyze the full range of options available to them and carefully balance factors of uncertainty, consistency, complexity, and opportunity cost. The “clarity” of greenfield is indeed tempting—but it’s too often an expensive and distracting illusion.
In our final post, we’ll discuss an approach that we believe offers, in most situations, a better balance.
