Slashdot Mirror
Modernizing the Common Language - COBOL
Frumious Wombat writes "Over at the Register Developers section, they are quoting the head of research for Ovum Consulting on the continuing dominance of COBOL in certain business applications. The antique language accounted for 75% of all business transactions last year, and some 90% of financial transactions. For all the time spent arguing the merits of Ruby vs. C#, should the community spend more time building tools to make COBOL livable? The article goes into what it terms 'legacy modernization', and lays out some details on how to go about it. From the article: 'The first stage in the legacy modernization process is to understand the business value embodied within legacy systems. This means that developers must give business domain experts (business analysts) access to the legacy, using tools that help them find their way around it at the business level. Some awareness of, say, COBOL and of the legacy architectures will be helpful but we aren't talking about programmers rooting around in code - modern tools can automate much of this analysis for staff working at a higher level.'"
The key limitation of COBOL systems are two-fold:
The main hurdle I've found when dealing with Mainframe apps are the lack of either (or both) of these. You find these monolithic COBOL systems that have been continuously updated for over 20 years and nobody knows exactly what they do.
What's more, 20 years of changes always involves some serious "Business Logic" changes. So the data is often kludged, with pre-1995 data treated differently from pre-2000 data, treated differently from current data. What's more, there are usually about 2 people who actually "remember" all of the changes, but it was never written down, so it's stored in the deep recesses of their brain. And since 1994 was the year that docs were still written in WordPerfect for DOS, you don't have electronic copies of anything unless you can find a dusty printout in an old binder somewhere.
Oh yeah, and the two people who have been there for 20 years. They're too busy to really impart their knowledge to the batch of people replacing the system. And really, why do they want to obsolete themselves? Why go outside of their comfort zone? Why write all of these documents and undergo this whole process when the current system "works just fine" and I only have 5 years to retirement?
So what's the reality? Most companies I've met have been taking shortcuts on their development processes for years. They kludge the code, fail to clean up, fail to date (or sometimes even comment) code and then they fail to document all of the changes.
As we all know that these shortcuts save time now at the expense of time later. Well if you've been writing cheques from the "later" account (as most companies are wont to do), then you're eventually so far behind that you simply can't recover.
Let's face it, if you had an exact spec for the functioning of your COBOL system, then conversion would not be a big deal. It would be time-consuming, but it wouldn't be "hard". But if you don't have a spec, then programming is not the issue at all. Without the spec all you have is a system with [un]known bugs and 20 years of vaguely understood changes.
I've heard of people developing systems to refactor COBOL code, but this is just another kludge. Porting code just gives you bad code in another language, the goal is always to port concepts, which is why domain experts are so key.
So basically, without Domain Experts and quality Documentation, COBOL systems will continue to exist. Without these two pieces the "upgrade" is basically impossible.