Business Rule Extraction in Application Modernization Projects

An extended essay on business rules and the extraction of business rules (and business requirements) from legacy application artifacts in large to very large scale projects. ? Copyright 2015, Don Estes.

Summary

We assert that the fundamental axiom of application modernization is that business rules controlling the processing of update transactions are invariant across the modernization process. Business requirements, other than those which specify that the business rules be obeyed in the new implementation, are not affected and thereby free to change as desired to optimize the use of the new system and provide increased value to the organization, unconstrained by the business rule invariance. This is equally true whether the modernization will be implemented in custom developed code or through use of a commercial off the shelf software package.

This axiom is of critical importance to projects that seek to add substantial business value to the modernized system but want simultaneously to ensure the success of the project. It is almost universally assumed that to add business value one must start from a blank sheet of paper and redesign the system from the ground up, accepting the costs and business risks involved because of the value of the goal. The axiom guides us towards mitigation of the increased costs and risks to the business from a top to bottom redesign without sacrificing the goal of significant business value added.

We further assert, as a corollary to the axiom, that the defects and shortfalls in functionality that occur in modernization projects are a direct result of a failure to extract a 100% complete and correct set of active business rules from subject matter experts and legacy artifacts. As errors and omissions in the set of business rules are exposed over the course of the project, the time at which the new application can go into production and replace the legacy application recedes into the future while present day costs continue to mount. Or, alternatively, the less than perfect new application goes into production and discrepancies occur in daily processing which must then be fixed in both the software and the data, at the most expensive part of the software development life cycle. In addition to the direct costs incurred are the business risks from defective processing, with an unknown potential for impacts on operations and reputation.

For most projects, these future costs originating from errors and omissions cannot be predicted by analysts at the time that the project is proposed and return on investment calculations are made. This is because, at the outset, the analysts don’t know what they don’t know. As a result the analysis is based on what they do know, using the best available information at the time which is always significantly incomplete in large to very large systems.

Therefore, assembling that 100% complete and correct set of active business rules before the actual implementation begins will underpin a more realistic assessment of the time frames and return on investment calculations, and will in most cases justify the cost of doing so by eliminating the impact of unknown requirements over and above the improvement in business risk. It is a predictable cost incurred to avoid future unpredictable (and usually substantial) cost increases and to avoid the business consequences from incorrect processing. In the body of the essay, we discuss a process of dynamic business rule extraction to complement business analysis and static business rule extraction.

We further assert that, for a large or very large application, neither traditional business analysis nor static business rule extraction together or alone will lead to a 100% complete and correct set of the active business rules – only the process of dynamic business rule extraction will do so. Dynamic business rule extraction can achieve this result with a practical level of cost within an established range of accuracy that derives from the business case.

We further assert that testing alone will not provide a sufficient protection to the organization from errors and omissions in a modernized application because existing testing methodologies are fundamentally flawed when applied to application modernization. Standard testing methodologies test against requirements (which include specifying the business rules that must be obeyed). By definition, this means that testing against requirements will never expose errors and omissions in the requirements upon which the testing is based. You can’t get out more than you put in.

Only some form of external comparison against the executing legacy application can do so, because only execution will eliminate the ambiguities inherent in human analysis. The dynamic business rule extraction process described herein creates and validates a set of test cases as the mechanism to expose those errors and omissions. Then the resulting unambiguous test cases can be used to validate the business rules in the modernized system more effectively than testing based on incomplete, erroneous, and ambiguous requirements. Although this is an analytically intensive process, it is cost/effective because the reduction in testing costs and the avoided cost of rework from defects found late in the software development life cycle provides a positive ROI without even considering the mitigation of business risks from undetected defects going into production use. Our assertion that challenged and failing modernization projects occur because of a failure to expose those errors and omissions in business rules derives directly from our experience in applying this methodology.

Assembling a 100% complete and correct set of active business rules is not a common practice. The experience of two projects, at the Federal Reserve Bank of New York and the US Patent and Trademark Office, completed our understanding of what is required and the basic economics of doing so and of not doing so. We describe the process, beginning with standard business analysis augmented by static business rule extraction tools.

We discuss a risk assessment process that can guide a decision as to whether or not 100% is truly required in any given project by focusing on the likelihood and cost of an error in production processing. When that cost and risk are acceptable to senior management, then in that case 100% is not necessary and dynamic business rule extraction need not be a part of the project. For such a project either business analysis + static business rule extraction, or business analysis alone, will be sufficient.