Some thoughts on legacy modernization with business rules

I saw this white paper by IBM on Legacy Modernization with business rules and thought I should quickly re-summarize my point of view on this and link to my various posts on the topic. The white paper does a nice, if IBM-centric, job of outlining the key issues:

I saw this white paper by IBM on Legacy Modernization with business rules and thought I should quickly re-summarize my point of view on this and link to my various posts on the topic. The white paper does a nice, if IBM-centric, job of outlining the key issues:

• You don’t need to modernize the whole application
• Decision making components are often the highest change, most difficult to maintain pieces of mainframe systems
• Externalizing these components using a business rules management system dramatically reduces the maintenance costs of a legacy application while both improving its agility and positioning you for replatforming later.

The basic steps:

• Analyze the code to find the decisions
• Rework the code to isolate these decisions in their own component
• Work out the rules for these decisions and document them in a business rules management system
  You can analyze the code to find rules but starting with the original policies/regulations is often much more effective as code analysis gives you VERY technical rules
• Use the BRMS to redeploy the rules as a decision service that the legacy application can access
• Retire the replaced code

Read the white paper, even if you are not an IBM customer, as it is a nice summary. For those of you who want my opinion, check out these posts:

• Is your legacy modernization program just “forward to the 70s”
• Why don’t you replace COBOL with something useful (not Java) and More on replacing COBOL with something useful
• Enterprise Application 2.0 and Getting to Enterprise Application 2.0

You can find these posts and more using the Legacy Modernization tag

Copyright © 2010 http://jtonedm.com James Taylor