A business rule management system (BRMS) is a suite of tools that both business analysts along with software developers can use to directly author, modify and manage policy as represented by rules. This can be done without altering the underlying software system. A mature BRMS is able to handle the complete lifecycle of rules within an organization and provides the means and methods to treat rules as a true corporate asset. A BRMS will also include a business rule engine (BRE) for the execution of rules to render decisions in a software system.


Given this approach, it would seem that a business rule approach is an obvious direction for any enterprise. Stories of agility and huge ROI, and the unparalleled need for rule-based systems have been well documented. IDC anticipates that revenue for the worldwide BRMS market will continue to grow from a 2005 level of $188.5 million to $455.1 million in 2010, based on the strong role that business rules management systems will have in building out the application infrastructure platforms.1 But, where will that growth and expansion happen?


It’s clear that over the past decade early adopters of a business rule approach have been major players in industries where markets are dynamic, competition is strong and complexity of policies is high. The mortgage, insurance, telecommunications and banking industries have all been active for quite some time. The litany of users includes names such as Freddie Mac, Travelers Insurance Group, Verizon and Credit Suisse. Notice a common theme in that list? These are all large companies with a significant investment in IT and staff. So where does that leave companies in markets where business rule agility is no longer a luxury but a mandate? How do small and midsized companies get in the game? In the mortgage industry, some estimates have suggested that only 10 percent of the over 8,000 lenders can afford the investment to acquire, implement and maintain their own BRMS.2


The software packages offered by the leading BRMS vendors are increasingly sophisticated and have eased technical barriers to entry in terms of both development and maintenance. Products are integrated into both Java and .NET environments, work with traditional enterprise IT tools (e.g., source code control systems and databases), and provide full lifecycle support for business rules. However, jumping into a business rule solution is still an expensive proposition. Systems residing in a J2EE environment require additional software to support those needs. Throw in a database, and you’re looking at a sizeable investment! Skilled business rule development resources – while becoming somewhat more accessible – are still a scarce and costly commodity.


In addition to these cost barriers, there is a significant business obstacle. Modern BRMS platforms are terrific at rule execution and management. Finding the rules and putting them in the system is a different story. In the days of artificial intelligence, the task of finding, documenting, analyzing and then creating the rules for a system was known as knowledge engineering. It is probably the most important of all the activities surrounding business rule development. It is also the least understood. In any organization, business rules likely exist in a variety of disparate sources, including legacy software systems, policy manuals and in the heads of human subject matter experts. This difficulty is further compounded by the likelihood that differing interpretations and representations will result in the need for resolution to eliminate inconsistencies, conflicts and redundancies from the rules collected. Again, bringing in costly consultants to assist in the process is only an option for the largest of companies.


So the question remains: how do we bring the power of business rules the rest of the market? The small to midsized companies are probably the ones who need it the most. In many ways, they must be the most agile – both in terms of responding to the market and their competition.


Realizing the dilemma that faces many companies, some vendors have moved to provide industry-specific turnkey solutions based on rules. By being able to shrink wrap a rule execution and management system that is populated with common industry rules, these vendors can provide the needed capabilities at a somewhat lower cost. This certainly brings much of the needed rule agility to their customers – however, it does so at the cost of true flexibility and still requires users to have the expertise to manage their rules. And too often it still comes at a high price.


A more promising answer for today lies in a technical concept discussed quite frequently: service-oriented architecture (SOA). If the cost to bring rules to small and midsized companies is too great, perhaps they can be brought to the rules. Imagine a scenario where a completely disparate transactional system handles rule execution and a third party is responsible for rule management. When a business process requires a decision before moving forward, a call would be made to a service that can load and execute the appropriate rules to render that decision and return the answer. Industries with established standards (i.e., mortgage and insurance) have already provided common terms so that everyone can speak the same language. In a mortgage scenario, an originator might have services available to execute rules at several different steps in the loan process: determining whether a borrower can be underwritten, finding the best available loans that meet the borrower’s needs, and then searching for the best prices on those loans found across as many lenders as possible. The rules representing all these lender terms would be stored and maintained in a central repository to ensure consistency in representation and coverage. This would allow smaller organizations to reap the benefits brought by increased agility while not requiring massive up-front investments – they only need to pay for the transactions they send.


Turnkey and service-oriented solutions are possible answers for today. Tomorrow may provide more interesting possibilities.


In the new world of business on demand we can consider a seemingly pragmatic approach - give them the rules they need when they’re needed. The CEO of one of the major BRMS vendors has expressed his desire for a world where executives one day exchange rules where they now exchange spreadsheets. Unfortunately, each BRMS vendor relies on their own proprietary syntax for specifying and executing rules. At this point in time, rules written in one vendor’s language will not execute in another. There are some research directions that might start to tear down this wall but until there is a common standard for expressing business rules they will not cross vendor’s technical barriers.


Interestingly enough, several of the industries that were among the early adopters of business rules have been taking steps to provide their own industry-wide standards. ACORD (global insurance standards) and The Mortgage Industry Standards Maintenance Organization (MISMO) were each created to establish a foundation for common vocabularies, standards and frameworks in their respective domains. Recognizing that there are a vast array of hardware and software platforms used by companies dealing with the same fundamental concepts these organizations are attempting to facilitate information sharing and collaboration. Why do we care about this with respect to business rules? Companies that are compliant with these standards have created the necessary infrastructure to handle information transmitted in these formats. Consequently, we now have a common set of attributes (and corresponding vocabulary) for generating business rules that utilize these attributes. Common business rules represent the next logical step. However, it is important to remember that these approaches only address vertical solutions and not a general technical interoperability.


General technical directions are certainly being pursued. There have been several attempts at an XML standard for business rules (RuleML, SRML, BRML) but nothing that has really emerged as a leader. The idea here is that this general expression of a business rule would be readable and ultimately executable by a specific BRE. The Rule Interchange Format (RIF) is a World Wide Web Consortium (W3C) standard to provide an XML-based language for exchange of rules between execution environments for both runtime persistence and interchange. This work is extremely promising but has a long way to go. In addition to handling differences in technical representation between vendors, this level of interoperability must also deal with language constructs that vary from platform to platform. Success here would mean that the ultimate choice of BRE would no longer matter and rules in a RIF format would execute everywhere. Alternatively, the Production Rule Representation (PRR) is an OMG standard to provide a formal, platform-independent meta model for production rules that would allow them to become objects in the Unified Modeling Language (UML) – a very popular and common method for object modeling in system design. Both would provide vendor-neutral alternatives for providing – or even sharing – business rules.


One of the long-standing claimed benefits of a BRMS is that it allows the business to truly control the business. While the technical rule compatibility we have discussed will promote the collaboration and sharing of rules, perhaps the approach taken by the Object Management Group's (OMG) semantics of business vocabulary (SBVR) initiative will truly make this claim a reality. SBVR is being created with the business side in firmly in mind. This specification is focused on supporting the interchange of business vocabularies from a business rule perspective and is intended for a use that is independent of any system specific hardware or software. The SBVR standard along with the aforementioned industry standards may ultimately provide a powerful combination.


Rules are clearly here to stay. Now it’s just a matter of letting everyone play by them. And in the not-so-distant future, the creation of cross industry standards – both horizontally and vertically – hold the promise of lowering the cost and time barriers to entry and enabling true interoperability across and within industries.



  1. Stephen Hendrick. Fair Issac Interact Conference. May 16, 2007.
  2. Scott Kersnar. "Rules-Based Systems Call the Plays." Mortgage Technology, January-February, 2007.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access