Developing business software for specific industries can often be very difficult if the business process has not be properly analyzed from end to end. Without a proper analysis, it is difficult to come up with an effective design that won’t require a lot of downstream changes.
Much of the important analysis often happens during the construction phase when certain shortcomings and missing pieces of the process are exposed by the technical implementation. Such shortcomings are subsequently addressed by changing the requirements and specifications. It’s often the case that resolving such issues after implementation has begun will lead to “design under fire” methods in order to meet deadlines. Invariably, this can lead to shortcuts taken on the technical side that later become unwieldy and difficult to maintain.
To counter a lot of the issues with changing requirements based on business process concerns, many organizations have implemented a Business Rules Engine (BRE). The idea behind a BRE is to allow many of the business requirements to be expressed in plain English (or some other linguistic equivalent) that can be maintained by Business Analysts and give a business a lot more flexibility to change their process without the maintenance cost associated with having Programmers maintain such business process specific code.
For example, lets say you have some business logic that requires validating the following two data fields:
Signed Date
Application Entry Date
Now lets say that these two fields are related via the following relationship:
Signed Date must be within 5 days of Application Entry Date.
The fields maybe encapsulated as properties within a class called Application:
public class Application { private DateTime? _SignedDate private DateTime? _ApplicationEntryDate; }
In most situations, a programmer would write validation code as a method which checks the two properties to make sure the dates are not more than 5 days apart. If the programmer assumes that this validation is static and will always be based on a 5 day period, he may write a method within the Application class like this:
private bool ValidateDates() { bool retVal = false; if(this._SignedDate != null && this._ApplicationEntryDate != null) { TimeSpan ts = this._SignedDate - this._ApplicationEntryDate; retVal = (ts.Days <= 5); } return retVal; }
Now lets say that the business rule changes to this:
The Signed Date must be within 10 days of the Application Entry Date.
Since the acceptable duration has changed from 5 to 10, this would require a programmer to update the ValidateDates() method to modify the duration. In the process, the programmer may decide to add a parameter to the method so that he can control the duration and only modify the calling methods if the duration changes in the future.
The process of finding and modifying this code becomes expensive once the system is in production. Such a change would likely have to go through layers of change control, testing, and deployment before the users would see it in the system. Also it takes time away from both the business analyst and the programmer to make the change. Additionally, even if the programmer had foreseen the duration value changing, he still would have had to update the calling methods to reflect the change in duration.
Now lets say that this particular business rule validation existed within a BRE. It might exist as a plain English statement that looks almost exactly like the statement in the Requirements Spec document.
Signed Date must be within 5 days of Application Entry Date.
A properly implemented BRE would only require changing the 5 to a 10 and redeploying it to the server. This would have the side effect of also transforming your rules engine into a maintenance repository of all of your business requirements. You could ensure that your business requirements stay up to date and improve the documentation of the business process without digging into code rather than rely on Specification Documents that inevitably become out of date when not properly maintained.
Sounds great on paper right? Unfortunately, this scenario often doesn’t play out very well in the real world.
The big problem with most vendor-provided BRE’s is poor integration with the development platform. Development teams often have to write custom wrappers for their platform due to lacking vendor support or incompatibilities with the vendor provided adapters. Also, most BREs have no concept of discoverability and generally require a manual process to map objects to nouns, adjectives, and adverbs. Mapping English sentences to objects can often become a nightmare that requires a dedicated team of professionals whose sole purpose is to make sure the business objects have the supporting structure to be related via Business Rules. Any savings gained by using a BRE is often lost in the additional cost of maintaining such a team. And as many other developers have recently stated, changing business rules through non-programmers can create system instabilities that often make it to production systems due to the lack of good testing capabilities within the BRE.
