Horses for Courses: Choosing the Right Player, Platform and Tool in the COBOL World
“OCCURS DEPENDING ON” is a wonderful clause in COBOL that resonates powerfully with a favorite answer that IBMers like to give to big, generic questions about how to choose and configure their technology: “It depends … ”
In the first case, the programmer may be asking for arrays, while in the latter the IBMer is likely asking to appraise the details before raising the stakes with a specific recommendation.
Of course, that’s the thing about world-class computing configurations: they’re not generic, and treating them as homogenous and undifferentiated is a recipe for disaster, or at least cost overruns and functional insufficiency of the kind that falls far short of any QoS parameters that should have been documented and required beforehand.
Beyond that, however, there is another dimension that may have been imagined but could not be reliably projected at the beginning of the journey of electronic computing: time. You know: that thing that turns quality into legacy. And also that thing that specifies which horse wins a race. Now, after winning a few races, a horse may retire to a more leisurely lifestyle. But a technology that wins just keeps on keeping on.
Besides, the term “horses for courses” is used more often as an analogy than advice about choosing race horses for the right race courses. The concept is pretty simple: choose the right player, platform, tool, what-have-you, to suit the purpose you wish to achieve.
That’s important, partly because it points out that when you start with generic requirements, until you work through them to establish a clear picture and measurement of what you’re trying to achieve, it will be rather difficult to have a measurable success.
Bring all of these together, and we have something more than just a snapshot picture of a successfully completed project because, again, unlike a horse race, success is just the beginning of a computer system or application. And what may have begun as a successfully-concluded project can become the foundation and progenitor of many future innovations and initiatives.
As we employ our hindsight, things may seem to make more sense than they did at the planning stage, but those technologies that were designed and planned with quality and qualities to last give a new meaning to the old saw, “nice guys finish last.” They’re the ones that saw the competition finish and wind down, while they still have the wind in their sails and wind up continuing to lead the charge into the future, as the finishing touches of each ending herald a new beginning.
COBOL Incumbency
In other words, a lasting legacy. When you choose an approach, a platform, a database management system, and a programming language, it’s a dangerous illusion to think it’s an isolated one-off. Nothing succeeds like success, and when a system is successfully designed, we have discovered for over half a century that it may be here for the ages, both in terms of its original design, and in terms of everything else that will be developed with reference to it—connectors, enhancements … and new applications that will mimic it and build on the lessons learned, in a large-scale homage to code reuse.
All of that is the first reason why COBOL is running the world economy. In a word: incumbency. It got there, it worked, it kept on working. There aren’t enough programmer hours in the world to rewrite all the COBOL that works perfectly fine into an unproven language and platform.
Different Language, Different Purpose
BUT: what about all the stuff that isn’t in COBOL yet? Or even stuff that maybe no longer needs to be?
There are workloads that are more readily designed in a language fit for a different purpose. If real-time graphical interaction with a user in a gaming environment is needed, then a dedicated consumer electronics platform using a language that is meant to enable such interaction is likely a better choice than COBOL on enterprise servers. (But feel free to prove me wrong.)
And there are also workloads that were designed a long time ago in COBOL on enterprise servers, that don’t have any local proprietary or competitive uniqueness, and may beneficially be replaced by off-the-shelf commercial software such as ERP solutions which are kept up-to-date with respect to modern functionality and customer demand. Your technologists’ time is better spent on unique business value that is specific to your organization’s needs than on reinventing a wheel that is commercially available for less cost and ongoing effort.
Similarly, you may have COBOL programs doing low-importance tasks that were written back when that seemed like the only alternative. If what they’re doing is not focused on quality, reliability and massive amounts of data, then if there’s not an off-the-shelf replacement available, it may make sense to consider moving them to smaller platforms and rewriting them in languages for which the programmers are available a dime-a-dozen. Of course, that assumes you still know what those programs do well enough to fully rewrite them in a cost-beneficially finite amount of time. Then again, if they’re that unimportant and obscure, it may make more sense to just deprecate them.
The pressures on the mainframe and COBOL over the past few decades have trimmed off a lot of the low-hanging fruit. But once you’ve eliminated the “road apples” that are no longer suited to your thoroughbred enterprise IT environment, it’s also time to feed it some golden apples that are of such a quality and strategic position that they’ll enhance your standing by being written in a language and on a platform designed for the ages.
Conduct a Cost-Benefit Analysis
To be clear, it’s very expensive to rewrite an application to move it to a new language and platform, so a careful cost-benefits analysis is needed before moving any legacy that works somewhere new where it will have to get the bugs out all over again. And that’s true for distributed non-COBOL applications too. Then again, we should have been doing that level of cost-benefits analysis all along. Still, if you’re struggling along with a burgeoning, ponderous distributed application that seems to be hitting a ceiling in terms of capacity, performance and functionality, then it may well be time to consider doing it right the second time.
But if you’re building a new application the first time, even if you’re doing it in a greenfield environment where you have no idea what it will do or how it will develop, and there are no similar examples to learn from, if it’s big and strategic, it makes sense to ponder the future dimensions and trajectories of such a system. And if it’s meant for more than just show, then rather than choosing a second-place platform and language, why not start by aiming for a win?