Panelists

Bonnie Moonchild   Rules Analyst / Project Manager, JBS International, Inc.

Roger Smith   Lead Business Rules Analyst, Delta Dental of Michigan

Kathleen Barrett   Specialist, The Hartford

Paul Ulshafer   Project Manager, GE Energy

Joe Garrity   Architect, The Hartford

Ravi Singh   Senior Business Manager, Freddie Mac

Mukundan Agaram   Senior Designer / Architect, Delta Dental of Michigan

David Brown   Project Manager, The Hartford

Moderator

Gladys S.W. Lam   Co-founder/Principal, Business Rule Solutions, LLC

Topics

1. What is a 'good' type of project for business rules?
2. ROI collected on business rules projects
3. Time spent harvesting the rules, versus the actual implementation time
4. Fact modeling and business rules
5. Business rule or systems rule?
6. Fact modeling techniques / tools
7. Business process management versus rules engine
8. What's missing in current products?
9. Business rule governance
10. Optimization for performance?
11. Rules and the human factor
12. Roles & responsibilities for rules
13. Enterprise-wide business rules
14. Skill sets for the business rules analyst
15. Forms of business rule statements
16. Rules and the business person's role
17. Why so little use of business rules in government?
18. Business rules ~ for the routine or for the most complex?

.

Introductions

Gladys S.W. Lam   Good afternoon, everyone.  Thank you for being here.  This section -- the Practitioners' Panel -- is one of my favorite events of the Business Rules Forum, and you will see, as we go on, why it gets very high ratings.  Everything we discuss here will be transcribed, and it goes on the web site.  In fact, if you go to the Business Rules Forum website, you can see all of the previous years' panel discussions.  You get just tremendous information from all of the panelists. The way I work with the panel is that I have a three-part program.  One is:  I start by asking all of our panelists to first introduce themselves ... give us a little background about their project experience, what tool they used, and the business rules background and history of their organization.  And also give us a couple of DOs and DON'Ts in the business rule project they've been experiencing.  Then the second part is:  I will start off with a question or two, just to kickstart the panelists with questions.  And the last part I will open up to the floor to anyone who has questions.  Just raise your hand and I'll come over with the mic.  This is really an opportunity to harvest all of the knowledge that is up here on the podium.  Okay? So thank you very much to all the panel members.  We really have a vast amount of experience in this panel.  I'll start with Bonnie.  Bonnie, will you give us an introduction?

Bonnie Moonchild

My name is Bonnie Moonchild.  I work for JDS International.  I've done two rules projects.  One was with a large, social service State agency.  And the other was at a smaller, more agile corporation.  The tool I used on both of those was Corticon; it was my rules engine.

I have some DOs and DON'Ts.  The first is:  if, like me, you're a geek (come from a geek background), when you're doing rules DO remember the people and be really professional with them ... be really kind with them.  Without them, you don't have rules, except in the legacy code.

