Enterprise Rule Applications
Business Rule Management System
by HSG on May 10, 2012 in Enterprise Rule Applications
I suspect that many of you are familiar with the term "hard coding a value" whereby the age of an individual or their location is written into the condition (or action) of a business rule (in this case) as shown below:
if customer.age > 21 and customer.city == 'denver'
Such coding practices are perfectly expectable provided that the conditional values, age and city, never change. They become entirely unacceptable if a need for different values could be anticipated. A classic example of where this practice occurred that caused considerable heartache in the IT industry was the Y2K issue where dates were updated using only the last 2 digits of a four digit number because the first 2 digits were hard-coded to 19 i.e. 1998, 1999. All was well provided that the date did not advance to a time beyond the 1900’s since no one could be certain of what would happen when the millennia arrived (2000). A considerably amount of work (albeit boring) and money, approximately $200 billion, went into revising systems by way of software rewrites and computer chip replacements in order to thwart any detrimental outcomes. It is obvious how a simple change or an assumption can have sweeping consequences.
You may wonder what Y2K has to do with Business Rule Management Systems (BRMS). Well, what if we considered rules themselves to be hard-coded. If we were to write 100s of rules in Java, .NET or whatever language that only worked for a given scenario or assumption, would that not constitute hard-coded logic? By hard-coded, we obviously mean compiled. For example, if a credit card company has a variety of bonus campaigns, each with their own unique list of rules that may change within a week’s time, what would be the most effective way of writing software to deal with these responsibilities?
A BRMS is a software application, typically written in Java but may also be written in C# or C++, that allows for the swift and elegant replacement of groupings of business rules or a repository of business functionality. Rules in this repository are often contained within XML files referred to as instance files i.e. instances or snapshots of the rules as they appear today, tomorrow, yesterday or some day. Replacing the file with another file replaces one set of rules for another. How did these rules get placed into XML files? Read my article titled: The Templatization of Business Rules.
The rules are placed into an XML format for the following reasons:
Placing rules into XML does not address how human beings can easily read this information. That's right; even us software engineers struggle reading XML. To compensate for this difficulty, some BRMS vendors have provided english like syntax akin to the following:
if the customer's age is greater than 21 and the customers city is denver
Consider that it is possible to have hundreds, if not thousands, of such rules that can be updated, deleted and added to the repository. Would it be possible for more than one individual to make these changes? How and when will the newer rules get deployed? How do we test these rules? Can I have of log of rule changes?
Architecture of the BRMS
The typical architecture of a BRMS is one that is centered on web technologies. The software developer, using a Data Dictionary, UML Class and Sequence Diagrams and copious notes gleaned from lengthy coversations with SMEs (Subject Matter Experts) develops a rule application via an IDE (Integrated Development Environment) that includes, among other things, a rule flow invocation, rule templates and a web application. This application can be used by a BA/Rule Author to edit rules using an internet browser or even an ipad. Once completed, the rules are stored, by way of the rule application, in the rule repository. The runtime application will then employ the rules to process incoming customers requests.
What comprises the web & application server is software that can handle incoming html requests, generate XML and HTML content, store the generated information in a repository, access this information upon an incoming customer request, create a rule network, use the network to access and to store information in the database and, finally, send a reply.
Software Development using the BRMS
You may wonder why there has been no mention of a componentized design whereby a group of rules represent a component that can easily be switched via some proxy or handle methodology for some other group of rules in an application. This is a common architectural design that has been used successfully in a number of large software systems: by componentizing different portions of the application, one component of functionality is replaced for another.
You may also wonder why I have mentioned BAs and ease of readibility and software development. Well here's something to consider: a BRMS is relatively ineffective if a BA cannot read and develop the rules. After all, BAs represent the business and its needs as described in the rules. Take the bonus campaign example, the BA is on the hook to ensure that money is not lost due to improper logic i.e. a bad rule. This is the reason that English like rule syntax languages have been created so that anyone can open an IDE to a BRMS and begin developing rules. It is also the reason why a component based architecture will not necessarily work since such designs are synonymous with compiled java, C# or C++ code, and compiling is not in the BA's realm of expertise.
If rule development can be done seamlessly by someone who is not a software developer, then the business is empowered to bring effective changes to market in an expidited manner. This means that the software developer is on the hook to develop rule templates that are used by the BA to construct the business rules. Now the BA does not need to know anything about templates. In many development environments, all the BA can access is a portion of the rules as they apply to their particular division.
Benefits of the BRMS
Disadvantages of the BRMS
blog comments powered by Disqus