T E R R Y     M 0 R I A R T Y

Situations in which reverse engineering can be your best friend

When to Reverse the Rules

November, 1997

Many people wonder why I think extracting business rules from the current application portfolio is important. They feel that the business rules those applications enforce are incorrect or have no current value. While this may be partially true, there are situations in which the code is the only authoritative source of the organization's business rules. If any of the following six scenarios applies to your organization, you may need to consider incorporating reverse engineering into your business rule discovery approach:

1. Your applications are older than your users.

If your applications have been around for more than 10 years, there's a good chance they have been with the organization longer than most of your business users. The current applications may provide the only framework through which your business users understand their jobs. Consequently, they may provide constraints imposed by the current technology as requirements for a new application. They simply don't realize that the business doesn't have to behave as it does today.

For example, consider the impact of technological advances on the business. There was a time when branches were a bank's primary profit center. Accounts were considered to be "owned" by the branch in which they were opened, and each branch stored the checks that were written against its accounts. The applications that supported check clearing were written using flat files, the predominant data management technology at the time. To support efficient record sorting so check activity could be reported by branch, many banks included a branch number in the first digits of all checking account numbers. In other words, the checking account number was designed to deal with constraints imposed by the available technology. While this policy enabled bank staff to quickly determine which branch owned an account, it meant that customers had to open a new account whenever they wanted to change branches. Obviously, this business process was imposed on the customer to make the bank's accounting procedures work, not for the customer's convenience.

With the passage of time, technology and bank practices have changed. Most banks now store checks in a central repository rather than routing them back to the owning branches. With DBMS indexing, we no longer depend on the intelligence embedded in the account number to determine which branch currently owns the account. Furthermore, the business may be interested in implementing more customer-focused operating policies by letting customers transfer accounts from one branch to another. If your business liaison is not familiar with the reason the branch number was embedded in the account number in the first place, he or she may give it to you as one of the requirements for a new system. If you ask why, the answer may be "That's the way it's always been."

Extracting business rules from the code that is targeted for replacement by the new system may help you spot areas specifically designed to cope with the technology of the past. As a result, you will be better prepared to ensure that all the current business requirements are truly essential to your business in the future.

2. Your users think that many of their requirements are obvious.

In his book, Data Model Patterns: Conventions of Thought (Dorset House, 1995), David Hay points out that some requirements are so obvious that business users don't think to mention them. Unless you know the business as well as your users do, you may not realize that essential requirements have not been captured.

I encountered such a problem when gathering requirements for a banking business. I was working with two incredible bankers who had performed nearly every major function within their retail bank. I was responsible for debriefing them in order to gather requirements for a new application intended to replace most of the existing operational applications. When I delivered the document for their review, they were outraged. While they agreed that all their requirements were fully documented, they complained that it was too elementary: It stated requirements that were extremely obvious to anyone who ran a bank. The two bankers were embarrassed to have such an elementary document released for review by their colleagues. I explained that most application developers were not bankers and that what was obvious to businesspeople was new information to developers. (In fact, the "What Is a Bank" requirements document I derived from this experience eventually became the basis for a course on banking for new programmer/analysts.)

The lesson here is that extracting business rules enforced by current applications may enable you to augment the business rules your users provide with any they may have overlooked.

3. Your users don’t want to provide their requirements again; all they want is new technology.

Have your users balked at the idea of participating in requirements sessions because they think they only want a new technology-you know, a client/server application with a slick GUI front end like they've read about in airplane magazines? They're not unhappy with what the current system does, they just want something spiffier that's easier to use and requires less training. Can't you just use the requirements they gave you when you built the old system?

This probably isn't the opportune time to remind your users that the system delivered didn't entirely match those original requirements or that the documentation hasn't been kept up as bugs were fixed and enhancements incorporated into the system. Reverse engineering that application may be the only way to save face in this situation.

4. Your company just merged with another company, and the person who knew the business rules just took the early retirement package.

