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.'"
This simply underlines the fact that there's a huge workload of easy, routine transactions that need to be done.
In terms of total complexity, the financial world is probably something like Excel 20%, C# 15%, Java 30%, C++ 30%, other 5%.
But in terms of transactions, I can well believe it's COBOL 70%, REXX/VB/4GLs 25%, other 5%.
Modelling a CDO *is* hard, and you don't do it in COBOL. Creating a visual system to monitor liquidity *is* hard and you don't do it in COBOL. 'Transactions' pure and simple are not hard... you can do them in COBOL... they're easy to maintain because changes are of the form 'deduct 5% if broker_country_of_incorporation = finland'... and they're also a darn silly way to measure the relevance of a language.
Whence? Hence. Whither? Thither.
Once you guys get jobs in the Real World, you will realize that businesses don't care about technology, they care about solutions.
No business person in their right mind would rewrite all their COBOL code into C or Java just for the sake of modernization. That would be foolish and stupid, and they would deserve to be fired from their jobs. Everything works, why change it. Financial institutions that have their entire livelihood based on these COBOL programs would rather upgrade their hardware and make THAT modern, but keep their legacy code. They already went through a multi-billion dollar fixing for the Y2K industry, that's more than enough for them. The next problem is either 2038 or 2050, when the Y2K issue is revisited because of how most companies implemented their "fix" (any date > 50 would be considered in the 21st century).
I was working at a bank during late 90s and during a building-wide Y2K meeting, one of the project managers was explaining to us how they implemented the solution. Someone in the crowd asked "Won't we go through this problem again in 2050?" He answered "Yes, but I'll be dead then, so I don't care."
That is how business people think... they care about solutions, they don't care about technology. Don't waste your time navel-gazing and trying to figure out brilliant ways of modernization COBOL, because no one who uses it cares. Keep your great ideas for the new ideas where the barrier to implementing new solutions and new technology is much lower.
You may be in touch with modern software principles but sadly you are out of touch with business principles. Ideology does not make a company money. And a company is about making money not writing code conforming to modern code design.
To make a business case for code change, you need to back up your reasoning by showing how it will either 1) save the company money within 5 years or less (including paying off all the money spent for the code upgrade which at large companies could run into hundreds of millions of dollars) or 2) earn more money for the company (including paying for the code changes) within 5 years or less. You could argue that these are the same things but I look at them differently as one causes earnings to increase indirectly through savings, and the other directly though increased revenue.
If you can't do either, then forget it. If you don't understand why, think about where your paycheque comes from and how the company is going to be able to afford to pay you to work on no-gain projects. If you don't want to understand why, then stay a coder... not even an analyst, stay a coder. You must justify the costs of these kinds of expenditures. Now it is possible and even likely that someone was able to justify the costs of fixing design issues on projects you worked on. However, in corporate life, wholesale 'fixing' of 30 or 40 year old stable code is not usually justifiable for design sake alone.
For example on on projects I have worked on where large companies have modernized their systems (often replacing Cobol code) it always involved monetary reasons. Many times Cobol systems are built on other Cobol systems, which are built on other Cobol systems... Business domains begin crossing back and forth across system boundaries and things (for example customer service) become a nightmare. Take a customer order management process: Customer wants three things, it might take three systems to order it, two different customer service reps, and if something goes wrong, support has to track things across 3 systems. If you want to create a new product package it takes too much time to coordinate between systems and one or more might need programming changes which might mean data conversions if the interfaces change between the systems, etc. If the pain threshold gets to high by holding back the company in effectively competing because their systems piss the users off, piss the customers off, and hold back introduction of competitive products (in other words, if it is costing them more money keeping the old system than replacing it will cost), then they will consider replacing the old systems.
Since we are talking Cobol and financial transactions, we are talking *mostly* about the corporate world. When you are talking about large corporations, the cost to replace even an ordering and billing system can run well into the hundred million dollar range or more. Tens of millions is not uncommon either. Projects in the million dollar range are a dime a dozen in the corporate world.
Note: I don't particularly like Cobol... actually I don't like it period (I like C/C++/Java syntax better because I understadn it :-). But for me to justify something to a customer, it must solve a customers problem. The first thing to remember is their main problem is how to make more money. Period. It is not about supporting good code design. They could have something in place that was the worst coding job in the history of the planet, but if it makes them money it won't matter. Unless of course you can show them in concrete terms that a good design will pay for itself by directly or indirectly making them more money.
-- I ignore anonymous replies to my comments and postings.