The Templatization of Business Rules

by HSG on Jul 05, 2012 in Enterprise Rule Applications

A business rule is the basic unit of rule processing in a Business Rule Management System (BRMS) and, as such, requires a fundamental understanding. Rules consist of a set of actions and a set of conditions whereby actions are the consequences of each condition statement being satisfied or true. With rare exception, conditions test the property values of objects taken from an object model which itself is gleaned from a Data Dictionary and UML diagrams. See my article on Data Dictionaries for a better understanding on this subject matter.

A simple rule takes the form:

Teaching You Tools to Become Empowered
To build a successful business and career, you must always keep up with changes in the IT Marketplace. AWS, Office 365, LinkedIn, Sales Force, SEO, Social Media are just a few examples of where knowledge is a huge factor for success.
Training with HSG addresses your knowledge gaps and provides you with the requisite tools to outpace the competition.

if condition(s)

then actions.

An alternative form includes an else statement where alternate actions are executed in the event that the conditions in the if statement are not satisfied:

if condition(s)

then actions

else alternate_actions

It is not considered a best prectice to write rules via nested if-then-else statements as they tend to be difficult to understand, hard to maintain and even harder to extend as the depth of these statements increases; in other words, adding if statements within a then clause makes it especially hard to determine which if statement was executed when looking at a bucket of rules. Moreoever, how can we determine whether the if or the else statement was satisfied without having to read the rule itself. Rules such as these are often organized into simple rule statements and provided with a name so that when reviewing rule execution logs one can determine which rule fired and not worry about whether the if or else statement was satisfied. Another limitation of this type of rule processing is that it does not take full advantage of rule inferencing and may have a negative performance impact on the Rete engine execution. Take a class with HSG and find out why.

Rule Conditions

Rule Conditions must be boolean expressions that resolve to either true, false, null or with some BRMS products unavailable or unknown. Such expressions can combined via the and and or operators:

if expression1 and expression2 or expression3

requires that expression1 must be satisfied as well as expression2 or expression3.

Rule Actions

Rule actions may execute any or all of the following:

  1. modify an object property

  2. object instantiation and deletion

  3. method invocation

  4. rule groups or sub-node invocation

  5. data retrieval from a DBMS, file, enterprise application or web service

Rule Template

Now onto the fun stuff. Suppose we had a number of rules which were very similar to one another; that is, their conditions are affected by the same object(s) and the action statements share lists of common functionality. The question then becomes would it be feasible to create a rule template that can be used to generate a number of these types of rules. The value add of this endeavor would be to allow a non-software guru i.e. a rule author to create these rules as they relate to the terms that they understand.

Rule Template

 

Let's take a simple example. Suppose we were to create a travel software program that included corporate travel discounts. There are many factors we would have to consider but we can limit the possibilities to the name of the corporation, the duration of the flight and the requested service class of the flight. The only action in the action statement of the rule will be to set the service class status. The rule author can then create a variety of rules that will determine the type of flight status for which an employee qualifies based upon their employer, the duration of the flight and their requested flight type. The illustration to the left provides an example of how a rule template may be constructed.

 

There are a number of things to notice about this illustration:

  1. Both conditions and actions are written in English like syntax. No dot notation or any other software like syntax should be required to confuse the rule author.

  2. The option to remove conditions from the rule should be provided unless the rule requires that they be part of the if statement.

  3. All conditions in this rule template are connected via the and operator. If this satisfies all such rule types, then job well done; however, if these expressions can be or'ed together, than the software developer/template author needs to include them.

  4. All mathematical operators in this example have been hard-coded. The equals (=) operator and the less than (<) operator are a permanent part of the condition. If these business rules may include a not equal to, greater than, greater than or equal to ... more options than the hard-coded options provided, this functionality should be written into the rule template

  5. Only a drop down list with 3 choices is written into the action template. If these rules may yield different options in the action statement, then each one needs to be included as an option by the template author.

What is not shown in the illustration is that the rule author can create more than one rule. Depending upon the constructs of both the condition and action statements, the number of rule permutations may be extensive. As per the article on BRMS, the resulting rules are stored in an XML instance file in a rule repository.

Limitations

After reading this article you may be euphoric, well maybe excited, realistically speaking intrigued by the possibilites of templatizing your business logic so that you may quickly react to the competition and modify/grow your options without technological limitations. Before you prepare for the challenge, let me identify some of the limitations:

  1. Before creating a rule template, you must have more than one, correction, make that considerably more than one rule, that should be generated from such a template. There is a lot of work that goes into creating templates, and to squander an inordinate amount of time and money creating them for one rule that will never change is, well, not the most efficient undertaking.

  2. Certain constructs should not be templatized. Rules that contain a fair amount of complex computations or functions, if you will, should not be modeled into a template. I can go on and on as to the reasons behind this suggestion; suffice it to say that presenting a rule author with the option to create a Fibonacci series or some other complex mathematical operation may not yield the desired outcome. Some organizations have realized this after they decided to include all of their business logic in a BRMS let alone a template; not only did they suffer getting the product to market in a reasonable time but runtime performance hits were incurred as these rules may not have been written to make the best use of the Rule engine when compared to running them via C++ or some other natively compiled language.

  3. Who will modify the rules? Who will be able to read them? When and how will these rules be deployed? Obviously, an entire deployment and security model needs to be built that identifies the players and addresses enterprise application challenges.

  4. Do you have the requisite expertise to begin building such templates and to aid rule authors in their development process? These types of endeavors require time, expertise and capital to complete successfully.

  5. If the object model tends to change a lot before or after creating these templates, look out! The development team may, forever, be in update mode having to incorporate these changes into the templates, sub-templates ... One little change to the object model by way of changing a property name or type or by including another property may have sweeping consequences resulting in a slew of compiler errors and hours of debugging.

