Business Logic
Dooley sees recompiling for Cobol.Net as a way to facilitate integration of Harland's back-office Cobol applications with front-end programs that are written in .Net languages. “If we get it into Cobol.Net, then the Visual Basic .Net application can call the same routines ... without having to jump through hoops,” he says. New interactive online applications, such as a Harland's delinquent-loan system, are written entirely in native .Net languages. With the rest of the Cobol in the .Net fold, he says, “we can make better decisions of where we can move business logic.”
Attorneys' Title Insurance Fund Inc. in Orlando is rewriting nearly 2,000 back-end mainframe Cobol programs in C#, a process that senior analyst Kirk Gagnon expects to take three to five years. To do that, the firm is outsourcing maintenance of the system in order to free up the mainframe support staff to train on .Net tools and products including Visual Studio, BizTalk and MSMQ-MQSeries Bridge software. “We're streamlining everything into one common set of software,” he says.
But even with skilled mainframe programmers at the helm, the project represents a big leap. “We haven't done anything this large before,” Gagnon says.
Migrating off the mainframe and rewriting the code at the same time can be “a recipe for disaster,” says Vecchio. He notes that the desire to move away from Cobol is most often driven by one of three factors: the desire to reduce total cost of ownership, a need to address the perceived Cobol skills deficit or the mistaken belief that the only way to attain business agility is to move off Cobol entirely.
Hirsch is taking it one step at a time, first migrating off the mainframe and porting the Cobol programs with as few changes as possible. From there, programs should be reassessed, not just rewritten, Vecchio says. “You need to rethink, How do I perform that function? not just, How do I do it in the same way on a new platform?” he says.
“Why would anyone ever write an application from scratch when there are so many ways to deliver pieces and parts of that?” Vecchio asks. Some programs may not be needed, while others can be eliminated by moving to packaged applications. Business process management tools and rules engines can be used to replace still others.
And perhaps, just maybe, some programs, such as those used in batch processing, should be recompiled and modernized in Cobol. “There are environments where thinking procedurally is better,” Vecchio says.
Just because your front end is object-oriented doesn't mean the back end needs to be as well, says Crego. "You could have a different language on the front end being very interactive, and on the back end, you could have a robust business language, and there's no reason why Cobol wouldn't fit into that space" he says.
Is Cobol dead? Not by a long shot, says Vecchio, but it's likely to continue its long, slow decline. Once center stage in state-of-the-art computing, the language is no longer the focus of innovation in business. “New packages and programs aren't being developed . Skills are declining. All of these things are working against a resurgence,” he says.
Organizations should plan to move off Cobol at some point, but that possibility shouldn't be the driving force behind any decisions.
"Focus on what is best for your organization, not what is the hot technology right now. That doesn't mean that the hot technology isn't where you want to get eventually" Swift says. But business process needs, not the choice of programming language, should dictate when to make such a move.
Related News and Opinion:
• Weekly I/O: Podcast interview with Robert Mitchell about the Cobol article
• Robert L. Mitchell: Cobol not so procedural after all
• Sound Off: Cobol versus Java and C#
• Robert L. Mitchell: How they learned to stop worrying and love Cobol
• Martin MC Brown: 10 programming languages to learn
• Shark Tank: Think Global, Act Loco