Recovering the design of legacy applications is critical to re-engineering and migration projects.
Whether you are rewriting your applications in the same language or another language, or selecting an off-the-shelf package for purchase, it is essential to thoroughly understand the business rules and data model that your business currently runs on.
Four primary purposes for recovering your application design:
- For designing reengineered applications
- For doing gap analysis of off-the-shelf packages
- In order to share application knowledge and communicate more effectively
- In order to improve the management and maintenance of your applications
Here’s a critical truth:
When rewriting or purchasing a package,
the single most cost-effective and accurate
source of business requirements
is your legacy application.
To not extract the valuable, proven knowledge contained in your legacy applications is to truly add risk, cost and time to any project schedule.
Will recovering the design give you all your requirements? Probably not. But recovering as much as you can is crucial. And here’s another critical truth:
The recovered design, especially the business rules, must be accessible and
understandable to developers, analysts, managers and users alike.
The box above summarizes both the design elements that are critical to recover, and the output and media options necessary to ensure smooth communication and adoption.