Rule templates, as part of a BRMS, can be incredibly invaluable. Some applications cannot function without them because rule placement is on a client-by-client basis; that is, the rules of the application are unique for each client that purchases the product. These clients can enter their own rules so that the product functions in the manner they need. Rule templates also make rule replacement and modification quick and easy. Selecting a condition and action from a drop-down list is much easier than writing the code behind it.

Rule templates can also be the bane of the development staff when a lot of work goes into beautifying code so that everyone can read it and only some can change it. Perhaps writing a rule or set of rules without deriving them from a template may be the better option.

other blog entries

Course Directory [training on all levels]

Upcoming Classes
Gain insight and ideas from students with different perspectives and experiences.

Interesting Reads Take a class with us and receive a book of your choosing for 50% off MSRP.

did you know? HSG is one of the foremost training companies in the United States

Information Technology Training that enables companies to build better applications and expertly manage the software development process.

Our courses focus on two areas: the most current and critical object-oriented and component based tools, technologies and languages; and the fundamentals of effective development methodology. Our programs are designed to deliver technology essentials while improving development staff productivity.

Personalized courses for unique business and technology needs

An experienced trainer and faculty member will identify the client's individual training requirements, then adapt and tailor the course appropriately. Our custom training solutions reduce time, risk and cost while keeping development teams motivated. The Hartmann Software Group's faculty consists of veteran software engineers, some of whom currently teach at several Colorado Universities. Our faculty's wealth of knowledge combined with their continued real world consulting experience enables us to produce more effective training programs to ensure our clients receive the highest quality and most relevant instruction available. Instruction is available at client locations or at various training facilities located in the metropolitan Denver area.

Upcoming Classes

consulting services we do what we know ... write software

Design and Development
Application lifecycle management
We generate use cases, UML documentation, architect the system, create an object model, iteratively develop the system, unit and system test and modularize where necessary. These types of engagements are typically longterm and, almost always, incorporate a variety of software technologies.
If you are in need of expertise but only require the assistance of one or two engineers, the Hartmann Software Group can be of help. Instead of procuring talent by way of a placement agency who is likely to contact us, come to the Hartmann Software Group directly. You may realize some savings.
Mentor
The best way to learn is by doing.

The coaching program integrates our course instruction with hands on software development practices. By employing XP (Extreme Programming) techniques, we teach students as follows:

Configure and integrate the needed development tools

MOntitor each students progress and offer feedback, perspective and alternatives when needed.

Establish an Action plan to yield a set of deliverables in order to guarantee productive learning.

Establish an Commit to a deliverable time line.

Hold each student accountable to a standard that is comparable to that of an engineer/project manager with at least one year's experience in the field.

These coaching cycles typically last 2-4 weeks in duration.

Provide Expertise
Services for your business growth.
With the introduction of smart devices, e-marketplaces, electronic forms, SEO practices, big data, virtual office environments, media streaming and so much more, there is hardly a business whose livelihood is not, in some way, dependent upon the inclusion of such software functionality into its online presence, work environment and product offerings. Such inclusion often presents a complex array of challenges that are far beyond the expertise of the business as it demands an understanding of technological options, modular decomposition, backend systems integration and web services. Most importantly, the business requires IT talent and expertise; this is where the Hartmann Software Group shines. To that end, here is an overview of some of the services that we offer:

Business Rule isolation and integration for large scale systems using Blaze Advisor

Develop Java, .NET, Perl, Python, TCL and C++ related technologies for Web, Telephony, Transactional i.e. financial and a variety of other considerations.

Windows and Unix/Linux System Administration.

Application Server Administration, in particular, Weblogic, Oracle and JBoss.

Desperate application communication by way of Web Services (SOAP & Restful), RMI, EJBs, Sockets, HTTP, FTP and a number of other protocols.

Graphics Rich application development work i.e. fat clients and/or Web Clients to include graphic design

Performance improvement through code rewrites, code interpreter enhancements, inline and native code compilations and system alterations.

Mentoring of IT and Business Teams for quick and guaranteed expertise transfer.

Architect both small and large software development systems to include: Data Dictionaries, UML Diagrams, Software & Systems Selections and more