Moderator:
Steve Nunez (SN), product reviews contributor, InfoWorld

Panel:
Maura Cole (MC), Business System Specialist, aigdirect.com
Darren Koch (DK), Senior Manager, Revenue Management, Hotwire
James Taylor (JT), author of “Smart (Enough) Systems“

The session started with questions from Steve:

SN: How do you work with linking your business processes to rules?

MC: We work with Excel to test the rules. This is a fully manual process, although we can move to production quickly. Rules are changed as part of a scheduled release.
DK: We tread the line between responsible/frenzied. There are no requirements beyond those in the heads of the analysts. Scripts cover the QA process. We can implement in as little as two hours. About half of that time is automated.
JT: There is the recognition that in an emergency things can be changed immediately. This is one of the big benefits of implementing rules.

SN: Do you have the ability to rollback if there’s a problem?

DK: We don’t have the kind of system eBay use. We normally just apply two rules at a time so we can pull these out if we need to.

SN: Do you have a governance process

MC: Yes, we have a team that are responsible for looking into this.
DK: We’re much lighter on this. I’ll approve changes and then pass these changes out to all engineers. Once this stage gets approved, the changes are pushed out to production. The original push for changes will come from the analysts.

SN: What is the process for passing rules down from business analysts?

MC: We don’t currently have the business analysts interacting directly with the rules. We’re interested in looking into the ILOG approach that can bring business analysts closer to the rules. We do currently let business analysts change the parameters of the rules - just not the logic.
DK: The IT department works on the BOM and keeping the site up. We originally started with a table that gets mapped to output.
SN: What is the biggest requirement for a BRMS?

DK: Speed of use. We’re constantly changing and trying new things. We make changes and we measure the effects.
JT: It’s interesting that some resources have to move. Business users need to add headcount - IT will loses some. This can cause organizational problems in dealing with this.
DK: We didn’t see it, but our organization is smaller.
MC: Our business analysts are not directly involved so it did not increase the resource requirements.

SN: What were the biggest challenges you face?

MC: Testing of the rules. Billing is complicated and these rules are difficult to change quickly. A lot of the rules are shared, and there’s a possibility that if you break something you can break something else further down the chain.
DK: We don’t have that problem as we don’t share rules across lines of business. We try and keep things in a linear process. All our rules are run realtime. For instance, when you book a flight, the rules are running while the bar moves across the screen.
MC: Performance is very important. A team checks that performance remains within company standards.

SN: Any unexpected benefits?

MC: When we put down the underwriting rules, no one in the business knew what the rules were. By exposing these rules, there’s new awareness of what’s going on. This transparency (not just to IT) is a good thing.
DK: We found something similar. eg. what is the process and how do things happen? We could go through the rules and look at the process, rather than having to rely on a software engineer.
JT: You will see IT and underwriters looking around the same screen - something that never would have happened in the past.

SN: Where is the IT function within the process?

DK: They concentrate on the BOM. They also vocalize the BOM.

Audience questions:

Question: When your business users starting writing rules, how did you test?

DK: We transitioned the testing. We had a script that sent thousands of simulated user searches through the rules. This helped us pinpoint problems.
JT: If business users are involved, there’s generally investment in automated testing. Tests that are meaningful to the business users, not just IT.
DK: We do have an error correction program. We never have the same mistake happen twice!

Question: Who were the sponsors for the deployment of rules?

MC: IT were the sponsors. Many IT analysts come from a business background so they were more aware of the business needs.
DK: For us, the push came from business users - an executive saw the value in the flexibility rules could offer and approached IT. The option was to buy or build. IT decided to buy.
JT: In my experience, both IT and business can be sponsors. IT tend to be IT-centric. This often adds another round to the implementation. The BOM needs to be redefined for the business perspective.

Question: How many rules did you start off with?

DK: We started by replicating a table with 10-50000 rows. This led to about 10 rules. Now we have 20-30 rules.
JT: Many of the best case studies have a very few number of rules.

Question: How do you manage the versioning if one rule is modified for another team?

DK: Our org is small - only 2-3 people change the rules. We keep it small and self-contained so that doesn’t really happen.

Question: How many people in the group change rules without changing the rest of the application?

Audience poll result: of those who responded, majority change rules without changing app.

Question: Is there anyway to extract the rules and see dependancies?

MC: Billing rules are embedded within use cases. These rules are pulled out to Excel spreadsheet and this can help spot dependancies.
JT: Another technique is to externalise the decisions from the use cases to cut down on the number of changes. The decisions change a lot more than the use cases.

Question: As you migrate the rules did you have any challenges?

DK: Security and access with our other systems. These systems are changed by engineers, not business users. The business users are sometimes overlooked and not told of these changes.
MC: We used a phased approach for migration. This worked for us.