My other DO (and DON'T) is:  DO be realistic.  DON'T start off with a huge project the first time you're doing rules, especially if everybody on your project is doing them for the first time.

Roger Smith

My name is Roger Smith.  I work for Delta Dental Plan of Michigan.  We're a non-profit dental insurance company that's patterned after Blue Cross/Blue Shield.  We process somewhere in the range of ten million claims a year.

My background is ... I practiced general dentistry for twenty years before joining Delta Dental.  Along the way I became responsible for the procedures subsystem, as a part of the adjudication process.  To be consistent with business rules I'll define 'procedure subsystem' which is:  the use of dental procedure codes that are five digit procedure codes used to describe dental treatments.  In the last few years we've been transforming our procedure subsystem from a legacy system into a rules-based application.  That happens to be where a large percentage of our corporate rules reside.

My DO ... it's the people.  You have to have the right people, which really means you have to have top-level management support or it just doesn't work.  You have to have the First Team  -- not the scrubs.  In our case, we were lucky.  We had just the right folks.

The DON'T ... coming from a dental background it is:  DON'T bite off more than you can chew.  <laughter>  You just have to keep the scope and expectations under control  because you just can't boil the ocean and do everything.

Kathleen Barrett

Hi, my name is Kathleen Barrett.  I work for the Hartford Financial Services Group.  I've been involved in a business rules project for the last four-and-a-half years.  We use the Blaze rules engine, along with Java.  Our Group is primarily responsible for rules in the personal lines of auto and homeowner insurance. 

I have just one DO.  (Depending on how you word it, it can be either a DO or a DON'T.)  When you're considering whether to have business manage rules, DON'T let IT force the business into that decision.  It really has to come from the business.  If they're not committed to it, it's not going to work.  There's a lot of overhead involved in doing business rules.  We've been able to be successful, but the only reason we are is because our business people really believe this is the way they are going to achieve the speed-to-market that they are looking for.

Just one other thing.  I knew it was going to be painful being up here, but now I'm sitting next to a dentist ....  <laughter>

Paul Ulshafer

My name is Paul Ulshafer.  I work for GE Energy, which is headquartered in Atlanta, Georgia.  Our project was focused mainly on gas turbines that produce electricity for all of you.  Our project has now been elevated to GE infrastructure-level, where we are incorporating GE aviation jet engines into the same model, as well as GE oil and gas in Italy, GE aero in Houston, Texas....  So, a lot of different businesses from GE are coming into our model.

My background has been in supply chain.  I worked for Grumman Aerospace on Long Island and Pratt & Whitney in West Palm Beach, Florida.  I've been with GE for about six years.  I don't have a rules background.  That goes to one of my DON'Ts.  When your previous manager comes to you with an 'opportunity', beware.  <laughter>

At GE we are famous for taking on stretch roles, to say "Let's get you out of your routine and out of your comfort zone.  Let's have you do something different."  This is definitely different!  I've been in this role for about two years; I've learned a lot. 

I'd like to echo what was just said.  I'm sure there are a lot of IT folks in the room, but business rules are just that -- business rules.  They are not IT rules.  Business really does guide this.  You have to have thick skin when you're dealing with the IT folks.  Just stand your ground.

Joe Garrity

Hi, my name's Joe Garrity and I'm from the Hartford.  As far as my current role, I'm an architect in the Office of the CTO in the P&C Division.  I used to work with David and Kathleen at the Hartford, on the Personal Line side, but I've since moved.  Now I'm taking more of an enterprise view of what's going on in the P&C company from a rules perspective.

As far as my background:  I've been involved with rules for well over fifteen years.  I was involved back when it was called 'expert systems'; I've seen it go the full circle ... so if you stay around long enough what you learned back then will still apply today.  So I was able to leverage a lot of what I learned then.  I've worked for a number of insurance companies, as well as some software vendors.  As far as the rules projects I've been involved with, it has covered the whole gamut -- from medical eligibility, underwriting (from a P&C perspective), as well as doing some work such as a web interface to customize the personalization of the experience using rules.

As far as DOs and DON'Ts -- and this is for the IT folks out there:  DO as much as you can in the BRMS tool that you choose -- work there until you find that you can't.  What I mean by this is:  there are a lot of things that you can do there, and once you start going outside of the tool, it complicates things.  You've then got to try to keep things in sync, which becomes a real challenge for you.  Part of this is to work with the vendor.  If there are gaps that you see, work with the vendor to see if they can fill those gaps.

As far as a DON'T -- and vendors, please don't take this the wrong way -- DON'T believe everything the vendor says.  What I mean by this is:  when they tell the business that they can "change a rule on the fly," just make sure that the business really understands what this means.  You still need to have the same SDLC process in place to manage those changes to your environment.

One other thing I'll say as a DON'T:  DON'T think that a rule-based approach is another silver bullet, just like expert systems were.  You still have to go through the same amount of requirement gathering that you do with any other type of implementation.  Don't think you can shortcut that, because that's the most important part.  That's why they call it 'business' rules.  Make sure you're focusing on what the business needs are.

Ravi Singh

My name is Ravi Singh.  I'm with Freddie Mac, and I've worked on several projects that required rule set conversions, as well as tool evaluation, rule harvesting, and defining rules roadmaps.  We have been using RuleXpress for our rule management, ILOG as a rule engine, and Pega for workflow.

A couple of DOs and not to DOs ... which are shared with my colleagues here.  Determine the true need for rules.  Make sure that you really need rules before you jump into a rules solution.  And start with the business requirement, or rules roadmap, which should guide your business rules solution.  Another critical thing is:  keep your senior management informed and engaged.

A DON'T is:  DON'T make decisions based on the performance of a rules-based solution versus a non-rules-based solution, because whenever you are implementing a rules solution you will always have a performance difference.  Any time you hardcode rules you'll have better performance.  Flexibility -- what your business needs are -- should be your drivers.

Mukundan Agaram

Hi, my name is Mukundan Agaram and I'm a Sr. Designer/Architect at Delta Dental Plan of Michigan.  I work along with Roger Smith, who is my business counterpart.

I've had fifteen years of diverse software development experience, both functionally as well as geographically.  I've worked at Digital Equipment Corporation, General Electric Aircraft Engines, Siemens, and so on.  My last six years have been at Delta Dental,  of which the last three years have been on a business rules project, rewriting our claims processing system.  We are using ILOG JRules for our business rules engine, and we are using WebLogic Integration for our workflow tool. 

There have been a lot of DOs and DON'Ts, which makes this a difficult question.  There are several DOs and several DON'Ts that all vie for number one.  But I'll go ahead and give you one DO and one DON'T.  I'll give you two Cs for the two Ds -- the DOs and DON'Ts. 

For the DOs, my DO is:  Collaboration.  When I say 'collaboration' I mean collaboration in terms of architecture.  Your technical architecture should be able to collaborate with all the other technologies, meaning workflows ... the whole works.  As far as the team architecture goes, you need to collaborate well with the business side of the equation.  Collaboration is a key concept in any business rules project,

As far as my DON'T:  I would say "Compromise."  When you are going down the path of a business rules project, you are going down an exciting path with exciting possibilities.  But, this space is young and kind of immature.  The business rules vendors offer good innovation but in a limited sense.  But there are also times when you have to make a decision that your architecture will not be compromised because of limitations of the vendor.  You've got to make your architecture complete and seamless with the rest of the application.

David Brown

My name's David Brown and I also work for the Hartford Financial Services Group.  My current role is project manager of a team that's in charge of designing, developing, and maintaining systems that support various client applications.  We use Blaze rules engine for our business rules.  I've been in the role of supporting some business rules applications for about three years now; all that experience is with Blaze.

To talk about DOs and DON'Ts I need to mention how immature business rules methodology is in the environment.  Everybody here is interested in business rules -- that's why you're here.  So we have to be the marketers, the advertisers for the business rules methodology and take it back to the corporations and stakeholders and shareholders and senior managers.  Get them involved in the business rules approach and make sure they understand that there are benefits to the approach.  It will take us some time to get there, but there are benefits. 

One of the DON'Ts I want to relate is something that occurred with us in the insurance industry.  Our first application was underwriting rules, so we got pigeonholed into the perception that "the business rules group can support underwriting rules."  We weren't looked at for any other type of application.  Eventually, as time went on, we were able to prove to people that business rules are more than just 'underwriting rules'.  So, as you're out there implementing your first application, you need to be sure that you're not pigeonholed into that first set of rules that you implement.  Make sure everybody understands that there's a wide range of things you can accomplish using rules.

Gladys S.W. Lam

Thank you.  That's quite a vast set of experiences, as you can see.

I'm going to start with one question that's a multi-part question, so it's wide open for the panel to jump in and answer.  Let me start with my first question.

What is a 'good' type of project for business rules?

Gladys:  With all of your various experiences, knowing that you've been through multiple projects, what would you see as 'good' types of projects for business rules?  What do you recommend?  What should folks getting started be looking for?

Mukundan Agaram

From our experience it seems that business rules technology is a collaborative technology that goes very well with business process technology as well as business intelligence technology.  So any space that you see that has requirements for all three is a very good candidate for business rules.  For example, insurance is a very rich field, because you have a need to collect intelligence about your data, you have a need to collect intelligence about your processes, and also there are a lot of rules.

Bonnie Moonchild

Besides that, one of my favorite presentations I ever saw here was from someone who made really big trucks -- Paccar.  So it made me realize that business rules are good in manufacturing.  And then, going from really big to really small, they're also good in robotics.

Paul Ulshafer

I'll add something, as the rookie on the panel (since I've only been on one project).  With GE Energy and GE Infrastructure we're looking at long-term service agreements with our customers on gas turbines, projecting sales and costs out twenty years into the future, and all the variables that go into providing that forecast -- providing an accurate forecast to suppliers.  We were focusing on things that are of high impact and that change frequently ... things that you don't want to have hard-coded.  I'm sure the rest of the panel has experienced that already.  That's where our focus has been from the get-go -- high-impact, highly-flexible, highly-dynamic things that are going to change in your application.

Joe Garrity

I'll just add one thing.  What a lot of us are facing in the companies we work for is this retirement cliff that we hear about -- over the next few years where we're dealing with an aging workforce; people are going to start retiring.  And now it's a matter for us to get all the knowledge that's in people's heads into some kind of automated process if we are to provide the level of capability that the business needs.  In our company that's a big driving force behind what we're doing.

Roger Smith

To take that one step further...  I see us standardizing our approach to how we communicate.  Because we're so heavily regulated we have to comply with contracts -- how we interpret those contracts and then how we translate those into automated systems.  I see that as a big value-add for us. 

Ravi Singh

Business rules are useful wherever there is a need to share requirements across business domains.

ROI collected on business rule projects

Gladys:  Do you have any ROI that was collected in any of your organizations on the business rule projects that you've done?

Bonnie Moonchild

I did a project with a large State agency.  We didn't look directly at the dollars.  But we did take a process that took three people about two months to do (which meant that every year they were one month behind) and we made it so that they were a week early.  Our "ROI" was to go from eight weeks to three weeks.

Roger Smith

In the health insurance industry we have to comply with HIPAA, and every couple of years the codes change on us.  We have to then figure out how to get those into our systems.  I just did a comparison with our previous legacy system.  To insert one new procedure code into the rules... we had two different ways we could do it.  One is:  rely on the IT department to do it, which I figured would be somewhere around 80 hours.  And in some cases, we couldn't get IT help, depending on priorities.  Or if we did it manually, it would be 180 hours.  Using our business rules approach it took me 40 minutes.

Ravi Singh

We don't have dollar amounts as such, but to implement a new mortgage product it used to take us three to seven months.  And now we're able to do it within a month.  This is about 150 rules.  We were able to modify them and implement quickly.

Time spent harvesting the rules, versus the actual implementation time

[from the audience]:  How do you characterize the time you spent harvesting the rules, versus the actual implementation time?  Looking through the project experiences that you have, how far should we be along the harvesting the rules path before we dive in and start the implementation?

Paul Ulshafer

I can answer that one because it's a current discussion that I'm having.  We started harvesting rules for an application that we're beginning design of right now.  We started harvesting in February.  So that's roughly an eight or nine month period.  Things have changed so much since February -- changes in things the subject matter experts handed over to me -- that we're starting to get some obsolescence on things I did early on in the process. 

The hour before this session I gave a presentation with Rolando Hernandez from Bizrules on how we are using Excel pivot tables to harvest rules and make the process of harvesting faster ... providing metrics to management and version control.  So we are always looking for ways to do the harvesting a lot faster.

David Brown

One thing we found when we were harvesting rules was that, as you go along, you start to find some things that are no longer needed -- some bad rules, some redundancies.  So you want to be pretty far along in your harvesting process before you actually start to implement.  In our experience we were finding things right up until the end that we didn't know why they were there.  It wasn't until somebody said, "Twenty years ago, when they put it into COBOL code ...."  And it just lived forever.  You find those things as you go along, and you need to make sure you're pretty far along before you implement.

Mukundan Agaram

Before I answer the question I'd like to remind you of my colleague's comment about only biting off what you can chew.  The harvesting is a qualified statement.  It's critical to scope the project you're going to be harvesting rules for.  Typically we're working in a very collaborative fashion with the business rules team -- the business side of the equation.  On our side it took five people about six months to get the full set of rules for a good set of realizations.  This was for about 90% of completion for a good set of adjudication logic for claims.  The remainder was just polishing it off.

Paul Ulshafer

I'd like to add something.  When we started harvesting, we didn't limit ourselves to "is this a good business rules engine rule?"  We just started harvesting rules.  Now that we think that we're at the end of the harvesting period we're going back in to look at those that are (as I mentioned earlier):  highest impact, most dynamic, and give the most flexibility to the business.  We're calling this 'retiring' -- we're retiring a lot of rules that are valid but don't provide the flexibility we're looking for.

Bonnie Moonchild

I like to do my projects in smaller increments.  We'll gather rules for the first increment that we're going to do and then work with the people who are making the web interface so that we'll have something to show our users.  We like to do each piece like that.

There are some times we get to the end and we go "Oops!"  Or halfway through we go, "I don't think we should use that any more."  But our clients really like to see things in small pieces.  They're worried that they're spending a million dollars and they don't see anything until $999,000 is spent.

Roger Smith

We did some of that same sort of thing -- very small iterations.  My colleague was creating a customized management tool that sat on top of ILOG and as we were harvesting rules he was also creating this functionality at the same time.  We just kept rolling over those pieces.

Ravi Singh

One more thing is:  It's good to define smaller scope and stick with that scope.  Once you start you'll always find things that will take you more time to get to -- it becomes the never-ending end.  So it's better to start by figuring out your iterations, as well as defining scope.

Fact modeling and business rules

[from the audience]:  While harvesting the business rules, how many of you have really dived into fact modeling?  If you have, have you seen benefits from it?

Paul Ulshafer

I definitely needed to do the fact modeling for my own sanity.  As we talked about in the last hour, just getting your business to agree on terms can be challenging.  What do you call a 'gas turbine'?  Some people call it a 'motor'; some call it a 'turbine'; some call it 'equipment'; some call it 'that thing'.  You have to come to common terms and build that glossary up front.  And then, from that glossary, you have to agree how those terms relate to each other.  You do that by building that fact model. 

Then you have to build rules off of facts.  You can't build rules off of "I think this is the way it works" or "I believe this is the way it works."  That's the way we used to do it. 

I needed to build the fact models to understood what the subject matter expert was telling me.  They could then come back and verify it in the fact model -- "Yes, that's what I told you."  After that, we can build the rules, based on those facts.

Mukundan Agaram

In our experience, we found that fact modeling is just a great systems analysis tool.  It's not only a rules analysis tool; it's a systems analysis tool.  Any time you have difficulty communicating what the requirements are you have a very good case for a fact model.  You can use it to clarify the terms and facts that you're all using so we found it very useful in certain areas that were extremely sticky.

Business rule or systems rule?

[from the audience]:  I was wondering if any of you have had experience dealing with business users who are heavily IT-focused.  In that case, how did you help them to separate (or identify) a business rule from a systems rule?

Paul Ulshafer

I'll just lead off by saying that I didn't limit myself.  I just harvested.  If it was a UI rule, I harvested it; if it was an application rule or security rule, I harvested it.  And then we went back, together with my IT counterpart, and said, "Yes, that makes sense; that's a system rule."  or "Yes, this one makes sense; it should be in the rules engine because it provides flexibility the business needs."  So it's something we did together.  And I didn't limit myself to making that determination early-on.

Paul Ulshafer

For me, it was three simple things.  Is this thing going to change?  Is it going to change because the business made it change?  And is this going to enable the business to be flexible?

If you're going to bury it in the system, as a system rule, and it takes away from me some business flexibility, I'm going to argue with you. 

David Brown

We set up a rules governance organization, made up of senior-level architects within our Group, and also some rules architects and business analysts.  One of the first things they set out to do was to lay out different types of rules, different business needs that could come in, and decide:  Where do things really live?  Does this live in the rules engine?  Does it live in the rating engine?  Does it live in the front end?

That governance process was set up to define that.  And then the governance team would meet on a regular basis and decide, "Is this truly a rule that belongs in a rules engine, or is this something that can live down in legacy code?  Is it a front-end edit?"  That kind of thing.  They had documentation they used to guide them in these decisions.

Roger Smith

I was a little luckier.  Muk and I have been joined at the hip for a couple of years, and if he said it's a systems rule, it's a systems rule.

Mukundan Agaram

That's one of the advantages of monopoly.

Fact modeling techniques / tools

[from the audience]:  Back on fact modeling, for a second, could you tell what technique you're using -- E/R, UML, ORM.  And, if so, what tools are you using?

Mukundan Agaram

In our case, we used a white board with erasable markers.  That worked very well, <laughter/applause>

Paul Ulshafer

I'll take that one step further.  I use the white board, but then a white board needs to be erased.  So we wound up getting the big white tablets and we just sit with the subject matter experts and draw the fact model out.  We draw and we cross things out.  Then, at night, I put what we'd drawn into Visio so that it looked like it made some sense ... so that someone could read my chicken-scratch.  The next day I presented it back to the SME and said, "Is this what we talked about?" and they would validate it from the Visio.

Roger Smith

It also works to take a picture of the white board.

Gladys S.W. Lam

The question was if anyone is using ORM (Object Role Modeling).

Mukundan Agaram

We have been using UML but not so much Object Role Modeling.  We did attend a few sessions last year and it seems like a very useful technique.  We use UML because it is more widely accepted by the IT guys; they understand UML.

Business process management versus rules engine

[from the audience]:  There is usage of business process management solutions in organizations.  And, obviously, there is usage of rules engines in an organization as well.  I've attended sessions yesterday and today ... some speakers advise not to combine both, and some speakers don't take a stand on which technology to use.  Based on your experiences, when should an organization decide to use the business process management system (or a workflow solution) versus a rules engine solution?

Mukundan Agaram

That's a very good question.  One of my key rules of thumb is:  if you have a system where a human being and system work interactively together -- where human beings handle certain functions in the middle of things and the system takes care of other things -- you have a classic case that calls for a workflow. 

Rules are basically statements about your business that are non-deterministic.  In our experience we have noticed that they go hand-in-hand.  It's good to separate them out.  Do the business process management in a workflow tool, and the business rules management in a rules engine.

Paul Ulshafer

I can tell you that when we evaluated the five suppliers of five rules engines we applied our CTQs (Critical To Quality).  We looked at the BPMs and chose Pegasystems because of their BPM.  However, as we're designing we're try to take that babystep approach and say, "Let's just use a rules engine first.  Let's see if that part works." 

We may migrate to use the whole package at some time, but we want to start with the business rules engine and show success, and then move on.  But we did choose them because of the BPM capability.

What's missing in current products?

[from the audience]:  As people who've implemented and used rules-based solutions, what do you think is missing from the existing products that are out there?  What is the biggest hole that you see?

Kathleen Barrett

In our experience, what's missing are the rule analysis tools, embedded within the engine.  In our Blaze implementation, we didn't have that and so we had to build our own, home-grown version.  There's not a lot of query capability; it's hard for us to understand what we have in our rules engine ... in our repository. 

Mukundan Agaram

The other part of the equation is traceability.  This has been talked about a lot.  However, I think that's also a cloud because what 'traceability' is to one company might mean something else to another company.  This will differ from company to company, based on their  business.  I don't think there is a single way any rules vendor can address that completely so there's always going to be an architectural element where you need to provide your own traceability, specific to your  organization's needs and application needs.

Bonnie Moonchild

I use Corticon; I've used it in both my implementations.  The thing that I'd like to see added to it is more ability to document:  Who's using this rule?  Who said this is a rule?

Ravi Singh

Rules do not have a business-friendly user interface.  Also, there is no single tool that can do glossary/fact model simulation and also the rules deployment.

Business rule governance

[from the audience]:  We started the day this morning with a discussion of the governance process and how rules are really all about the governance process.  I'm wondering where your organizations are with that?  Have you defined a process and, if so, what does it look like?  What kinds of roles and responsibilities have you defined for that?

David Brown

I talked earlier about how we had a governance process set up to decide where different business needs or  requirements really should live.  What we found was that a lot of the needs and requirements that were coming in were being fast-tracked.  We already had documented where that piece of information should live -- whether it should be in the rules engine, the rating engine, etc.

Then, the business rules governance group went away -- disappeared for awhile -- and we found new things coming up ... a lot of 'discussion' between various areas about where this logic should live.  Should it be in the UI front-end?  Should it be in the back-end?  So they've found they had to reinvent the business rules governance to discuss this type of issue and make some decisions as to where these items should live.

Joe Garrity

If you look at it from an IT perspective, looking at solutions out there you find there's so much overlap -- a lot of these tools can do a lot of similar things.  And trying to pick the best solution is only going to become even more difficult.  One of my concerns is that depending on someone's background and what tool they're familiar with will drive where something lives, and it can end up somewhere that might not be the appropriate place.  For example, sometimes just having a relational table look-up is adequate, as opposed to a full rule-based solution. 

So I think that's our challenge -- trying to make sure people make the right decisions about where the best place is to implement something.

Mukundan Agaram

My opinion?  Business rules governance is the lifeline (the umbilical cord) for any business rules project.  You can't give birth to one without having a business rules governance body -- at least, not in my view -- because the project will die fairly soon without that.  One of the primary reasons I see is that this technology is hard; it is still climbing on the maturity curve.  There will be a lot of change.

It's very important for the business rules projects that you have management buy-in ... and more importantly that you have some structured form of sponsoring further improvements in the technology.  Without this, the technology is going to keep improving and, if you don't have funding for ongoing improvements, you're going to notice that your  solution becomes obsolete fairly soon.

Paul Ulshafer

This might be a bit simplistic, but it works for us.  Any calculation, equation, algorithm is providing flexibility, just by its nature, based on the variables that can go into the calculation.  So as a baseline we've agreed with IT that all of those, at a minimum, will be within the business rules engine.  And then we're building on top of that.

Optimization for performance?

[from the audience]:  Recognizing that rules-implemented systems give us greater flexibility, and acknowledging the need for governance in everything we do, I want to make a little shift.  As you got into production and you encountered performance issues, what things did you do to optimize performance, to keep your systems up and running effectively?

Mukundan Agaram

We are not in production, but we are getting ready to go into production.  We are at a point where we're doing parallel testing with huge volumes of claims.  In any system, what we have noticed from our experience is that database issues and database-related issues overshadow anything else in terms of performance.

As far as rules executing in rules engines?  They are relatively so fast they cannot get overshadowed by other issues.  Typically, in our experience, a big rule set of about 800 rules would execute in a matter of a few milliseconds as long as you don't do any database calls.  So the primary thing, in our experience, is database calls.  Those are the most resource-intensive kinds of operation.  And that's the case in any kind of system.

David Brown

The first project that we implemented was an auto insurance project, and we were generally averaging about 200 milliseconds to execute our rules engine.  Then we implemented a homeowner's application and we found that things were running in the one to one-and-a-half second range, and this was without doing any more data or new type of rules.  So we were curious about why that happened.

We used some Six Sigma techniques to drill down, to determine what was causing our performance issue.  It turned out it wasn't anything to do with the rules engine.  It had to do with some Java code that we had living beneath that.

So we've never seen a case where our rules engine wasn't performing well.  But we have had cases where some code around it -- like database calls, or Java code -- caused us issues.

Joe Garrity

I'll add a couple of points.  On our first implementation, before we hit production, we had some issues that were related to a lot of excessive object creation.  Those were the types of things we found -- managing all the objects was fairly extensive and that really slowed down the engine.  By using the profiler that Blaze provided, it could pinpoint where we were spending all our time. 

On an ongoing basis, the one thing I would suggest for any organization is make sure you set up a performance test environment.  What I mean by that is:  set up an environment that simulates your production environment as much as you can -- have the same set of hardware and duplicate production data in that environment; run a whole series of transaction volumes through it.  That will give you a good sense for how well things will perform before you hit production.

And don't think that, after your first implementation, you are done.  You're going to do this on an ongoing basis.  Sometimes you don't realize the subtle changes that might push you outside of the service level agreement that you're trying to meet.  So that should just be part of any release process that you have in place.

Paul Ulshafer

We haven't gone into production yet, but a process that we have been using is "proof of concept."  As we take on new GE businesses, they have different requirements. 

For example, one of the businesses that we just took on requires a stochastic simulation, as compared to a deterministic one that we're more familiar with.  We'd already chosen our rules supplier and that new business had already chosen a simulation tool (AnyLogic).  Before we said, "Okay.  We'll use both and go forward" we did a proof of concept.  While they did communicate with each other, the performance was not anywhere near where it needed to be. 

So, definitely, testing things prior to putting things together in production is vital.

Rules and the human factor

[from the audience]:  Moving from the topic of the technical performance, how was the performance of the human factor?  How many rules is it possible for humans to manage?  How do you scale beyond the pilots and the small projects, to thousands of rules ... where, even if you get the machine going fast enough, what happens to the humans that need to figure out what all those rules mean?  How do you scale across the human factor?  What have you actually seen out there?

Mukundan Agaram

That's an excellent question.  As we see in the market today, everybody has been talking about having good analysis tools to analyze huge rule sets.  But the problem space itself is kind of difficult.  I think for us to have a comprehensive solution in that direction is going to take some time.

But what we can do in the direction of quality of rules is provide good testing -- regression testing frameworks and analysis tools that will help mitigate some of those problems.  In our place that has helped a lot.  If you give the business users the right kind of tools, you're going to know that you will get high-quality rules at the end.  That's been our experience so far.

Roger Smith

I'll add to that with something that shows the difference between the IT and the business side.  I kept talking to Muk about "How am I going to manage all of this stuff?"  And he's over there working on his framework and his database. 

Ultimately we came together on how to manage this -- chop things up into reusable parts, have ways to name things that are sensible to both of us, and so on.

Ravi Singh

It is helpful if you can divide your rules into meaningful categories and groups.  You can then do your impact analysis based on that.

Paul Ulshafer

Also, you need to regulate what users, or what departments, can actually influence or change those different categories.  Not everybody should have the keys to the whole candy store.  Things should be compartmentalized into what the different groups can change.

Bonnie Moonchild

I work, generally, in smaller groups doing things.  We just handed out responsibilities -- "These are the rules about your customers.  These are your rules."  It works because we only have five little silos and people actually do talk to each other.

Roles & responsibilities for rules

Ron Ross:   I'm going to inflict onto the panel a question that I always get.  And since it's a hard one to answer I'm going to steal whatever good answers I can harvest out of what you have to say.  The question has to do with roles and responsibilities, and people -- I want to get back to that.        I want to ask the panel if, as they moved into their rule work, there were some roles that they didn't have that they needed to put into place, or that there were some new roles that emerged almost spontaneously because it was just obvious that they were needed and there were people ready to fill those breaches?  Or if you have any trends or any other ideas about matching people with what is this new style of approach to thinking business and capturing semantics?  This is a very general, open-ended question about roles and responsibilities.

Mukundan Agaram

Let me take a stab at it.  In our world, we started with a small team and a very collaborative team.  For example, I worked with Roger Smith, who's a dentist.  I would keep digging and digging and digging to get the right vocabulary out.  At the end, we had drawings of a tooth, and how the fillings actually take place.  He even went to the point of explaining a very complicated procedure to me. 

That's a long answer to get to the point.  There's a certain amount of rubbing off of experience that needs to happen within the rules team.  The technical guy needs to understand a little bit more about the business, and the business side needs to understand about the technical side of things. 

There have been times I've explained how UML works.  I've showed them how the ILOG rules engine works.  I've showed them what an IRL is.  I've showed them how you do term/fact modeling.  For people who are new to this ... they need to understand some of these concepts.

The other thing that I've noticed is:  a business rules project is very successful if every single area of it has ownership by a person in the team.  So, in that sense, the team should be fairly flat-structured, so that every person takes ownership of some specific area.  We had realizations where different people took the lead ... people who could specialize in that area.

David Brown

All along, we've been labeling our business analysts as typical  business analysts and our developers as the same developers, even though they know this extra rules technology.  One of the things that we're beginning to find is that we need to be labeling these people in something of a different light ... to say that they're really "rules architects" or "rules developers" or " business rules analysts." 

They have this extra set of skills that we really need to label and take advantage of ... and make sure we compensate for.  It's starting to become a big industry out there and people that have this knowledge and these skills are able to leave and move along.  If we didn't make sure that people were labeled as what they actually did, to set them apart from the other developers in the organization, it became a problem for us.

Bonnie Moonchild

I think, also, if you have a big enough organization you can 'sample' people.  When we did training on our rules engine we trained 6 IT people and 6 business people.  I found out that it simply broke down into who-is-good-at-it, and who wasn't and not along IT/business lines.  Three of the IT people and three of the business people were good at it.

That gave me the opportunity to go, "Oh, those are the people I want on my team, to do this first project."  However, if you're little, you probably don't have that ability.

Roger Smith

We added some subject matter experts for certain pieces that we needed along the way.  Some of those people have been raising their hands, saying, "I want to be part of this rules thing."  They thought that, because it was their particular area of the business, they should be represented.  However, in some cases, once they got involved and found out how difficult it was, they changed their mind and they were happy to let us continue taking that role.

But we have had a lot of give and take.  We are very fortunate that we've had a chance to all grow, along with our business rules experience.

Paul Ulshafer

I'd like to echo some of the things that have been said.  We've just recently created a new role, which has helped me a great deal.  I now have an IT rules project manager.  He's on the IT side but his focus is rules.  So I finally have an advocate over there.  I can say, "You deal with them.  You convince them because I need to spend time over here."

As you said, we also have business analysts, as well, who are rules focused.  You just can't be in every meeting that's going on, and they need to ask that extra one or two questions -- "Why is that?"  "How does that work?"  You need people who can make that determination and give you the right feedback.

Ravi Singh

On the business side, what we have done is divide the team into three groups.  One is 'business analyst'; another one is 'rules analyst'; the third one is 'set-up'.  Business analysts have expertise in the business domain; they're the SMEs.  Rules analysts are good at formulating rules, writing RuleSpeak, as well as if-then-else statements.  The third is the 'set-up' person, who is responsible for setting up the rules in the system.

Mukundan Agaram

On our team we added a fourth one, which we called the "Rule Nazi."  <laughter> 

Enterprise-wide business rules

[from the audience]:  I have a question on governance.  If we take it outside the project level and to the enterprise level, I've been faced with situations where you could have a rule that's of one business domain and used by multiple business domains.  We also have cases of rules used by multiple rule execution engines, which have multiple IT domains that support that as well.  Has anyone tried to create an enterprise (or somewhat enterprise-wide) governance committee?  And, if so, how did you go about that?

Paul Ulshafer

We actually have a "Center of Excellence" that is not associated with any particular business.  It's looking out for that very thing you are talking about.  We haven't put it into an enterprise "file cabinet" (so to speak) yet, but that certainly is the plan.  The Center of Excellence is looking to make sure that the common rules are at the highest level.  We all share the same GE Corporate commonality, and those need to be in the highest bucket are ones we all share.  This way there is not duplication, going down.

David Brown

To add on to that.  The CTO at our company put a rules foundation project together.  They made some decisions for the enterprise, across the board:  What rules engine are you going to use?  How are your rule flows going to look?  They made some of these high-level decisions.  This helped along the way, later, when new applications came along.

Joe Garrity

Our biggest challenge is from the business side.  We might be able to do all this from the IT side, but until the business decides that we want to use these rules it won't happen.  Someone in the business needs to say:  Whatever is done in personal lines will be reused across commercial lines (for example).  We can do all we can from IT, but until the business decides to do it it won't happen.

Roger Smith

In our business, so much is tied to these dental treatment procedure codes, which have rules tied to them.  Those codes get used in other parts of the adjudication system or other parts of the business.  Because of this, in some ways we get to control a lot because we control the procedure codes.

Mukundan Agaram

One of the bigger problems we have faced is not that ambiguity about terms but nomenclature of terms.  For example, we had something called a 'usual and customary fee', which is a fee you charge the dentist.  Later on it morphed into something called 'maximum allowable charge'.  Three months down the line, they decided to call it something else.  That causes a lot of confusion, and we don't have a really good solution for that. 

But that kind of thing happens.  And they will only shake out when you have team design meetings and brainstorming sessions.  Term/fact modeling really helps in that area.

Skill sets for the business rules analyst

[from the audience]:  I have a two-part question about roles and responsibilities.  First, for Ravi -- you said you had business analysts, rule analysts, and set-up analysts.  What skill sets did you look at to identify those different types of roles?  And then, for the panel as a whole, I was wondering what skill sets you looked for in between 'business analyst' and 'system business analyst'?

Ravi Singh

To answer the first part.  For the business analyst, they have to have domain experience.  What we did is look within the company -- we wanted SMEs -- and they were assigned the role of business analyst.  For rules analyst, it requires specific skills.  So we trained the team in RuleSpeak as well as if-then-else statements so they can perform the role.  We had an existing group that was performing set-up.  Set-up is not writing new rules.  It's more like lifting rules -- setting up negotiated products and programs.

Mukundan Agaram

I'll answer the second part of the question.  There are excellent resources on the BRCommunity.com site.  There is an excellent article by Kristen Seer about the "characteristics/traits of a business rules analyst."  It's a plain no-brainer -- I think it can apply to any business analyst.  I don't see making a distinction between a business analyst and a business rule analyst because a business rule analyst is The  business analyst.  There are lots of good resources out there, and we have tried to follow them.

Forms of business rule statements

[from the audience]:  As I've been attending the various sessions I'm hearing that we should be writing the business rules in business terminology.  I'm also hearing that we should be writing them in if-then-else statement form.  Looking for what you're doing, are there benefits and problems you're finding with doing one or the other?

Mukundan Agaram

I'll take a first stab at it.  To start off, there's always an evolutionary process in analysis of any kind.  You might start off with a segment of your statements that just uses casual English.  Then, as you start digging and start unraveling the layers you start to get more and more formal, until eventually you want to get very precise.  The most precise form is a mathematical form, but that's highly cryptic and few people can understand it.

To be very practical, what has worked for us is to start off with a business conversation and get it to a reasonable amount of somewhat structured, English form.  That's where terms and facts help because then you're not messing up your language.

Kathleen Barrett

Our business analysts use both RuleSpeak and if-then-else.  I'm not sure it really matters, as long as you adopt a common language that everyone understands and agrees on, and the terms are clearly defined.  I'm not sure if one syntax is better than another.

Rules and the business person's role

[from the audience]:  My question is regarding change in the business rules and something that I heard as one of the DON'Ts:  Don't listen to the vendors when they say business can change rules.  I wanted to ask you, when the rules change how do you foresee that change propagating to production?  Is this anything different from your regular SDLC cycle?  And for a second part of my question:  Do you think there is something missing in the tools that the engines provide that could help?  Finally, would you outright say that the business itself changing the parameters for the rules is an outright myth?

Mukundan Agaram

There are multiple scenarios for deploying rules.  For example, we might be running claims through the system and notice, "Oops!  We are mispaying this set of claims!" -- we are losing $500,000 a day.  In this case, we would go into production and change the rule, putting it into effect immediately to fix the problem.

There are other kinds of rules, such as those from regulatory bodies, that come up with version changes once in so many years.  When this happens it means widespread change -- we are changing practically every rule in the system.  For this situation, you need to have good analysis tools to identify the rules that need to change.  These changes need to go in in a phased manner, based on (say) the temporal effectivity date.

A third kind of situation occurs if your company is acquired by another company and you go from selling dental insurance to flipping burgers.  That is a whole different deal.  It's not just the business rules that change; everything changes -- your terms, your facts ... everything. 

So, even though I meant what I said, it came off kind of flippant.  On a more serious note, your deployment strategy, or your architecture, needs to account for various kinds of situation.  And you need to have migration policies and procedures for each of them.

David Brown

We have a standard release strategy.  When we have a release going into production, even if it's a critical, emergency production fix, we still follow the same set of release procedures.  We might have an emergency release for it, but we're never going to change things right in line, in production, because we don't want to affect 30,000 other policies when we make that change.  So, we follow set procedures, even if it's a rules change.  It's pretty much the same way that coding changes go through the environment into production.

Paul Ulshafer

Here's an example, on a smaller scale.  We're looking at things from engineering where they're still trying to develop maintenance factors that drive our turbines for maintenance.  And engineering doesn't quite feel that they have that defined yet, but they feel that they're close.  So we're building the calculation with that variable defined but giving it a factor of "1" so it has no effect on the equation.  But we are defining it as a term, and we are defining the variable in the calculation.  That way, when engineering does feel they have the right severity factor to give us, we can plug it in and it will work.

Mukundan Agaram

What we have done within our system is provide analysis tools.  For example, in claims we have a commonly-used term, 'drop to pay ratio'.  What does that mean?  If we have a drop to pay ratio of 85%, that means 85% of claims are not touched by a human hand, from the time they come through our door  until the time the payment goes out.  A human hand doesn't touch it, period.

But there are some scenarios where a claim is so difficult to comprehend -- its handling is so subjective -- that it gets routed to an expert who looks at it, evaluates it, and decides whether or not to pay it.

For things like that, suppose you wanted to change the rules, say, to cut down the volume that goes to a specific desk.  You would need to have analysis tools to help you identify things such as "Find all rules that route claims to this desk."  That's one kind of situation.

Consider another situation.  We determine that there is a certain policy we have in place that is causing us to lose x-amount of dollars.  So we decide to remove that policy, or to put another policy in its place.  We should have the capability of being able to trace every rule to the policy statement and have the ability to find rules based on the policy.  Having good analysis tools, combined with reporting, is the answer.

Why so little use of business rules in government?

[from the audience]:  I have an observation and I'd like your comments on it.  It's interesting to me to see that, here we are in the nation's capital and, amongst the panel, there is not one of you who work for government.  Even in the audience, with the exception of IRS, there is a dearth of government representation.  It's mainly insurance and industry.  I'm curious to hear your comments as to why here, where we have a goldmine of rules embedded in legalese and the code of federal regulations and the U.S. code, there is so little government involvement.  How might we go about gaining government involvement?

Bonnie Moonchild

If you were going to take things out of the U.S. code, you'd have to read it first ... <laughter> ... and that's a problem, if you've ever tried.  Seriously, my company does work for the federal government, but I feel isolated sometimes with all these great big companies, doing all these billions of dollars worth of things.

Paul Ulshafer

I can certainly see the IRS using rules, but I sure wouldn't want to be the guy harvesting them.  <laughter>

Roger Smith

Indirectly, we do work for the government because we have some government contracts through Medicare and Medicaid.  So I have had to read some of these things.

[from the audience]

I did business rules for the Department of Defense Business Enterprise Architecture.  We have a governance board and the rest.  I can tell you why we don't do more.  It's because all our decisions are made under political considerations, and you don't want to record those as hard and fast rules because now you're constraining the people who are making the political decisions.

Paul Ulshafer

Actually, Rolando, are you out there somewhere?  He could probably answer this.  For our contractual tax department, Roland harvested all the tax rules for eTax.  He could probably explain to you the complications of that.  That would be our closest government involvement.

Business rules ~ for the routine or for the most complex?

Gladys: I have time for one more question. [from the audience]:  This is directed to those people who are in the insurance industry.  I was struck, during the Derby and then again by a recent answer, that the questions that reach a certain level of complexity are the ones that are considered by humans -- it's a human intervention stage.  Yet, it seems unlikely to me that they are bringing anything into the consideration that really rises above the level that business rule could handle.  I'm wondering if you foresee a day (and I realize there's a political element to this) where the business rule engines will be able to handle those questions that have been traditionally handled on the human level?

Mukundan Agaram

That's an excellent question.  I once asked the question:  "We are in the dental industry.  Thirty-two teeth.  How complex can it get?"  I was told it wasn't about the thirty-two teeth.  <laughter>  It's about the money that you pay for the thirty-two teeth.

So, to answer your question, I think that's a very political one, and one that involves trust.  It's a question of nurturing the technology within the organization for years before the people come to trust it. 

We do have a lot of cases where claims are adjudicated manually, and these are ones where people don't yet have the trust level with the system; they don't believe the system can do it.  We are hoping that with business rules technology, at some point, we will reach 100% drop to pay claims ratio through business rules.

Roger Smith

I've addressed this within our company ... with various people, at various times.  There's a need, in the claims processor, to be perfect.  You have to have the data set up correctly -- you have to have all the rules correct -- so that what comes out the other end is paying the right amount, or not paying (and so forth).  Unfortunately, the world is messy.  The stuff that comes in is not clean.  And people do things to you to mess it up.  They get divorced; they have kids; they move.  They do all kinds of things.  They don't play by your rules.

Some things come with reports to tell you what actually happened.  Many of these require interpretation, which can be as simple as someone reading the report and then figuring out how to put the stuff into the system correctly.  Then, at that point, the system can take over.

I think there is a place for intelligence.  That's where a lot of this started, after all, ... a lot of the early artificial intelligence was directed at medical decisions.  Certainly we could go farther.  It's simply a matter that we haven't gotten there yet.

Joe Garrity

Judging from what's happening in my company, we're going to start seeing more pressure to drive costs down.  How do you do that?  Automate as much as you can.

So straight-through processing is going to increase.  We'll see people wanting to turn the ratchet up a bit, to do more and more.  This drive for cost savings, as well as the aging work-force and the ability to have the consistency that we need -- all these drivers are going to require rules-based solutions.

Wrap-up

Gladys:  Thank you very much. As usual, we ran out of time.       First of all, I'd to thank everyone.  Please join me in thanking the panelists.  They've been great.  <applause>  Thank you for the wonderful answers.  I learned a lot.  And thank you, also, for the excellent questions.

# # #