Extracting Business Rules from Legacy Systems

You are in charge of retooling business processes for customer services. Your analysis found that several regional service centers can use a common set of standardized, streamlined business processes to improve customer service and reduce business expenditures. Unfortunately, each business unit relies on unique, back-end applications that perform similar, yet conflicting and redundant functions. This could undermine the entire initiative.

Legacy applications can be a major impediment to a business process retooling effort, but not insurmountable. There are, however, a variety of analysis tools and techniques that allow analysts to decipher legacy systems. Business rule extraction, which these tools facilitate, offers insights into backend system functionality, while offering a roadmap for retooling applications to support streamlined business processes.

Extracting business rules from the vast applications running in today’s modern enterprise has taken on increasing importance as businesses evolve. If three back-end applications perform conflicting customer service functions, understanding where and how these systems perform these functions helps analysts consolidate and standardize those processes. More important is the fact that this analysis provides the basis for retooling back-end applications to enable business process initiatives.

Application analysis, consolidation, realignment, redesign and redeployment projects are based on the ability to understand, segregate and manipulate automated business logic. A business rule in this instance is a bounded set of condition / action statements that enact a change to business data. Note that a business rule is granular in nature, embedded in source code and differs from a business process, which alternatively describes a business activity.

Extracting business rules is a multi-step analysis process that applies a series of techniques and drills down to critical back-end functionality. This task is manageable if it is undertaken in a methodological way, using the appropriate tools. Analysts should:

1. Utilize analysis tools to assess applications of interest, capturing application meta-data. A variety of tools perform this function for different languages and platforms.
2. Load application meta-data into an open repository. This facilitates integration of application meta-data captured by disparate tools, while allowing analysts to annotate and manipulate this meta-data.
3. Create cross-reference lists linking programs to user online and batch interfaces. Interface-based analysis provides an excellent starting point for business rule decomposition because it links source code to visible user functions.
4. Eliminate programs that do not relate to the processes under review or are utility-based (i.e., no business logic). Remaining source programs become targets for the next level of analysis.
5. Use rule extraction or code slicing tools to selectively extract program logic based on transaction type, data usage, input or output interface. Differing selection options offer varying views of business logic.
6. Eliminate unnecessary business logic including implementation dependent or extraneous logic.
7. Represent these remaining business rules in the repository. This requires creating a business rule object and linking source program, user interface and business process to these rule objects. This tells analysts how a business process change can impact backend systems.
8. Import extracted business rules into more understandable formats. Certain rule extraction tools can import code slices into other languages (e.g., Java) or model-based formats (e.g., UML). This enables analysts to more readily assess the meaning of extracted rules.
9. Annotate extracted business rules, within the repository, based on additional cross-reference analysis and experience. These rules can then be used to retool applications and align them with redesigned business processes.

This is a highly simplified overview of this process. These steps offer the basis, however, for establishing a realistic link between business process retooling efforts and application analysis, redesign and redeployment.