If you’ve worked in a corporate IT environment for more than year, either as a Business Analyst, a Developer, an Architect, in Quality Assurance, or in Application Support, you’re probably familiar with how the typical IT project goes. For example, let’s say you’ve been asked to lead a project that involves building a system to manage a mail-order DVD rental service (like Netflix). The project would likely cover these basic steps:1. The Business Analyst works with the Business Stakeholders (often referred to as IT’s clients) to gather business requirements.
2. The Business Analyst then works with a Systems Analyst or Architect to translate those business requirements into System Requirements.
3. The System Requirements are then handed to a System Architect who describes a “physical” design to implement the aforementioned System Requirements.
4. The Architect then works with the Developers and QA to ensure their physical design is being correctly implemented.
5. The Business Analyst performs User Acceptance Testing as approved by the original Business Stakeholders to ensure the requirements have been implemented as expected.
6. Once the stakeholders sign-off on the user acceptance testing, the system can be moved into production.
Of course there may be other necessary steps to follow. Such as:
a) A security assessment, to ensure the system upholds corporate security policies
b) A data architecture review, to ensure the system is properly aligned with an Enterprise Data Model
c) Load testing sign-off, to ensure the system can meet the required query and transaction volume
d) Availability testing, to ensure the system doesn’t have any single points of failure, and can meet its availability requirements.
The last four points, while necessary, are not specifically of any interest outside of IT.
Now, in our example, given that this system is a DVD rental & return system, we know that the following business rules are going to have to be present:Rule #1: A customer may rent the movie only if the movie is in stock
Rule #2: A customer may rent the movie only if the movie has not been reserved by another customer
Rule #2: A customer should be charged a late fee of $5 at most once, only if the customer’s movie rental is received past the due date.
Rule #3: A Customer must not have more than three (3) movies out for rent.
After our system has gone into production and customers are now actively using it, we may begin to see following questions:
How often does Rule #1 & Rule #2 result in the customer not being able to rent a movie of their choice?
How often are customers being charged late fees as a result of Rule #2? How about if we change the late fee to $1.00. How often is this rule invoked then?
For Rule #2, if we change the limit of 3 movies to 2 movies, how often are customers trying to exceed the limit, and is this impacting our bottom line?
To answer these questions, in all likelihood extensive changes would need to be made to the underlying system to explicitly log rule behaviour, and from there generate custom reports. For question #3 (where we’re changing the limit from 3 down to 2), we would also likely have to perform some heavy duty statistical analysis that may be beyond the purview of anyone working in the IT department.
Another issue we may face after the system has gone into production is that we may also have the need to drop Rule #2, thus allowing customers to rent movies that are currently under reservation by another customer (a certain Seinfeld episode comes to mind here).
For the questions stated above, as well as the modifications requested, IT will likely require the Business Stakeholders to pay for expensive Change Requests, which are effectively small projects. Furthermore, the change to drop Rule #2 (especially if that change is requested after the original development team has disbanded), could be very costly. A single change alone would require extensive review of the original Business Requirements Documents, System Requirements Documents, the original source code, and this is before even making a single change. Furthermore, many of these documents are not always up-to-date or easy to locate, and it is not uncommon to see a disconnect between these documents and what has actually been implemented (typically because these documents are not maintained ).
Instead, if you take a Business Rules Approach you treat your Business Rules as information assets unto themselves and are now in a much better position to reuse business logic. Even when technology changes you can easily carry your Business Rules forward to the next platform as the English descriptions of the rules are always tightly coupled with the underlying implementation. For example, if your rules are implemented as static components (e.g. COM components or EJBs), you could convert them to on-line web services with relatively little impact analysis.
The Business Rules Approach has the following advantages:
The Business Rules Approach provides best practices for describing the rules themselves in an unambiguous manner. This form of documenting rules has been developed by Ron Ross and is referred to as RulesSpeak.
The Business Rules Approach requires a Business Rules Management System (BRMS) to execute the rules themselves. Once the rules are placed within a BRMS, the rules can be changed, added or removed by a business analyst, as there is no longer the same distinction between business logic and application logic (there are limitations as to what a Business Analyst can do here without assistance, but we’ll get into that later). In other words, the business logic is in plain sight and can be changed without requiring the business analyst to understand the underlying system logic. This ensures that there is always a tight coupling between the plain English business rules, and their actual implementation, effectively guaranteeing traceability between code and requirements. Furthermore, the execution history of the business rules can easily be queried and analyzed to understand how the rule has been behaving.
When utilizing a BRMS, the Business Rules Approach tightly couples plain English definitions with the underlying implementation, so there can be clear traceability between business requirements and what’s actually running. Furthermore, because the descriptions are located alongside the implementation, it’s easier to ensure that documentation remains up-to-date and is easy to locate. This greatly reduces support costs as the Application Support team can quickly assess if the system is acting according to the business requirements, and if not, how it deviates. One of the biggest problems Application Support teams have, is locating the original requirements, and often issues that are reported as bugs are in fact purpose-built features that have simply gone forgotten.
In summary, the Business Rules Approach is both a set of best practices in gathering and documenting requirements, as well as a set of technologies used to store and execute those well documented rules.
Going back to RuleSpeak (this is the set of best practices I mentioned above for documenting rules). In some regards, this is the most important aspect of the Business Rules Approach. Probably the biggest problem when implementing Business Rules is that their full set of consequences is not entirely understood, or that they are not precise enough to address nuanced scenarios. I attribute this to the following reasons:
a) The rules themselves are ambiguous. RuleSpeak addresses this directly by providing guidance and a set of templates that can be used to author rules. If you have ever taken a formal logic course in college or university, RuleSpeak will look familiar to you. Thus I suppose that one of the nice side effects of adhering to RuleSpeak is that you can make factual claims about your business through deductive logic.
b) There are too many rules in play at the same time. Remember Miller’s law of seven plus or minus two? Basically, people have a tough time keeping track of more than 5 to 9 things at the same time. This is why local telephone numbers are only 7 digits long. So if you have a system that must evaluate 30 rules simultaneously to arrive at a decision to say, qualify a customer for a loan. While it may be possible over time for the loan manager to get her head around the 30 rules, the first time customer encountered these rules, they would surely be bewildered and confused, especially if they are turned down for the loan. Instead, if the rules were parceled off into 5 categories, of 6 rules each, then the loan manager would only have to go over the 5 categories, and explain which category of rules the customer failed to comply with. For example, one of the categories might be Personal Collateral which in turn could be comprised of six rules:
a. Customer has assets in excess of $10,000
b. Customer’s qualified assets are located within Canada
c. Customer’s qualified assets can be liquidated within 60 days
d. Customer’s qualified assets are non-volatile
e. Customer has required documentation to vouch for qualified assets
f. Customer is willing to liquidate qualified assets on notice from bank
By grouping this sets of rules under a single “collateral” rule, not only does the customer benefit from being able to conceptually understand why they were denied loan approval, but the business also benefits from being able to understand which categories of rules are most often the reason for loan denial.
By addressing the above two issues, you are now in a position to align the customer’s thinking with the business’s. This on its own has plenty of value. How many times have you complained about some spurious charge on your cell phone bill, or had a question about a payroll deduction, only to be confounded by some obscure back-office accounting explanation that leaves you utterly confused? I know it’s happened to me. By clearly documenting rules, and organizing them into small manageable sets, you can mitigate if not completely avoid these issues.
I’ve talked about documenting rules, but how about their execution? I mentioned something called a Business Rule Management System (BRMS). There are over 15 commercially available BRMSs available, and at least one open source one. Often these are referred to as Business Rules Engines (BRE), and on the loftier side, Fair Isaac’s refers to theirs as “Enterprise Decision Management” (EDM), but at their heart these systems are all the same. Even Microsoft includes a rules engine with their BizTalk server. In spite of less than mainstream acceptance, there is no shortage of vendors. A sampling of these vendors includes:
1. Haley Systems
2. ILOG
3. InRule
4. Versata
5. PegaSystems
6. CA
7. Corticon
8. Logist
9. IBM
10. Microsoft
11. FairIsaac
All BRMSs are configured to work with the following three concepts:
A Fact Model. This is basically the BRMSs view of the database. In all likelihood, the data you should be executing against should be master data, so if you don’t have any Master Data Management in place, you should seriously consider doing so. Actually, you should have Master Data Management in place regardless, otherwise you will have multiple versions of “The Truth” floating around. Always a bad thing.
Rule Patterns. A Rule Pattern is merely stating the rule in general terms without specific constraints. For example, the rule pattern for Rule #3 (from above) could be stated as: “customer must not have more than X movies out for rent”.
Rules: The rule itself can be thought of as an instance of the rule pattern, and are thus derived from rule patterns. For Rule #3, we just replace X with the number 3 to get our rule “customer must not have more than three (3) movies out for rent”.
Once the BRMS has been configured with the appropriate Fact Model, Rule Patterns, and Rules, it can begin evaluating the Rules against your Fact Model. Most BRMSs apply an algorithm known as the Rete algorithm when evaluating such rules. The Rete algorithm is fairly efficient in that it can avoid round trips to the database when evaluating the same Rule or even Rule Pattern multiple times.
Ironically, most BRMSs that exist are neither purchased systems, nor do they neatly conform to the description I’ve provided above. Instead, they have evolved over time to meet a specific set of applications. This is not surprising since most people I talk to in IT are not aware that BRMSs even exist, but when I ask them how they manage their rules (especially for mature systems), they describe in their own language a system which is basically a BRMS.
There is also another reason why most BRMSs are home grown. Home grown systems are often able to achieve better performance. Namely, BRMSs, especially when executing a high volume of rules against a high volume of data (e.g. batch processing), tend to perform poorly when compared to a well tuned SQL statement running native within the RDBMs – there is simply an advantage to not having to go over the network. Also, because there are numerous tools to tune SQL (e.g. EXPLAIN PLANS), it is easier for most people to optimize an SQL statement, than optimizing BRMS rules. As a result, many home grown BRMSs are really just purpose-built SQL generators, generating massive SQL statements. Clearly, this is one major obstacle to the wide-spread adoption of BRMSs. That said, performance is in fact not a very good reason for NOT choosing a BRMS. Servers will continue to get more powerful, the BRMSs themselves will also likely improve, but people’s time will always be scarce. Even now, I’m convinced that with sufficient hardware all systems can cost effectively be run on BRMS and still significantly reduce costs, not to mention all the other wonderful benefits of the Business Rules Approach. If we also start thinking in terms of grid computing were computational power can be scaled up quickly on demand, I suspect that the performance issues are becoming less and less relevant. Remember, performance is not the same as scalability, and the BRMS will run in the same Order of time as the home grown solution even though it may underperform.
That said, the main reason the Business Rules Approach is not yet mainstream has to do with a lack of understanding, awareness, and interest from both the business and technical communities at large. I would attribute this to the fact that following the Business Rules Approach does not save money up front, but is only felt on the long term. In other words, if you are consultant, and have been tasked with building the aforementioned DVD rental system, taking Business Rules Approach (especially if you’ve never done it before), will not improve your time to completion, and will likely increase the amount of time it takes to implement the system. Of course all of these costs would be recuperated several times over once demands emerge to change the rules, or analyze the rules behaviour. This argument applies to numerous issues in IT, and quite frankly comes down to a governance issue. So if you’re not mandated to take a Business Rules Approach, you’ll probably take the path of least resistance and build something custom, yet rigid. Furthermore, because taking a more thorough and disciplined approach to document rules (a la RuleSpeak) also implies more time spent up front, the average Business Analyst may not be interested in making the effort.
My message to those folks out there that are interested in taking a Business Rules Approach: I implore you to do so. By following this approach you may get some pushback initially, but in the long run you will reap the benefits.
In a future blog post I will discuss Business Process Management (BPM), and how BPM complements the Business Rules Approach.
For more information, I suggest you join the BR Community portal. There you can find the RuleSpeak “Do’s and Don’ts” as well as a bevy of other resources pertaining to the Business Rules Approach. You can find the portal here: http://www.brcommunity.com/
As a closing statement, I would just like to quote PegaSystems slogan which I think succinctly describes the need for a Business Rules Approach:
Build For Change!
