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'

then ...

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?

If you are thinking along the lines of using a scripting language such as Javascript or VBScript, think again. Though they may work, these languages are not considered industrial strength enough to be used in large scale transaction systems to handle many simultaneous requests/responses, security, debugging/testing and the like. They are, however, being used in other business transactions, the internet for one and even in some JMS (Java Messaging Server) Applications to add business intelligence for message delivery. You may have thought about other scripting alternatives such as Perl, Tcl, Python and Ruby that can be used to dynamically replace business functionality at the flick of a switch so to speak. The value add of these software languages is that they allow for faster software development/testing than Java, .NET or other compiled language, they have been used extensively by large organizations such as Google and their processing time is relatively fast since their commands are running C functions: the foundation of most operating systems. This means that business logic substitution can take place without having to recompile, and change can be implemented quickly. On the negative side, they tend to be less intuitive to use and implement for a myriad of reasons ... cryptic coding practices, non-strongly typed, elusive scoping boundaries, incomprehensible runtime error messages ...; these are the issues with which the software developer has to contend. To ask a BA (Business Analyst) to do the same would be a nightmare for obvious reasons. So what language or development environment can be used to quickly replace business rules without their being hard-coded, does not employ a scripting language, addresses security and performance management constraints and is easy for both the BA and software developer to read? Business Rule Management System (BRMS) to the rescue!

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:

1. can distinguish a well formed document using XSDs (XML Schema Defintion) or DTDs (Document Type Definition) - this means that if the rule entries are incorrect, the well formed document checker will let us know.
2. parsers, either DOM or SAX parsers, are readily available and are often built into the API of the software language (C# in particular) enabling for ease of storage and ease of reconfiguration back into the system
3. no database is required. The need to create database tables with strongly typed columns (anything other than varchar, text or blob) is not a requirement.
4. rules in a BRMS are organized in a network that can be visualized as a grouping of sub-networks contained within a larger network that are organized by flow of events or lock-step flows as illustrated in the figure below. The colored nodes represent sub-networks, black/white nodes represent decision nodes and/or sub-flows ...

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

then ...

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

• Reduced reliance upon IT - the entire point of rule templatization is to enable rule developers i.e. non-software engineers to write rules without the assistance of the IT department.  This is a major benefit to the organization as the time delay between rule deployment in a traditional software environment vs the BRMS is considerable enough to warrant a proof of concept or a discussion at the very minimum.  Testing and Quality Assurance should still be involved to ensure the system integrity prior to each rules update.
• Rule managed is controlled by the business - with IT 'out of the picture', business managers now have control over rule lifecycles and editing of rules.  With one less department in the mix, confusion is minimized.
• High correlation of business venacular to rule development - rules can be written in such a way that they can be read by anyone familiar with the business thereby not requiring IT expertise.  See the article An Object Model and the Data Dictionary  Components such as decision trees, decision tables, score models and rule flows offer an immense development aid.
• Automated processes can be instituted to deploy rules.  To react to market changes and the competition, this may prove invaluable.

Disadvantages of the BRMS

• Extreme expertise required to develop and implement - Individuals that posses vendor specific BRMS knowledge, business rules knowledge, advanced software skills to deploy, design and develop applications, communication skills to effectively communicate with the business and knowledge of industry best practices are required.  Since such individuals are rare, they may be employed only with considerable expense to the corporation. 
• Extensive development cycle is the norm - Creating a BRMS is not easy task as it requires a stable Object Model, rule harvesting, organization and template rule creation and system design and development that includes a well defined security model.  All of these processess are not common to an out-of-the-box vendor BRMS implementation and are unique to each development environment. 
• IT departments may always need to be involved - something as simple as introduction of new rule condition requires the involvement of IT department.  If new rule types are introduced, there, too, the IT department will have to be involved.  The goal to dispense with the use of the IT department may never come to pass.
• Not optimized for highly computational tasks - a BRMS is not the ideal development environment for writing complex algorithms for a number of reasons beginning with decreased efficiency of the rule engine to handle these computations and ending with a failed attempt to templatize such code.  If it is difficult for the IT department to implement, it will be difficult for the rule developer to do the same.
• Perturbation of the Object Model may have system wide implications - having been involved in a number of BRMS training and consulting engagements, it is our experience that something as simple as an enum can reak havoc on software development requiring, at times, hours of work to fix compiler errors.  Though this may be true for the general software process, it is especially true for a BRMS since the way data is sent to the rule engine is typically by way of an object model.  Obviously, if the model changes it willl affect all the rules whose conditions and actions are dependent upon it.
• Strong coupling to a particular BRMS vendor - once the decision has been made to develop a system using a BRMS, the success of implementation hinges upon the functionality and attributes of a particular BRMS vendor.  The option to write-out or remove this product without serious cost, development, efficiency and time implications are next nill.