The intersection of sixty-year old Cobol baby boomers and a forty-year old computer architecture
by
Tom Hill
Next year some baby boomer Cobol programmers will celebrate their sixtieth birthday and the IBM 360 mainframe architecture will have endured for just over two thirds of those sixty years. In other words, programmers around the world have been creating a legacy of mission critical business applications, under the same standard language and architecture for over forty years. Business applications represent the implementation of an enterprise’s business models. In many cases the application programs, running on a forty-year-old architecture, represent the only written documentation of the business rules that enforce an enterprise’s most critical business functions.
I jest with many of my IT peers, when they suggest that we develop business rules for our customers, and maybe we need to create a standard language for this purpose. Hmmm… a common business oriented language makes perfect sense. Let’s do it and call it COBOL.
Every couple of years, the IT press laments about what will happen when we run out of aging Cobol programmers. “…It’s another Y2K crisis, all Cobol systems will stop running as our programmers retire...” This will not happen. We will always be able to train people to code in any programming language. If the economics are right they will be educated and replace an aging workforce.
Business leaders, responsible for the growth of their corporations, should be concerned about two open questions:
- Will the sole provider of the 40 year old architecture forego its powerful position and provide multiple open-architecture upgrade paths for continued operation and growth? Architecture flexibility is required to reduce operational risk.
- As experienced Cobol business analysts leave the workforce, who will maintain that essential link between your critical business processes and your critical business applications? The essential link is necessary to maintain and grow applications in a competitive business marketplace.
Multiple answers have been proposed to reduce the danger that these two questions bring forward. I only see a few practical solutions and recommendations to minimize this intersection of risks:
- Architecture-to-architecture transformation tools are becoming Cobol-ready. Find a large corporate mission-critical application, commit to transforming it, move it to a new open architecture, and operate it in a production environment. Understand the difficulty, the costs, and rewards of independence. Make a knowledgeable plan to mitigate the risk.
- Many of the transformation tools claim to extract business rules from Cobol applications. Use existing tools or create tools to mine critical application business rules and use your talented experienced Cobol business analysts to connect the rules to documented business processes. UML use-case diagrams provide one method of documenting the rules-to-processes connections.
I have to put some more thought into it – but we might just be able to extract the business rules and leave the rules in a Common Business Oriented Language as we attempt to connect them to our business processes. I think this would make a fitting legacy to Grace Murray Hopper. Any other suggestions?
