≡ Menu

More on replacing COBOL with something useful


Lisa posted an interesting comment on an old post of mine (Why don’t you replace COBOL with something useful (not Java)) in which she make some interesting comments:

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.

Indeed. Replacing an old procedural language with a modern one might help some, it will not make the resulting code any more accessible for business users and will not, therefore, truly increase the agility of an organization. She goes on to ask:

However, is there an example (or examples) of a real-world product that you could suggest?

Well yes. There are a whole class of commercially available and powerful business rules management systems (FICO Blaze Advisor, IBM ILOG Rules, Pegasystems, InRule, Innovation Software, Corticon, IDIOM and more) as well as open source options (JBoss Drools) and various BPMS solutions with decent rules capabilities. Any of them can be used alongside a legacy modernization solution like MicroFocus to replace the core business logic of an application – the decisions – with a more declarative model. There’s no magic button to replace the legacy code with declarative models but the process of understanding and restructuring the legacy code, extracting the code that represents a decision and replacing in with a rules-based decision service is well understood. All the vendors I list could provide case examples of customers doing exactly this.

I assume that “under the hood”, these products would be code-generators.

Some are, some aren’t. Some have an engine component used at run time, some generate stand-alone code, some do a bit of both. Several (FICO, IBM) even generate COBOL so you can have the rules management tools for business user access and still run all the logic inside the COBOL execution space on your mainframe.

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.

Here the story is mixed. The tools do work and are used for new business applications but Lisa is correct in wondering why they are not widely used – and let’s be frank, they are not widely used. Despite the fact that business rules management systems work and work well they are not used anything like as often as they should be. Part of this is that only recently has the industry solidified around the best way to use them (building decision services, for instance, and integrating with business process management). Mostly, however, it is resistance from programmers. Programmers think procedurally and understand their code – changing the way they approach the problem so that they can bring business users into a more collaborative environment is not always something they are willing to try.

So, Lisa, the tools do exist and do work. You can (and should) use them in legacy modernization but you are correct that they have not (yet) penetrated as far as they should into the development mainstream.


Comments on this entry are closed.

  • Mannes Neuer February 11, 2010, 6:44 am

    These days, we are seeing less folks looking to migrate off COBOL. Instead, many are making their legacy applications more responsive by associating core elements and defined service components with documented rules and decision models, managed by the business. In that context, they will use our toolset (Modernization Workbench – Business Rule Manager) to discover rules from COBOL, refine them and manage them forward as business assets. This falls short of direct business authoring of executable code a la BRMS, but provides the benefit of business alignment and insight into the organizational DNA (which is what, after these applications are), and without the massive investment required for full redevelopment.

    Direct business authoring is also a target many of the BRMS vendors have been pursuing – recognizing that even with the higher abstraction level they offer, it is still IT who often ends up coding and maintaining the BRMS systems.

Next post:

Previous post: