Joe McKendrick in his Eye on the Enterprise blog had a post on legacy modernization – Time to Cut COBOL from Life Support in which he referenced a post by James McGovern The mainframe is not evil, but COBOL is… in which James says
that there’s no reason why aging COBOL apps can’t be replaced with Java. In fact, there’s no logical reason why IT shops are keeping COBOL going
And I completely agree – keep the mainframe, dump COBOL. But don’t just replace today’s legacy code (COBOL) with tomorrow’s (Java). Java may be more expressive than COBOL but it is still largely “syntactic, abbreviated, and procedural” as Ira Fuchs once said. The full quote contrasts today’s programming languages (including Java) with what is needed:
“Programming languages today remain syntactic, abbreviated, and procedural, as opposed to semantic, verbose, and declarative”
Well, of course, one of my favorite technologies (business rules) has a syntax that is semantic, verbose and declarative. That is, in fact, almost its definition. So rather than replace all the COBOL with Java, perhaps programmers should think about business rules more often. After all, there are many advantages of business rules over code, whether that code is COBOL or Java.
My suggestion would be to find the COBOL that represents business decisions such as a pricing engine (what price is this product for this customer), eligibility logic (is this customer eligible for this offer or service), approval rules (can this claim be auto-approved) and replace those parts of the application with Decision Services.
Such an approach is the last step in the decomposition of traditional applications. These COBOL applications we are replacing are monolithic – they contain data, user interfaces, business logic, and process flow in one block of code. We have come to understand that we should decompose these applications – managing data in a database that runs across applications, using portals and other clients to manage the user interface across applications and, a BPMS to externalize workflow and build cross-application flows effectively. Before we replace what’s left with Java we should take one more step – separating out the decisions and managing them so they too can be shared across applications.
Thus we should replace
- workflow and state management COBOL with a BPMS
- data management COBOL with SQL and a database
- decision logic COBOL with business rules
- just the remaining “plumbing” with Java.
That way you still get new languages, you improve business user control and you can still use the mainframe.So, don’t replace COBOL with Java, replace COBOL with a true composite of modern tools and manage your business processes, business decisions and plumbing in languages suited to each.
Comments on this entry are closed.
Although it is hard to disagree with the desire for something more modern than COBOL, the statement “there’s no reason why aging COBOL apps can’t be replaced” is emotionally based. If the software (COBOL or Java) is continuing to add business value at minimal maintenance costs, there are likely other investment avenues to pursue with greater ROI. It’s a business not a hobby. Hand-crafted code that has a limited resource pool for enhancements… calcifies the organizations ability to change, but there are so many opportunities and so few resources, we need to focus on what differentiates the organization, not on what feels good.
Charlie
You are, of course, right. I blogged about this in a post about the making of meals from leftovers (https://jtonedm.com/2008/05/28/making-meals-from-your-mainframe-leftovers/). My point here was more that when you decide to replace COBOL, don’t just blindly re-code in Java.
OK, let’s say, just for giggles and grins, that we have a system that actually is written in COBOL and the upper management wants to replace it. What “language” would you suggest? You’ve already take the stand that Java is not a good idea, and you might be right; don’t know. BUT, what are the alternatives? C? C++? Ada? Scripting? (OK, I got a bit silly there, but you get the idea.)
So, let’s consider that a rulebased system, the engine itself, is nothing more than a compiler. The underlying language is irrelevant, whether C or C++ or Java or whatever – even COBOL. So far as the business is concerned, it’s just a compiler that they can use if the engine has a BRMS interface. The IT guys, on the other hand, have to maintain this puppy. And you can bet your bottom dollar that for an extensible, flexible, expandable system they will vote for Java every time.
Unless, of course, performance is a problem. Then they might go for C or C++. Yes, I’m one of the die-hards who believe that C++ is still faster than Java, as proven by CLIPS, CLIPS/84, CLIPS/R2, etc. The latest version of CLIPS runs the Waltz-50 benchmark in just over a second, faster than ANY of the Java-based engines including the OPSJ Rete 2 engine.
Dr. Forgy (the original Rete guy) has always said that C/C++ would run the Rete 2 algorithm much faster than the Java version but he never could find the economic justification to do such a thing. Well, maybe now he has one. We’ll just have to wait and see.
BTW, if you want to talk to Gary Riley (CLIPS guy), Mark Proctor (Drools guy) or Dr. Forgy, make it to the October Rules Fest. See http://www.rulesfest.org for more details.
SDG
jco
James
Not sure you followed my argument! My point is that replacing one from of techie-only procedural logic with another (no matter which one) does not get it done. Ease of maintenance and business agility mean replacing process, decision and other components with declarative “models” like business rules and using the hard-core languages that can only be edited by a programmer only when absolutely necessary.
(sorry for such a late comment)
I understand your last point that using a declarative “model” such business rules would be preferable to replace legacy COBOL applications instead of using a procedural language.
However, is there an example (or examples) of a real-world product that you could suggest? I assume that “under the hood”, these products would be code-generators.
If there are such wonderful tools available, then wouldn’t they be widely used already for new business applications instead of C or Java?
I thought that, since the 80’s at least, these types of tools have been explored / attempted, but they have been unsuccessful so far.
Thanks,
Lisa Keeler