THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

Published in TDAN.com April 2001

You are forging ahead with your e-business strategy. You are web enabling and converting systems. You are busy. Below the surface, though, lurk two ugly thoughts:

“There is so very much undocumented legacy code out there,”
and
"Am I just furiously building a deeper hole (legacy two or three)?”

A clue to addressing these worries lies in another question. What is buried in these legacy systems that is so hard to get out? The consistent answer is: “Business Rules.”

In a nutshell, business rules are those statements that implement business policies, such as, “any customer with purchases greater than $100,000 over the last six months is a preferred customer;” “Preferred customers get an extra 10% discount on all orders;” “preferred customer discounts are overridden by special discounts;” “Available balance is computed as…..” an so on. These, and many more complex rules are at the heart of what must be excavated from existing systems in a re-engineering effort.

Business rules represent the essential business logic that must be unearthed, and the portions of systems that usually need to be adjusted over time in order to respond to customer demand and market change. The fact that they are buried somewhere in legacy code is a major barrier to a business’s ability to adapt on an ongoing basis.

The idea, then, is this: If we can identify common characteristics about business rules, maybe we can:

1. Develop analytical, tool-assisted methods to cull them from existing systems in a way that accelerates re-engineering while at the same time improving the quality of results.
2. Deploy new systems using technology that keeps this recovered business knowledge externalized, so that it can be directly managed, or at least known by, the business community, and can be rapidly changed.

Today, it seems we may be able to do both. Moreover, for such dynamic, “rules dense” initiatives as one-to-one customer relationship management and collaborative e-business “extraprises,” it’s beginning to look like such a rules-driven architectures may be critical to success.

Years ago, with the advent of DBMSs, we externalized persistent data in a sharable form from applications that referenced it. Today, few would consider building an application without one. In the same way, business rules are becoming another, equal player, maybe an even more powerful player. The tools for implementing business rules separate from the rest of the system architecture are maturing rapidly. “Business rule products,” some with their roots in older artificial intelligence software, and some based on different approaches, are emerging as a separate architectural component. Examples vendors include Blaze Software, Usoft, Versata, Rule Machines, Aion and Haley. These products may be “data centric” – responding automatically to attempted changes in data, or service oriented – called by other objects. The degree to which the business rules can be stated and managed in natural business terms; how rapidly an updated rule can be deployed (some allow real time, 24x7 update); how the rules capability is best integrated with other components; and the type of system to which they are most suited (transactional vs. analytical) varies from one product to another. But the underlying concept is the same for all of them: externalize and manage the rules as a separate system component…….to enable faster business change.

Deploying systems using a business rules approach into business rule technology can save time in both initial development and subsequent maintenance. It’s easy to see how maintenance savings would result. With business rules externalized, changing them becomes a matter of just doing a direct update of the affected rule(s). All processes affected by that rule are will now reference the updated version.

The savings in development come from:

1. Not having to create traditional program code for business rules, but rather loading them directly into the business rule product
2. Allowing the product to automatically manage rule interdependencies and execution sequence (again rather than coding), and
3. Providing a requirements specification method (business rules) that is both natural to the business and precise in terms of implementation.

The last point may be the most dramatic, and have the biggest effect on improving the business/IT dialogue and ensuring delivery of quality systems. It may be the best “lingua franca” for business/IT dialogue yet to appear. This doesn’t mean that business rules are the next “silver bullet” or will replace existing development methodologies. Most business rule proponents will tell you that a business rules approach augments existing methods and provides clarity to them. A business rules approach sharpens the requirements, leads to interesting policy and rules analysis, and provides a pathway to implementing them as an external asset. In a business rules driven architecture, the process or presentation layer components tend to be thinner and easier to specify, as they no longer have to struggle with incorporating business rules in their logic. Consider, for example, a customer relationship management environment. A rule product can greatly facilitate the establishment and management of customer specific financial arrangements, services, preferences, product selectors and configurators. Looking forward, business rule products may emerge as another, obvious component of the architecture, just like the DBMS is today.

OK. That addresses the second of the two nagging worries: fear of re-burying the knowledge you exhume from legacy systems and creating nightmare number 2. But what about the first headache, getting the rules out to begin with?

Help is arriving here as well. Tools such as SEEC’s Mosaic Studio, Netron’s HotRod, and Relativity’s Rescueware, with their roots in legacy COBOL maintenance and Y2K conversion support, have continued to mature. As a whole, these tools target the identification and isolation of essential business logic in legacy code, and the forward engineering of these as executable components.

A word of caution. Vendors in this space almost uniformly now talk in terms of automatically mining and forward engineering “business rules” from existing legacy code. What this generally means is that functionally independent chunks of code can be isolated, “wrappered,” and forward engineered as objects in, for example, Java. This may result in a repackaging of existing code into new technology, but without externalization and separate management of the essential business rules. In some cases, repackaging may be all that you’re shooting for.

Stated another way, consider that we can break down such tool assisted re-engineering efforts into the following phases:

1. Scoping and inventorying the target application
2. Prioritized digging through code and isolation of essential fragments
3. Analysis, abstraction and recasting of business logic
4. Forward engineering

These code re-engineering tools provide good support for steps 1) and 2). They can also provide some assistance in step 3), where you uncover and clarify the essential, underlying rules. However, the latter is where hands on analysis methods will also need to be brought to bear if you want to externalize actual business rules for management and redeployment. For example, excavating the rules for how you handle interest calculations or account fees from an existing sequence of batch programs may not be as simple as zooming in and plucking them out where they lie. The actual rules may be buried under or fragmented across a technology dependent, procedural sequence of steps. Simply wrappering such logic represents a great example of the old adage of repaving cowpaths, but doing it much faster. More importantly, the true business rules may remain buried.

But even taking this extra step into account, great improvements can be realized in the time and quality of system re-engineering or migration projects. Base on results using such a tool assisted approach to rule extraction, or Business Rule Mining, as we refer to it, Knowledge Partners, Inc. estimates the time savings over equivalent manual approaches to be on the order of 50%, with a much higher confidence level that all essential logic has been extracted.

Summary

According to the Meta Group, “….By 2003/2004, organizations that have not automated their key line of business applications and provided this flexibility (e.g. extracting the business rules from the coding layer) at the infrastructure and commerce chain levels will be at a significant competitive disadvantage.” (Meta Group, The Process Automation Evolution, Workflow 2000).

If you’re daunted by mountains of intractable legacy code on one hand, and worried about the future business adaptability of what you’re hurriedly building on the other, you are at least not alone. It also means that business rule driven approaches and technology for both reverse engineering and redeployment, are something you should be looking at today, whether you are re-engineering yourself or migrating to packages. In no small way, your company’s competitive position tomorrow may depend on it.

In future columns, we’ll take a closer look at both classes of software we’ve just described: products for separating and managing rules as a separate architectural component, and tools that can assist in the initial extraction of business rules from their legacy caves.