Stay with legacy applications or re-write them

Dear Bob …

I have read several articles lately with the author wringing his/her hands and stating that IT must move its core business logic off of its traditional language/database (COBOL, etc.) to a ‘newer’ language/database. That approach seems to be a non-starter with me. It is true, however, that many of the old line COBOL, IBM assembler, etc. programmers will be retiring in large numbers in the near future. So what’s a business to do?

My belief is that the business should select some of the brightest of its new hires. After explaining that someone needs to be proficient in these ‘ancient’ languages, the company should offer a career path and training (using the theory of ‘golden handcuffs’).

The key to me seems not to be the incredibly expensive process of rewriting the majority of the world’s business applications — but to connect those applications to a Web 2.0 world using people who are proficient (or even wizardly) on both sides of the fence.

So how would you approach this situation Bob? Would it be re-write (at whatever speed could be afforded), train, or just chuck it and start over?

– Old Coder

Dear O.C. …

This sort of question is never as simple as it appears at first glance, for both architectural and staffing reasons.

Architecture first: “COBOL” isn’t enough information. If the COBOL in question codes real-time transaction processing systems rather than being a batch architecture design … and if its logic is encapsulated into callable modules and accessible through CICS connectors of some kind rather than the usual COBOL in-line code … and if the application is well-structured and maintained (many older applications have accumulated a fair share of kludgey patches over the decades) … and if its ability to support both the current business and likely future strategies looks good … if all of this is in good shape, then yes, it makes architectural sense to stay with what you have.

Otherwise, it often makes more sense to go with configurable packaged solutions.

Now the staffing question, which I’ll answer with a question of my own: If you were on the receiving end of an offer like this, which asks you to accept golden handcuffs in exchange for investing in technological skills that are increasingly non-transferrable and that decrease your value in the IT labor marketplace, what kind of contractual guarantees would you ask for in exchange?

The history of corporate America over the past few decades would not lead a wise employee to take a deal like this on a handshake. If it were me, I’d be asking for lifetime employment, since in exchange I’d be volunteering myself for a one-way ticket to career jail.

Not that this is a challenge that’s easily dealt with. Quite the contrary: Since there is no new COBOL, CIOs have to operate on the assumption that most languages will have no more than about a decade of staying power. Nothing about this makes long-term architecture planning easy, which is one reason I lean toward packaged solutions as the logical course of action when one is available that fits your business requirements reasonably well.

It doesn’t fully address the challenge, but at least it makes it the vendor’s problem to solve.

– Bob