System Transformation Portal

Legacy Business Rule Capture: Last Piece of the Transformation Puzzle

By William Ulrich

Whether driven by redesigned business processes, cost issues or other factors, IT has been chartered with providing organizations a competitive edge through information technology. The objective of the majority of these systems "redevelopment" efforts is to replace, integrate or somehow accommodate legacy systems to more effectively meet business goals. As a result of this directive, improved understanding of legacy systems, through business rule capture, is becoming an increasingly common goal.

Many organizations have found that the IT department actually contains a company's functional expertise. But over time, that expertise has been lost. When company's make the decision to move to distributed systems or other technological environments, they need to determine what functions were currently being performed and what functions needed to be added. Business rule extraction is the way to determine what a company has before attempting to move forward."

Many companies are involved with a large number of business process reengineering (BPR) efforts. BPR, in the absence of systems transformation, yields only short term relief. When redesigning business processes, it is critical to realign application system functions at the same time."

Systems transformation normally involves a mix of model driven and code based redesign and reuse along with adding new functions. In some cases packages provide baseline functionality. In other situations in-house development leads the way. The use of templates, in the form of reusable design models is growing. But while templates, packages and other reusable components streamline design efforts, business rules embedded in legacy systems still provide that "competitive edge". These rules are "locked up" in legacy systems and efforts to respecify them in today's high pressure, downsized environments is a costly, time consuming endeavor. Legacy rule capture and reuse has been described as the "missing link" in the systems transformation process.

When is a Rule a Rule?

Capturing a business rule requires defining a business rule. IBM's GUIDE group had undertaken this task in its Business Rule Project back in the mid-1990's. GUIDE   defined a business rule meta-model within the context of an IT organization. This includes defining a business rule, classifying rule types, creating a taxonomy and addressing specific aspects related to reverse and forward engineering of rules. Business rules may be classified as Definitions, Facts (Relationships, Connections), Constraints ('must have' versus 'must not have') and Derivation Rules (inferring new facts from existing ones).

Ronald G. Ross, publisher of Data Base Newsletter and also a member of the GUIDE project, authored The Business Rule Book to define one such model. According to Ross, "the model focuses on defining rules in a declarative and non-procedural manner. The business rule model is the result of work dating back to the mid-1980's and covers aspects of non-procedural specification. It does not eliminate the need for procedural specifications, but reduces it rather dramatically."

There have been other efforts at defining an industry standard for a business rule. Object Management Group states for example, that "Rules are declarations of policy or conditions that must be satisfied" and that "Business rules are rules that govern the way a business operates."

While these efforts have merit, restrictive time frames make it difficult for IT organizations to assimilate these complex, and potentially conflicting, views. Software vendors, consulting groups and IT organizations are, therefore, proceeding based on definitions available today. To that end, we define a rule within a legacy domain as "a combination of conditional and imperative logic that changes the state of an object or data element." This definition establishes a basis around which software tools and extraction techniques can identify and capture business rule candidates for further analysis, abstraction and reuse.

Excavating Business Rules

Legacy business rule capture is similar to an archeological dig. Unlocking past secrets involves more than digging up old bones. Like the archeologist, rule excavation seeks deeper meaning behind what is initially below the surface. Business rule capture may be viewed as unlocking the DNA structure of legacy systems because they define the essence of a system. Because rules are scattered across a multitude of large, convoluted programs, identification and excavation of these rules involves phased analysis, elimination of irrelevant byproducts, clarification, isolation and reuse.

Estimates indicate that business rules comprise less than 30 percent of existing source code. This suggests that wholesale reuse of entire systems is ill advised. A case in point occurred at Wall Street firm Kidder Peabody (since acquired by Paine Webber). Ana Leonard, assistant vice president at Kidder Peabody, managed a business rule extraction effort. According to Leonard, "system functional experts were available, but specific detailed knowledge was still missing. We used tools to capture legacy business rules. Experts were then called upon to verify the context of the extracted rules. This allowed us to glean required rules from the current system to support respecification in a client/server environment."

"One point to emphasize" Leonard adds "is the importance of using an overall process to manage rule identification and capture. We performed an Inventory/Analysis based on USRM a transformation blueprint. With so much code to deal with a tool could easily be misdirected to focus on irrelevant patches of logic. Our initial technical and functional analysis set the stage to more effectively use granular tools to find rules."

Rule capture and reuse, however, is just one component of systems transformation. Defining a process to leverage these tools is a must. The benefits of any tool in the absence of a well defined transformation process is limited.

Rule extraction is a subset of the transformation analysis, improvement, extraction and reuse cycle. This cycle involves technical, architectural and functional analysis to segment systems in preparation for rule extraction and reuse. As Kidder Peabody's Leonard emphasizes, skipping this process can lead to focusing on irrelevant patches of logic. Technical analysis identifies weaknesses in the current system that should be corrected prior to rule extraction. Corrective measures includes code stabilization, data name rationalization and remodularization. Architectural and functional analysis identify candidate source code for rule extraction and isolates programs and systems to be targeted for corrective measures.

Removal of code flaws, such as recursion, and restructuring of convoluted logic simplifies rule extraction because some rule extraction tools have difficulty with legacy code constructs. Remodularization is selectively used to split cumbersome modules into more streamlined routines. Data name rationalization (DNR) involves consolidating and renaming redundant data definitions so that analysts can tell which data an extracted rule actually impacts. If a rule extraction tool does not support DNR as part of the process, it should be applied as a prerequisite step. While code improvement techniques are prerequisite to business rule capture, common sense coupled with comprehensive front-end analysis dictates the degree of effort applied.