While mergers may be good for the companies involved, they can be extremely traumatic on the IT organizations. Melding two application portfolios into a cohesive unit can be extremely challenging. Some of the primary questions are:

* If my application is not a survivor and I must rip it out, what is the impact on the remaining applications in my portfolio?

* What interfaces does this application have to other systems?

* Is any of this application's code used by other applications?

You can answer these types of questions by reverse engineering the application's Job Control Language. The analysis must be performed across the entire application portfolio in which the datasets and programs an application uses are linked together. Now, if an application is being removed from the portfolio, you can use its list to identify the other applications that are sources or users of its data. Likewise, you can identify applications that use programs for which the application in question is responsible.

You must also analyze both the surviving application and the one being eliminated to determine whether the business rules they enforce are compatible. Does the incoming application enforce business rules that do not exist in your application? Does your application enforce business rules that the new application doesn't support? Addressing these questions will help you determine what impact integrating the disparate data and business rules will have on the business.

5. You just bought the latest one-size-fits-all software package, but you aren't sure whether its business rules are compatible with yours.

Incorporating a new package into your application portfolio requires the same type of impact analysis you would perform for a merger. You are replacing one or more applications in the current portfolio with the package. You can assess the external impact (the impact on other applications) by running jobs that will reflect the flow of data into and out of the obsolete applications. You can also assess the internal impact (the impact within the boundaries of the application's programs) by determining what business rules the package enforces compared to what business rules the obsolete applications enforced. In the former case, check the documentation provided by the package's vendor; it may allow you to submit the package's source code to your reverseengineering software.

6. You have a data warehouse, and your users want to know more about its data than merely its definition.

As your users become more sophisticated in using the data warehouse, they will increasingly demand more metadata. They rapidly find that a data element's business definition is insufficient for determining why a specific business object has assumed a certain value for that data element. They find that they need access to the valid values, default value, derivation rules, and dependencies on other data in order to understand the results of their data warehouse analyses. The question has changed from "What does this data mean?" to "Why does this data have this value?"

For example, in my last column ("Getting Your Business Rules Automatically," October 1997), 1 described a furniture delivery scenario in which "scratched and dented" was the default value in the operational application that recorded the "delivery return reason code." When this information is available through the data warehouse, the business analyst can quickly determine why "scratched and dented" represents a disproportionately high percentage of the delivery returns.

Of the various techniques you can use to identify the business rules an application enforces, reverse engineering the code is probably the most expensive. Even with automated support, I only recommend code reverse engineering if knowledgeable people are not available to document the business rules. For example, if your application and business subject matter experts were available when the data warehouse was initially developed, code reverse engineering would not be necessary because your experts could tell you what business rules the source applications enforced. However, in subsequent releases of the data warehouse, these people may not be available, making code reverse engineering your only option.

In the situations I've described, you are doing data reverse engineering, which is more precise than the code reverse engineering conducted for application awareness. Data reverse engineering involves a highly focused slice across the application portfolio to find just the code that impacts a specific set of data elements. For each data element, the ideal reverse-engineering tool identifies the specific type of business rules being enforced and provides a programming language-independent interpretation of each business rule it discovers. It also provides access to the logic in the order in which the code is executed, rather than the order in which it is written. None of the products I reviewed in last month's column (Viasoft's Existing Systems Workbench 4.2, ADPAC's PM/SS version C 305 M1, Microfocus Revolve 4.1, and Regenisys Access:R 1.0) meets all my requirements. However, these products did provide a path through the code so that I could accumulate a meaningful data element documentation package. My hope is that the vendors of application-aware reverse-engineering products will eventually enhance their applications to support data reverse engineering.

Terry Moriarty, president of Inastrol, a San Francisco-based information management consultancy, specializes in customer relationship information and metadata management. Her common business models have been used as the basis of customer models for companies within the financial services, telecommunication, software/hardware technology manufacturing, and retail consumer product industries. You can reach her at terry@inastrol.com.