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:
- 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.
- 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, 24×7 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:
- Not having to create traditional program code for business rules, but rather loading them directly into the business rule product
- Allowing the product to automatically manage rule interdependencies and execution sequence (again rather than coding), and
- 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:
- Scoping and inventorying the target application
- Prioritized digging through code and isolation of essential fragments
- Analysis, abstraction and recasting of business logic
- 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.
