Enhancing IT - Business Synergy with Business Rule Management
Daryl Pereira 270002AW8D firstname.lastname@example.org | | Tags:  impact09 business rules
4,067 Comments | 37,099 Visits
This session covers the implementation of a Business Rule Management System (BRMS)-both the theory and the practical example of Hotwire's online travel booking system.
First off is Colleen McClintock from ILOG, an IBM Company, offering an overview of how a BRMS functions.
Business Rule Management Systems 101
Colleen starts by pointing out that business decisions exist throughout every business. Business decisions are made in the organization's operating processes and management support processes:
Examples include: cross-selling, product selection, order management, fraud detection, claims processing, underwriting and pricing. We have been automating our business decisions for decades to achieve operational efficiency. But automated business decisions in the modern world are unstable since they are subject to variation and change. If you segment your market and present different products or capabilities to different market segments (e.g. an insurance policy for the over-50s), or if your are in the business of providing custom solutions to your customers then you end up with variable business decisions.
In addition to variation, business decisions are subject to change. They change because your market changes; your business decisions are influenced by competitive, economic, and regulatory factors. Many of these automated decisions are hard coded into IT systems and can involve heavy resources or time to change. You need to be able to accommodate both variation and change in your automated business decisions.
How do you build for change?
Colleen uses the excellent example of building construction in earthquake prone areas, such as her native San Francisco. An earthquake can be viewed as a massive change to the system, so buildings like the Transamerica Pyramid building are built with such change in mind:
You need to consider all the following when assessing which parts of the enterprise are potentially dynamic:
BPM and BRMS are not just complements to SOA. They are key to being able to build agile applications on top of an SOA infrastructure:
Business decisions are made based on business policies. For example, when a medical insurance claim is processed, the heath care organization's business policies determine whether the claim is potentially fradulent, and if it is not potentially fraudulent, whether or not the specific procedures are covered by the policy. A BRMS allows you take the business policies represent them as rules. You write the business them in business rule language, store them in a repository with their associated meta data and execute them using a rule engine.
A key benefit of implementing a BRMS is to create a stronger relationship between IT (eg. architects and developers) and business users (eg. business analysts). A BRMS is not a one-size-fits-all solution. Instead a BRMS supports flexible implementation options so that you can define the right degree of collaborative development between business and IT depending on the organizational needs. Over time you can evolve the business-IT partnership to more fully leverage your BRMS investment.
Colleen then presented the Business Decision Maturity Model (BDMM) developed by Knowledge Partners International (KPI). Colleen used the BDMM as a framework for describing various BRMS implementation approaches to support different levels of collaboration between business and IT. The model moves from the decisions being completely unmanaged to autonomic:
To achieve the visible level of the BDMM, you begin to identify and specify the policies that guide your business decisions. There is value in doing this on the business side even if you are not yet sure of how you will automate your business decisions. On the IT-side a first step is to externalize rules from code: Identify change prone or highly-variable decision points and rather than writing them as code, automate them as rules using a BRMS. As an IT-led activity this approach will deliver agility on the IT side, but it can be too close to code and not accurately represent the business perspective.
To enable business agility, and move to the agile level of the BDMM, the next step is to decouple your business rule changes from the IT release cycle. IT normally schedules new release based on new functional specifications and platform upgrades. Business policy does not change on an IT cycle. You should allow the business to dictate when business rules are deployed. A BRMS allows you to change rules without changing the application code so the changes can coincide with the needs of the business rather than tying them to an IT-driven software release schedule.
You should get business users involved since they are the owners of business strategy and the associated policies. Initially you can do this by offering read-only access to the rules. Then you'll have begun talking a common language between business teams and IT.
Next, you can offer limited rules-authoring capabilities to your business users (so they can change templatized rules or decision tables). This approach allows business users a safe rule authoring and editing capability, increases business agility, and reduces the routine maintenance changes required of IT.
To fully exploit the IT/business partnership you can give the business full ownership and governance of the rules. With this approach business users write rules, test them, and perhaps even deploy them with little or no support from IT. IT provides the tools and infrastructure so rules are deployed safely and effectively. The benefit of this approach is that as you give the business more control you benefit from increased business agility.
Business policies frequently occur in different contexts and therefore are duplicated in different software applications. Using the BDMM (Business Decision Maturity Model) as a framework, to move from agility to alignment you need to achieve consistency in your business decisions and reduce costs through re-use. You can do this by sharing common rules and common elements in the busines object model or by deploying your business decision services as rule-based decision in the business services layer of your SOA.
As you expand the scope of business decision management from a single application to multiple applications and eventually towards the entire enterprise, it is valuable to establish a rule competency center. Having a dedicated function responsible for rule management and governance is valuable to promote the use of rules, make sure rules are reused, and share knowledge across different projects in the organization..
From the business perspective, it is useful to predict what will happen business policies change. For example, if your credit decisioning rules are less stringent will you generate enough additional revenue to cover the losses due to defaults? You may also want to understand how your rules perform from a business perspective using different data profiles. For instance, if you are currently doing business in Texas, would moving into the Oklahoma market (which is governed by different regulations) be an advantageous move? The business simulation capability of a BRMS can help you determine this.
To wrap up, Colleen makes the following points:
Hotwire BRMS example
Darren Koch of Hotwire explained the benefits the online travel site has seen by implementing a BRMS. Hotwire was started in 1999 with a specific mission: to take the excess inventory of it's travel partners (eg. empty seats on major US airlines) and sell these at discount over the web. It is now part of the Expedia group.
Given that they are a discounter, all prices are flexible and are only normally determined on the fly when users use search. At that point a pricing decision needs to be made. Previously, all the criteria for pricing decisions were held in an Oracle database maintained by analysts. Updating these rules could take months and in addition this was not a scalable solution.
In 2006 Hotwire implemented ILOG JRules. Within a matter of weeks the project had paid for itself. Even given Hotwire's tight margins, profit gains have been in the region of 5-10% increase per year.
In terms of scalability, Darren points out,
'We went from 30000 different price points into the millions'.
Rules drive the pricing and sorting of available options, whether it be booking a flight, a car or a hotel. On average, 20 rules are executed per second. New rules can be tested and deployed in a period of three hours (previously this would have taken months). Darren points out this is particularly beneficial in the current climate where there is a price war between the major travel partners. For instance, some airline operators are waiving booking fees. Hotwire can respond to such changes and have new pricing options in place in two hours.
Business teams (rather than IT) own the rules; management is down to a team of four business analysts who have no programming experience, and are generally statisticians and operations researchers. Since launching, 600 rule changes have been posted live to production.
In an answer to an audience question, Darren described how they test new rules using business simulation. Building a simulation model around 100 customers, they apply rule changes and look at the results. This gives a good indication of what happens when the rules go live. They also have real-time alerts that monitor rule changes looking for major adverse effects.
For more information on ILOG JRules, visit the BRMS Resource Center.
You can also view a more in-depth BRMS 101 session from the Dialog user conference.