The request seemed simple enough. Marketing wanted customers to be able to order products through the Internet. This meant the company needed a Web-based application to check item availability, issue order requests, calculate prices and replicate a host of other functions that were being performed by legacy applications. In response to the request, the project team planned to use a tool to capture legacy business rules (blocks of conditional and imperative logic that change the state of business data) and import them into a Java-based front end. While this may seem like an easy answer to a simple request, this project could torpedo Internet deployment efforts if it ignores strategic implications.
There is growing popularity for legacy business-rule reuse as companies move functions to the Web. But doing that on a large scale requires addressing a number of inherent complexities. Legacy rule identification can be difficult because of inconsistencies in legacy data definitions and the cryptic, redundant nature of the rules themselves. But uncoupling business rules from legacy systems is just one hurdle.
When legacy systems continue to run parallel with Internet applications, major synchronisation problems can occur. For example, a legacy system may update customer data one way while an Internet application may do so another way. This could cause unexpected results or delays for customers. As more functions move to the Web, business-rule synchronisation problems can spin out of control.
It takes a comprehensive, enterprise-wide coordination strategy to ensure that business-rule capture, reuse and synchronisation are managed effectively over the long term. And this requires answering a few questions. For example:
* What constitutes a business rule?
* How can you reconcile legacy data definition inconsistencies?
* Can multiple projects synchronise rule identification and reuse?
* How can you reconcile redundant processing results when rules ported to an Internet application continue to run on the mainframe?
* What cataloguing scheme can be employed to track business rules as they are captured, consolidated and redeployed?
* How do you deactivate legacy rules that are no longer needed?
Any attempt to reuse legacy business rules as part of a Web-based deployment plan must be addressed in an overall strategy. This strategy must then be communicated to any project team involved in capturing and reusing business rules.
To begin, establish an oversight team to draft and deploy a legacy migration strategy. This includes creating a concise definition of a business rule and a process for identifying, classifying, consolidating and reusing rules. This process should define how data definitions are used to help identify rules and indicate how redundant rules and data can be grouped and consolidated across multiple stand-alone systems. Because there are software tools that support this process, the team should also identify a tool to enable rule identification, classification, consolidation and reuse.
There are two schools of thought regarding rule classification schemes. One says that a scheme should indicate the events triggering a rule within the legacy environment. This provides analysts with a basis of understanding for reapplying those rules in a Web-based environment. But business rule purists argue that a rule should stand alone and be classified based on the business data it impacts. Whatever scheme you choose should store rule definitions in a repository, indicate where they are used and allow analysts to access, add or update rules for ongoing Internet migration projects.
Forming a strategy to capture, classify and reuse business rules requires some front-end investment Ignoring the need for such migration strategy means driving Internet deployment into a sea of chaos.
* William Ulrich is a management consultant and president of Tactical Strategy Group