We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

James Taylor's Decision Management

James Taylor

Is your legacy modernization program just "forward to the 70s"?

Vote 0 Votes

Phil Murphey, over at Forrester, had a post on  Apps Modernization - What are Your Top Priorities in 2010/11? that reminded me I wanted to write about modernization a little before the year got too far advanced. As Phil says the coming years are going to be really interesting:

Leading edge technologies will become commonplace; Still newer technologies will emerge; New business threats and opportunities will arise; And the impact of the Baby Boomer phenomenon will finally arrive.

In the face of this challenge/opportunity what I see is many organizations busily modernizing their applications so that they would pass muster in the late 70s - taking assembler or spaghetti COBOL and turning it into more efficient, better structured COBOL. While this is, I suppose, worthwhile it seems to me to be too little too late. These applications will still be hard to edit, still be hard to change, still won't deliver the strategic agility that organizations need and that business leaders are crying out for.

The alternative is to invest the same effort in understanding what the assembler does but to replace it with structured, maintainable, declarative business rules. Using either the mainframe's ability to execute Java-based business rules or the generation of COBOL supported by a number of leading vendors, you can use the same basic system infrastructure but replace hard to maintain COBOL with easier to maintain business rules. Furthermore you can bring the business users who know what changes are required into the process to make the changes themselves for dramatically increased agility. Modernizing for real, not simply making the system less out of date.

I wrote before about replacing COBOL with something useful (not java) and on making meals with your mainframe leftovers. I also presented with Claye Greene on Mainframe agility and business rules.

1 Comment

Although this looks like a 2010 discussion, we had the same discussions decades ago. And funny enough, we already had solutions back then as well. A product called AION (previously Platinum, now CA) does exactly what the writer talks about.
Put the rules in an external rules engine, so code is just code and when the rules change, change them in the external engine (multi platform, by the way...)test them (yes, TEST them) and Bob's your uncle. No recompiling and the most flexible programs you can get.
Many large mainframe clients have done this for years and have 20 year old programs running modern business rules... Problems are not always as big as we think they are....

James Taylor blogs about decision-management technologies such as predictive analytics and business rules, discussing how they deliver agility, improve business processes and bring intelligent automation to SOA.

James Taylor

James Taylor blogs on decision management for ebizQ, and is an independent consultant on decision management, predictive analytics, business rules, and related topics.

Sponsored Links



 Subscribe to this blog by RSS
Subscribe by email:

Recently Commented On

Recent Webinars

    Monthly Archives