I saw this post on Offshore Architects, Legacy maintenance and modernization and it struck me, again, how valuable business rules and a focus on the automation of decisions can be in legacy modernization. By separating out the high-change, highly volatile rules into self-contained decisions you can:
- Reduce the number of changes required to the hard-to-modify legacy code by externalizing the high change pieces as easy-to-change business rules.
- Make the core business logic reusable in your SOA through decision services.
- Ensure that the business know-how relevant to your core logic stays onshore, even if most of the maintenance work is offshore.
- Give those architects who think maintenance is boring something more interesting to do - adopting a rules management system and making the changes to the SDLC to take full advantage of it should be fun enough for the most jaded.
- Make re-platforming and the adopting of business process automation or outsourcing much easier by brining the tough business logic under real control
- Modernizing COBOL with business rules
- Live from Delphi - When Your Business Knowledge Goes East
- Using decision technologies to manage application maintenance
- Business rules and the application knowledge deficit
- Lean application development and maintenance - some thoughts
- Using business rules to renovate old applications
- Here's a way to use business rules to manage offshore development
Subscribe to this blog by RSS
James,
I agree that business rules and a focus on the automation of decisions can be a key in legacy modernization.
However, we may also have to work with the challenge of legacy refactoring where it may not be practical to propose a separation of concerns, or abstract out the business rules from legacy systems.