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 …
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.