Guide To Business Rules Recovery
Having the ability to look at applications from a Business Rule perspective is critical for this reason: it is the only perspective that survives all applications, all languages, and all platforms, over time, for an organization. You could rewrite your RPG IBM i application to any other language on any other platform, and still have the same business rules.
Typical Reasons for Extracting Business Rules
It is during the transition to new applications that Business Rules are most commonly extracted and used to facilitate the process and lower both transition costs and risks.
This late in the game approach, however, misses out on opportunities to reduce application management costs, improve maintenance results and increase an application’s value throughout its lifecycle. The overall benefits are:
- To help Business Analysts to understand and work with the system
- To communicate system functionality to users and management
- To help developers understand existing functionality, what it is and where it is located
- To improve system quality by facilitating consistency and accuracy
- To increase programmer productivity by enabling code reuse
- To feed the process of reengineering and migration
- To evaluate the suitability of packaged software being considered for purchase
A repository of Business Rules should do more than simply be another system reference. It should be used to shape IT processes and communications. As noted in the introduction, Business Rules survive multiple iterations of application lifecycles and platform installations.

What Are Business Rules?
There are two broad categories of Business Rules: Structural and Functional.
Structural Business Rules define how the database is modeled – what are the tables, their attributes, the relationships between different tables.
Structural Business Rules also define much of the user interface – how it is designed into individual use cases or activities, and the flows between them.
Functional Business Rules define how data is processed in the application. A typical Functional Business Rule is in the form of “if this condition is met, then take these actions.”
In X-Analysis there are specific repositories for each type of Business Rule: the Data Model, the User Interface, and the Functional Business Rules.
Business Processes, Application Areas and Business Rules
From a modeling point of view, where do business rules fit into the picture? In very broad terms, software applications are representations of what comprise organizations and their actions in the real world.
Businesses have business processes which are typically represented by what we call applications. Applications may be subdivided into sub-applications. Individual actions occur in applications and are typically comprised of functional business rules. Data model business rules define the data used within applications.
Re-engineering existing software, aka, design recovery, is a complex process and is basically an attempt to understand and document the blue areas above, by analyzing the green.
The Re-engineering process should deliver its output in a variety of formats including:
- UML artifacts, such as Activity Diagrams, Class Diagrams and Use Cases
- Standard office documents such as Visio, Word and Excel, for further elaboration by analysts
- Programmable formats such as DDL, SQL and XML
X-Analysis provides all these formats and many more options as well.
How Do You Use Extracted Business Rules?
Business Analysts can use Extracted Business Rules to document existing application functionality for purposes of specifying changes to applications, specifying functionality in new applications, or for comparing existing functionality to software packages being considered for purchase.
A good Business Rule tool enables the business analyst to add comments to business rules to further explain their purpose or use. A tool should also enable the business analyst to perform cross reference and drill-down activities interactively, as needed. The tool should also translate the extracted functionality into some form of structured English or pseudocode, and allow it to be exported to office applications for further development.
Developers can use Extracted Business Rules to locate existing functionality throughout the system for purposes of reuse, cross reference or general research and analysis. Having access to an immediate, interactive tool encourages code reuse and facilitates application consistency. The ability to map Business Rules directly back to the source code is also important for developer use.
X-Analysis provides all these features to business analysts, developers and IT managers.
How Do You Extract Business Rules?
The traditional means of extracting business rules has been for business analysts to sit down with developers and walk through the code, often driven by existing documentation into which the business rules are mapped.
With a tool such as X-Analysis, however, new opportunities open up due to the ease and speed with which business rules can be extracted.
X-Analysis allows you to extract your business rules with just a few simple clicks in a matter of seconds.
Click here to arrange for a live demonstration of extracting business rules with X-Analysis.
