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
