≡ Menu

Live from Business Rules Forum – Reaping the Benefits of Rules through SOA and Business Rule Management at Travelers


Alan Weiss of Travelers and Brian Stucky of InScope presented on Reaping the Benefits of Rules through SOA and Business Rule Management at Travelers. Travelers is a Fortune 100 insurance carrier and Alan is part of a group focused on moving control over processing into the business. The key purpose of business rules in this environment is to empower agility so you can move to “zero time to market”. Knowing the rules and being able to support the business in making their own change while ensuring consistency really deliver this agility. Travelers’ policy systems could not support automated underwriting and pricing. So, for instance, only 17% of small commercial policies were going straight through and the rest were going to an underwriter. By and large these are small policies so referring to an underwriter makes a loss almost immediately. These prospects did not want to wait. Poor rating also led to adverse selection where they tended to attract the worse risks (who got bad prices from those with better systems) while better risks got better offers elsewhere. Rules were also spread out everywhere and hard and slow to change.

They went to get a BRMS to deliver speed to market and ensure that changes that were not subject to legacy test procedures so could be managed external to the legacy systems. Wanted a 2 day development, 2 day test to production sequence . Needed to support concurrent development of multiple versions as well as configuration management, backup and recovery. They picked ILOG’s JRules BRMS. They have a multivarient pricing model using both internal and external data implemented as rules. They implemented it over SOA using a .Net front end accessing Java services using SOAP.

They were doing an UNDERWRITING project and SOA and a BRMS happened to be the right answer. This is the right sequence – find a decisioning problem FIRST then decide how to solve the problem.

Brian focused on how using rules and processes together, and avoiding an overly formal semantic/enterprise model approach. You need to focus on a decision and how it fits inside processes. Think about decision management and think about it as part of how you do business process management. SOA is the key because it allows you to use Decision Services as an abstracted, distributed composite approach. SOA also allowed reuse across old and new architectures, multiple sites. Also helped limit and localize regression testing by defining concrete contracts for the interface between services. A good point – Decision Services need well defined contracts just like other services. Travelers tried to stay very focused on their business problem and not get carried away with using SOA. They focused on reuse and on making services atomic enough to allow this reuse while defining contracts first. All this took education.

Need to manage change and risk. Rapid change and deployment can be advantageous but can also be very dangerous. Must find the balance between speed and control. Consider the scope of data influence for the rules change, the code influence and the scope of the rules being tested. High impact changes should be deployed differently to more localized one. Different rules have different volatility and different requirements for testing, audit etc. You therefore will end up with more than one way to change rules and promote them into production. Business users might have low or no involvement initially or they might have real control over the rules. You need to handle emergency changes and small, localized changes without a lot of overhead. On the other hand you need a normal, regular release schedule for new rules to support new products, new customers. Perhaps also to have some pre-tested scenarios deployed in case they may be needed. They started off using the IDE to develop rules in IT. Over four months they transferred maintenance to the business users and rules are now updated every week.

Reporting from a BRMS is important and most offer good tools for searching and viewing rules and these can help with compliance. Rules are easy to read, though, so can do a lot more. Can ask why/why not, generate feedback and provide information about what happened to the business users so they can understand the processing that is going on. For instance, Travelers generated immediate reports on rejected policies, analyze validity of rejection rules, check lift from the pricing rules. Reports on referrals and subsequent manual treatment, for instance, allow you to gradually eliminate rules that generate unnecessary referrals.

Testing is also very important. Anyone making changes needs to be able to check that they work, that they do what was expected. You can also use testing tools to see what happens in certain scenarios – to simulate something or do impact analysis. Basic levels of testing include basic confidence that a rule does what it is supposed to, does it pass basic validation testing, can business people validate and approve the rules? Travelers did find that SOA made testing easier but also found that the testing of data was also important – services need the right data. The rapid turnaround of rule deployment forces you to automate testing and have focused rule packages to make it easier to localize these tests.

Straight Through Processing (STP) went from 17% to 45% on day 1! Two rule changes in the first week went to 75% STP – would never have known that this was causing so much of the referrals. 93% increase in policies quoted, 50% in policies issued, 58% increase in premiums which is probably also going to be more profitable premiums given the better pricing models.

They recommend that you

  • Start small
  • Bring in expertise if you don’t have it
  • Use out of the box tools when you can
  • Figure out change control BEFORE deploying rules as it is too late otherwise
  • Just because you CAN change rules quickly does not mean you SHOULD

Comments on this entry are closed.