Once code improvement is completed, actual rule extraction may begin. Widespread occurrence of implementation dependent logic inhibits business rule recovery and typically comprises over 70% of the logic within a given program. Implementation dependent logic falls in several categories as depicted in Table I. Software tools help uncover and remove some of these constructs, but analysts must selectively review and remove other constructs. Suggested removal guidelines are listed on the right side of the table. Depending on the tool being used, business rule capture usually overlaps with implementation logic elimination.

Rule Capture

Rule isolation and extraction is performed by tracing logic paths based on various selection criteria. This includes logic leading to the creation of a given output variable, logic linked to some type of conditional and logic associated with a given input transaction type.  Analysts must review a rule after extraction in order to use it as is, extract again based on a different criteria or subset the extracted rule further. These techniques are somewhat tool dependent, but it is important to establish an initial extraction criteria regardless of the tool being applied.

Required rule extraction tool criteria minimally includes an ability to "slice" out a rule based on a specified selection criteria. Since business rules do not limit themselves to the confines of a source program, extraction tools must be able to analyze logic across program boundaries. Beyond that, a rule extraction tool should be able to bypass or highlight implementation dependent logic, store an extracted rule, further extract against a previously extracted rule, display a rule in varying formats to promote understandability and transform an extracted rule into a reusable format.

Certain tools can load a system into its knowledge base and transform it into predicate logic. Rule analysis is then facilitated through cross system extraction and simplification techniques. Rules may be displayed in decision vectors or as source code. The real power of are that they allow IT professionals and non-technical analysts, to examine extracted rules and verify what functions a system is actually performing.

The industry wants automated solutions in this area because people do not like to do the work required to get useful results. An example is when people skip the DNR process. How can organizations understand their code when they cannot understand their data? Furthermore, early efforts to reuse whole programs and import them into ICASE tools have left the marketplace skeptical regarding this whole topic area. Early, misguided efforts in business rule capture stemmed from the lack of sophisticated reuse strategy in many organizations.

While most tools offer static source code analysis to support rule extraction, other tools provide dynamic analysis by tracing logic paths during program execution.  Dynamic analysis is performed when a program is executed, dynamic analysis can capture a logic path based on the transaction being performed. Sophisticated tools support the creation of a union of slices allowing analysts to fine tune extracted views.

Business Rule Classification & Reconciliation

A given system may contain hundreds or even thousands of business rule candidates. It usually takes time to assimilate these rules to begin to see "the forest for the trees". Other factors driving the need for rule classification include reconciliation of overlapping rules, mapping of legacy rules to target rule requirements for reuse, linking rules to related events and mapping legacy rules into target paradigms. Finally, the fact that humans cannot digest the shear volume of captured rules dictates that these rules must be presented in some hierarchical fashion using a predetermined rule classification scheme.

One technique applies a scheme that defines each rule using atomic sentences with capitalized key words. Categorization was performed by linking each rule with the data entity that it impacted. Analysts and users could then review each set of rules by pinpointing a given data entity. The findings were then used by analysts chartered with data warehouse and related projects on a continuing basis.

While the rule / entity classification scheme is a common one, other options exist. Event capture, based on on-line screen invocation, call routines, transaction paths and other invocation logic, helps classify rules based on how they are triggered. An event can be linked to the object or entity it impacts, thereby providing a link between business rule and data entity or object (based on the modeling paradigm used). Representing these types of relationships is a straight forward process using a Legacy Transition Meta-model. This meta-model can be implemented in commercially available repositories and allows analysts to link captured business rules in an infinite variety of ways.

To be most effective business rules should be stored in a technology independent repository to improve the management of those rules once they are captured. Business rule capture is a key issue because most development projects do not have the luxury of starting from scratch. Once rules are in the repository, reuse is facilitated in our rapid development environment.

Other classification schemes include linking rules to Information Engineering models, highlighting redundancy by linking legacy rules to other legacy rules, mapping legacy rules to target rules to support reuse, and mapping rules back to originating source code. A combination of these relationships may be established depending on project requirements driving rule capture. Migration and reuse projects require rule mapping to target models. Event / object migration efforts focus on event derivation and event-to-rule mapping. Maintainers would be interested in understanding redundant rules and their link to originating source code.

Rule reuse in a target model is driven by the specification model used by the development team. For example, an atomic sentence format is understood by the business user, but does not map to available development models. This means that a rule, once reviewed by an analyst, must undergo transformation prior to being reused in a target model. Target formats may include any variety of client/server models, declarative procedures or target languages. Because this is highly tool dependent, IT organizations must rely on bridges between rule extraction vendors and development tool vendors. Fortunately, relationships between various tool vendors is becoming increasingly common.

The process of business rule capture has been practiced on an informal basis for many years. Formalizing this process, and automating portions of it, completes the missing link in the redevelopment chain. Business rule capture and reuse is becoming a feasible endeavor that will profoundly change the way organizations redevelop the vast base of legacy applications. As the pace of redevelopment quickens, organizations will want to have the process and the tools in place in order to meet competitive information challenges of the next millennium.