Screenshots
Videos
Guides
Download
“Owners of legacy RPG applications are faced with the threat of losing knowledge of their applications before they have time to reengineer or replace them.”
I overheard that remark recently – it was in the context of a discussion about the ever-dwindling pool of RPG programmers.
All existing applications on all platforms, in all languages, will eventually be replaced. That replacement takes the form of a) a rewrite, often in another language, or b) the purchase of packaged software.
And here’s the point that clicked for me: in either case, knowledge of the existing applications is critical. Without that knowledge the transition will be far more risky, lengthy and expensive – we all know this from experience.
And we also know this transition will have to happen someday.
The question is whether owners of legacy RPG applications will be able to make this transition while they still have full knowledge and control of their existing applications.
It Is Inevitable That You Will Recover Your Business Rules at Some Stage
Virtually all organizations that have monolithic, legacy RPG will eventually modernize to something else.
There are two primary paths to follow: 1) reengineer your application to a modern language and architecture, or 2) purchase a commercial off the shelf product (COTS). In many cases a combination of both will be adopted.
In either case you will need to recover valuable design information from your existing application. At a minimum your business rules, consisting of transactional business logic and relational data architecture, are the most essential artifacts to recover.
(click here to see a Guide to Business Rules Recovery)
No matter which way you eventually go, recovering business rules is central to your future. There are a number of reasons for this:
- Understand your application – gain a perspective that everyone can understand: users, analysts, developers and so on. Your business rule repository is a descriptor of one of the key values your system has to offer.
- Manage your application better – Reuse your business rule functionality, and clean it up – see typical problems, below – to improve maintenance work.
- Analyze the gaps in COTS ERP packages – If you migrate to a commercial off the shelf package you will have to go through a process of comparing the package against the functionality your organization currently runs on. Having the complete – and clean – set of business rules is an absolute requirement to discover gaps. You will also need to map the existing and new data models for data migration.
- Feed the design of migrating or rewriting – If you are rewriting or converting your existing application, in whole or in part, you will want to extract the business rules and feed them into the requirements, design, testing and documentation of the new application. Again, this will be an absolute requirement.
Whichever way you exit from RPG you will want to understand the business rules that currently run your business. In the meantime it is only logical to prepare for your eventual application transition by understanding your business rules and getting them in order. Applications of significant size accumulate a number of problems with business rules over time:
- Incorrect business rules
- Duplicated business rules
- Inconsistent business rules
- Business rules located in incorrect places
- Obsolete business rules
- Missing business rules, as in “uh oh, I thought the system checked for that!”
Extracting business rules has long been an extremely tedious task, consisting of developers and analysts going through program code, logging rules, organizing them, and cross referencing them. Fortunately there are modern tools available such as Databorough’s X-Analysis that can automate the task to a tremendous degree.
(click here to see a Guide to Business Rules Recovery)