I just saw this interesting story in Data Center Journal that evokes images of "It's a Wonderful Life," the story where despondent savings & loan manager George Bailey is provided a glimpse of what the world would be like without him -- it would have been a bleaker, raunchier world.
Apparently, the same could be said of COBOL -- we would be muddling along in a world without ATMs, credit cards, reservation systems, and point-of-sale systems.
COBOL has long been relegated to the back rooms of IT, but it still powers much of today's infrastructure. It would have been messy and expensive to try to throw it all away to move onto newer languages. But service oriented architecture now makes it feasible to surface COBOL-based applications as services within newer architectures and newer applications.
Apparently, the same could be said of COBOL -- we would be muddling along in a world without ATMs, credit cards, reservation systems, and point-of-sale systems.
COBOL has long been relegated to the back rooms of IT, but it still powers much of today's infrastructure. It would have been messy and expensive to try to throw it all away to move onto newer languages. But service oriented architecture now makes it feasible to surface COBOL-based applications as services within newer architectures and newer applications.
Isn't it time to replace the critical business logic in these systems with something useful (like business rules) so it can be maintained, even if we keep the majority of the system running on COBOL? Time, perhaps, to make a meal from our mainframe leftovers?
JT
I am by no means a fan of COBOL, however, it is quite clear that many of these COBOL programs have been the back bone of many organizations for the last 40 years. They have been developed and tested over the years and contain well proven logic that performs under incredible loads in some cases.
I find it incredible that someone would comment that these systems should be replaced with 'something useful'. Many attempts have been made to replace COBOL systems over the years and have failed miserably for many reasons including the cost of redevelopment (sometimes they do a lot more than it looks like they do) but ultimately because most of the newer technologies simply cannot handle the load and throughput that these COBOL programs can sustain.
Finding a middle ground, I believe the answer lies in reusing this existing COBOL logic using services (I would argue standards based services) to disconnect the front end processing from the back office stuff where the COBOL normally resides. This then gives the option to replace the back office implementation with something else where this makes sense. My view is that if something can be reused easily and does a good job, why rewrite for the sake of rewriting it ? Surely there are plenty of other tasks that can add business value without simply replacing something because it's COBOL ?
Even if there is a need to replace cobol, replace it with Java running on Mainframes, thats the most effective way of running anything. When you take a look at the over all cost, and plus with the new cost initiatives by IBM on z platform, it is going to be very good.
HP and other servers are good, but not as great. z is the ultimate thing.