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.