Old COBOL Dog, New JSON, XML and Mobile Workload Tricks
What is an old dog? What is a new trick? If COBOL were a human, its 61 years might make it seem eligible for early retirement. But something strange has been happening in the world of established business technology, beginning with the non-retirement of highly-experienced technologists.
Yes, there are plenty of people who have followed the traditional path and are moving on to less technological pursuits. But there are also many people who are sticking around, as they discover that they never actually had a “best before date” and they just keep getting better. Superannuated technologists, who either aren’t retiring, or else are coming back as consultants to continue their careers after this ostensible milestone, are keeping the worlds of COBOL and mainframe running even as a new generation begins to arrive.
Perhaps that suggests that the capacity to keep learning new tricks means that the dog isn’t so old after all?
We need to stop imposing arbitrary ceilings on value that keeps increasing with no signs of stagnation, whether it’s technologists who are entering a time of deep and effective practical wisdom in their careers, or technologies that are showing themselves to be built for the ages, with no discernible expiry date.
Rear Admiral Dr. Grace Murray Hopper is reputed to have said something like, “I don’t know what the language of the future will look like, but I know it will be called COBOL.” So far, her visionary wisdom seems to be holding, as a language designed for the ages continues to remain young at heart but as solidly established as the roads that still lead to Rome.
COBOL and the Wheel: Intrinsic Revolutions
In many ways, the creation of COBOL was like the invention of the wheel. It took into account all the requirements for high-volume, high-quality business processing, with a measure-twice-cut-once attitude, such that it nailed the business processing space, leaving other languages to seek new niches where they could develop different sets of strengths. But, of course, there’s wheels, and then there’s wheels. A modern electric sports car still sports wheels, but so much innovation is riding on them that the original concept of wooden wheels is more of a prefigurement than a viable alternative (as the good folks at Mythbusters demonstrated so well).
As it turns out, the wheel is intrinsically revolutionary, and once the paradigm for continuous motion was established in the transportation infrastructure, finding ever-new value in this technology for the ages was more than mere spin.
Likewise with COBOL, it built a niche for itself with careful research and design and fit for business purpose, and then became the recipient of custom infrastructure that was designed to meet the same purposes, such as the IBM System/360 mainframe and its successors, including the modern IBM Z platform, designed to meet the same business processing quality and volume challenges in a deeply compatible way.
Interacting With JSON, to XML to Mobile Computing
Of course, having the infrastructure and the vehicle, the world kept moving forward. And so has COBOL, as it continues to advance to interact with new technologies of business relevance from JSON and XML to mobile computing.
But at the end of the day, it’s all business—COBOL’s middle name. We call them workloads because they’re not mere bells-and-whistles distractions. We need a solid, proven way to continue to build business value as the world of business keeps taking up every new opportunity to competitively use new technological approaches to get new business value. And, just like building on the concept of the wheel, so business computing builds on the established paradigms and applications of business that predate electronic computing, and were so well manifested in the “legacy” COBOL applications that have borne the mantel of running the world’s business, and are now foundational to further innovations.
Of course, neither COBOL nor the IBM Z mainframe are islands: They exist in a universe of technology and business where we choose “horses for courses,” (i.e. making sure the means suit the purposes) so an app that sits on a smart phone and talks over the internet to a server and service may be written in a locally optimal language. And it may well be talking XML or JSON to that server. But as it reaches out to shake the hand of the server that has the data and processing to get world-class results, if it’s working well, it may well be talking to a COBOL application, possibly running under CICS on the IBM Z mainframe.
As we look at the alternative to this configuration, it often involves inserting an intermediary application that works with the same data and applications on the central server, either querying them real time, or making regular copies of their data. If the system of record is written in COBOL, inserting an additional link in the chain may not be optimal if the conversation can be tuned to be a direct connection.
Bringing New Applications to COBOL
For all of these reasons, business that do their homework are bringing new applications to COBOL and established servers such as IBM Z, talking to the distributed platforms using smart phone apps or browsers or other clients, and knowing they have a proven, secure, reliable source for the data and applications that keep the business moving forward.
Given that realization, there is a corollary opportunity that is emerging: Move off of disproven intermediary systems that just provide a lower-quality redirection link. Recode their behaviors in COBOL directly on the mainframe, to take advantage of all of its qualities of service, cost-benefits advantage, security and the performance and reliability that come with centralizing on a proven performer that has annual unplanned downtime measured in seconds and mean time between failure measured in centuries. And do it with a language that is likewise proven to think and act like it means business.