Panelists

Mike Lockhart	Program Manager, Microsoft
Emily Springer	Business Architect, UNUM
Leslie Blumenfeld	Director of Application Development, Fortegra Financial
Robert Dizinno	Lead Business Advisor, USAA
Kathleen Barrett	Senior Tech Lead, The Hartford
Jerre McQuinn	Principal Solution Manager, Microsoft

Moderator

Gladys S.W. Lam

Co-founder/Principal, Business Rule Solutions, LLC

Topics

1. What is your advice for getting started: project fit; ROI; getting approval?
2. Is Excel a good tool to use for 'starting small'?
3. What is the role of the IT Business Analyst when the users are doing the rules?
4. How do you get the business to accept the rules role and not want to push it back onto IT?
5. If you start with only a small pilot, don't you end up with two systems to maintain?
6. What level of detail were the rules in your initial project?
7. What are the characteristics and qualities of a good business rules analyst?
8. Where do you find that the rules end up — in the UI, in the database, in the rules engine?
9. Who has what role in a rule change?
10. Once you are operational, how long does it take to effect a rule change?
11. How do you test your rules for quality before they are implemented?

.

Welcome & Introductions

Gladys S.W. Lam:    Good afternoon, everyone.  Thank you for joining us.  This is really my favorite part of the conference, and it's always a lot of fun.

This is where we have practitioners who have been there — done that and will share their experiences.  We like to have very interactive conversations through this panel discussion because you can certainly learn a lot from all of the panelists here today.

Let me explain how this works.  There are three parts to this session.  In the first part, I will ask each of the panelists to introduce himself and give some background.  Then, I'm going to kick off with some questions that I have prepared to ask the panelists.  After that, I will open it up to the rest of you ... for anyone who has questions.  So, if you have a question while they are introducing themselves you might want to jot that question down.

To give you an incentive, I brought four types of chocolate from Canada ... four different flavors.  The first four to ask a question will get a treat — you get your choice when you raise your hand.

So, now to start.  I'd like to ask each panelist to please introduce himself:  name, organization, role, and, of course, since this is the "DOs and DON'Ts" Practitioners' Panel, also give us a couple of DOs and a couple of DON'Ts from what you've learned.  Then, say a few words about whatever tools you used in your project and what your background and experience is in business rules.

Okay, shall we start?

Mike Lockhart

My name is Mike Lockhart.  I am a Principal Program Manager at the Microsoft IT organization.  We (I and my compatriot down at the other end of the panel) have been on a journey to use SAP as our rules engine for mastering product price and program data within SAP — exposing it through Microsoft products and using the SAP infrastructure and engine to manage these rules about our core master data.

Probably the biggest DO we've had comes from our trying to use out-of-the-box SAP and encouraging our business users to think in high-level rules.  Where you get the bang for the buck (especially out of a package like SAP) is from trying to push rules higher.  We use the term 'policy' — what are your core rules?  We use low level rules where things are 'ticky-tacky', whether it's prices or attributions or whatever, using those as the low-level rules.  That's probably one of our biggest DOs.

For the biggest DON'T:  don't hard-code.  I know that seems like that's the theme from a technical perspective — how many times do you find that the rules are put into code?  No matter how many decision tables you put in front of somebody, seven times out of ten the person will come back with, "I have to write this in code."

Emily Springer

I'm Emily Springer, with UNUM.  I'm a Business Architect, primarily charged (recently) with implementing a business solution for business rules.  In-house we have RuleXpress and also Corticon, as one of our six rule engines.  Over the past year and a half we've been selecting a methodology, selecting a centralized repository, and then implementing those in a large company.

After all of that experience, my biggest DO would be:  Support your methodology and your repository with governance.  If you don't have governance it's going to fall apart.

My biggest DON'T would be:  Don't underestimate change management.  Moving from a situation where your business rules are either not captured or are everywhere in your organization, to a centralized methodology and a consistent syntax, is a big change for an organization.  Don't underestimate the change management piece.

Leslie Blumenfeld

I'm Leslie Blumenfeld.  I'm the Director of Application Development at Fortegra Financial.  My role in the company is to help set the technology direction and to support the business and development in making sure that we're leveraging the proper technologies and that they're serving the business.

That leads into why I got involved in the business rules aspect of what we did.  Over the last year and a half we took a ten to fifteen year-old (depending on which part you're looking at) claims system that was a green-screen, RPG on an AS400, and we breathed new life into it.  We chose InRule as our business rules engine , and without redoing the application, we actually externalized all the business rule logic.  Basically, we introduced business rules to the company and business rules to that process, and automated our claims system.  We did that in about nine months — not the whole project, just the first phase.

That leads into my DOs and DON'Ts.  I have a couple of DOs, and I'll make them really quick.  The first DO is:  Involve business and IT.  It has to be a collaborative approach.  It will most likely be led by one or the other — most companies don't immediately have an area that does this, so you do need a champion.  That can come from IT, or it can come from the business.  But you must involve everybody.

The second DO is:  Make sure that you identify what you want to do — identify your goal — and phase it.  What a lot of companies do is go out and say, "Well, we're going to do business rules!"  And then they find they didn't get the bang for the buck.  So, make sure that there's some actual goal in mind.  The goal may just be, "We're going to externalize our business rules."  Then if that's what you do you've succeeded.

A big DON'T goes along with that:  Don't try to oversell (or undersell).  If you undersell, you may not get the support you need from the organization, and if you oversell you may find yourself (since it's a brand new thing that's going to require the kind of change Emily mentioned) facing a lot of opposition.  In that case, even though you did get where you wanted to get, the organization may not see it that way.

Bob Dizinno

My name is Bob Dizinno.  I work at USAA; I'm a Lead Business Advisor.  I've been doing business rules projects for about ten years now, and currently we're attempting to establish a business modeling methodology.  I think we've understood what that's about and what it means, but now we're putting in place, practically, how to develop that and how to make it happen.

For rule management tools we've been using a number of common repositories.  Just recently we've purchased RuleXpress, and we have ILOG J-Rules for our rules engine.

For my DO, I'd say:  Do your homework.  What I mean by that is this.  The discipline behind this methodology — behind the business rules approach — has been getting much more sophisticated over the last five years or so.  When you have done your homework, you'll be in a better position to determine what type of tool support you should be getting and how you want to practically employ both the tool and the methodology once you've established it.

For a DON'T it's a simple one — it's more words of encouragement:  Don't give up.  It's not going to be perfect the first time and — to reinforce what I just said — it's never going to be perfect because the discipline behind this is going to continue to develop and get better over time.  So, you may think you have it down pat and that you really understand it ("I'm really proud of that rule!").  But you're going to come back a month later and think, "That could really improve."

Kathleen Barrett

My name's Kathleen Barrett.  I'm an Architect with The Hartford.  I've been implementing business rules applications for almost ten years now.  We use the Blaze Advisor as our rules engine.  Unfortunately, from a rules management perspective, we aren't at the same level as some of these other companies, and I see that as a gap for us ... that we really need to get to the point where the business is managing their own rules, separate from implementation.  We're just not there yet.

My DON'T would be to the IT people:  Don't over-complicate your design.  The rules vendors have done a really good job of giving us a rich toolset to work with, with many things you can do.  But a mistake we've made (and that I've seen other people make) is trying to get everything into that implementation.  Then you end up with a very complex application that's difficult to use and to maintain.

The DO would be:  Do start small, define your scope, and pick a group of rules with low risk.  What we did, over nine years ago when we did our first implementation, we picked rules that weren't very critical to the business.  We just wanted to get our hands wet; we needed to get a feel for this new technology.  We ended up throwing away that prototype.  It was successful; we actually released it into production, but then we just threw it away and started over.  The lessons we learned were worth the time we took to do that.

Jerre McQuinn

I'm Jerre McQuinn.  I'm a Business Analyst with Microsoft.  At Microsoft, Business Analyst is part of our IT organization, and so I have to hasten to say that we're on the IT side — we're on the side running Microsoft, not producing the products.  We get to dog-food (or beta-test) all the software before it comes out to you.  So, if you've ever found a bug in a Microsoft product, it might be my fault. <laughter>

Thank you, Kathleen — we are already doing the DO you said and that's to start small.  We're babes in the woods at implementing business rules, but we've made a decision to put business rules into the hands of our business users, starting with our product data rules and our pricing data rules and the rules for creating that data.  So, we're using business rules for master data management.

The DO that we've discovered is to look for the patterns — the low-level patterns — and then as you work with the patterns, take it up a notch and look for the patterns of patterns, and the patterns of patterns of patterns.  We've been able to separate our low-level rules from our patterns, from our policies.

My DON'T is:  We have to carefully pick the business user who's going to be operating these rules and implementing them every day.  It needs the right combination of business understanding and a discipline (almost a programming discipline) in configuration management.  It's about managing those rules and governing those rules and not implementing workarounds.  Mike spent the afternoon with one of the people back home on exactly that topic.

Gladys Lam

Okay, thank you.  I'm going to start with a first question.

What is your advice for getting started:  project fit; ROI; getting approval?

[Gladys]    There are a lot of people here who are starting out new — do you have any advice for what's a good fit for a business rule-type project?  Have you seen any kinds of ROI that can help them in terms of going to get approval for this type of project?  What are the challenges to look out for?

Leslie Blumenfeld

What we've been talking about here for the last few days is the idea of taking the business rules out of the code.  So, obviously, you want to pick something manageable that has business rules.  If you pick a couple of programs just because they are big — but they're easily modifiable — that's probably not a business rules project.  A good idea for a business rules-type system is more like this:  it's something where the entire reason for having it is coming from the business; it actually is automation of a process that people do, or decisions that people make; these decisions are buried in code right now and you have programmers and analysts constantly maintaining and changing them.

I'll repeat what many of us said though:  Make sure that when you pick something you pick part of it.  Don't say, "We're going to take everything we do in this area, and we're going to bring in a business rules engine (or a repository), and we're going to do business rules."  If you're really seasoned and very experienced with business rules, that might work.  More likely, even if you are it probably won't work because of all the cultural changes you're introducing and all the different disciplines that have to get involved.

So, definitely pick something that's high business-touch — visible to the organization — so that you can see if you've had an impact.  But it has to be something that's manageable.

I mentioned that we did a claims automation project.  On the ROI side, that's kind of a strange animal.  I remember that, when we started this project, we went through our steps of looking at what we were going to use and thought a rules engine would be helpful.  We then had to introduce that concept to upper management.  I remember meeting with the Sr. Vice President for the division that this system serves and the first question he asked me was, "So this is going to make the project a lot less expensive, right?"  And I said, "Well, not really."  And he said, "Oh, so this is going to let us get this done way ahead of schedule."  "Well, not really." 

So what's the ROI?  That's an interesting question ... we really couldn't tell you that we've saved x-number of dollars by doing business rules.  What we do know is that we had a staff of very highly-trained, very capable claims adjusters with a very, very complex process that they did every day.  And now what we've enabled them to do is take that very complex process and put it into business rules that they have ownership of.  We now know that across the entire claims department everything is being done in exactly the same way, all the time.  The decisions that are being made are always correct (always correct according to the rules that we've done).  We can audit what we're doing a lot better because now we have a manageable piece of logic that everybody understands. 

From a money perspective the payoff is really ongoing because we are about a week or two away from completing Phase Two.  Phase One was nine months; there were a lot of technical issues with interfacing to do a rules system from an AS400; there were a lot of people education issues.  All there really was in Phase Two was process, rules, testing, and implementation.  So, taking that into Phase Three I could probably go back to that same Vice President and say, "We'd never be here if we didn't do it this way."  And he would definitely agree at that point.

Jerre McQuinn

I'd like to jump in on the ROI question.  It frequently does not come down to a matter of money or time saved or vendors saved.  In our case, it came down to quality.  We were able to raise the quality of our price points to a much higher degree — from 93% to 99%.

It also came down to scalability; we are able to scale from six million price points to fifty million price points.  We're not there yet, but with the volume of products and the ways we offer them, we have a tremendous number of price points.

So, the gains are in quality and scalability — and we were able to block leakage in some of the promotions on top of promotions that were escaping ... things that we just weren't aware of.

Gladys Lam

Great.

Kathleen Barrett

We've seen an increase in speed-to-market with our personal insurance implementation.  We automated our underwriting eligibility rules, and once we were fully rolled out we saw that about forty percent of the underwriting guidelines could be changed by the business, without any IT involvement.  And those are fully business-maintained rules.  So that's significant.

Gladys Lam

That's excellent.  Any more, before I go into the audience for questions? 

Okay.  This is where, if you raise your hand, you get your first choice of the chocolates ...  Here we go.  Would you like cherry, apricot, cranberry, or strawberry?  Cherry — okay!

Is Excel a good tool to use for 'starting small'?

[from the audience]    I have two questions; they're completely separate.       We are in the infancy of business rules — basically, we don't do them.  Our rules are buried in the code.  I hear you say that we should start with a small project and yet I can't really justify doing this kind of thing — getting a big business rules tool and spending all this money — on a small project.  Could I recommend starting with a small project and getting the business rules into an Excel spreadsheet (or something)?  Would managing it that way show the value of business rules?

Jerre McQuinn

First of all, thank you for using Excel. <laughter>  Gladys told me yesterday that Excel is one of the most widely-used rules tools, but maybe not the best.  It certainly is a great way to keep track of the rules, and any way to do it systematically is better than having things in people's heads or on scraps of paper.  So, yes, it's better than those alternatives, but there may be even better alternatives. 

If you don't have the funding to go big time, then go medium time or small time.  At least, start.

Leslie Blumenfeld

I need to add something because part of the question may come from what I said about starting small.  When I said "start small" I didn't necessarily mean to pick a small or insignificant project.  In fact, the project that we did was probably one of the most significant and visible projects of that year.  If you judged it on priority and risk, it was actually high priority and had a certain amount of risk to it.

When I said "start small" what I really meant was:  Take a piece that's manageable.  I talked about our three phases.  We have hundreds of major customers that are serviced by this area, with hundreds of policies for thousands of claims and thousands of policies a year.  We obviously knew that there would be no way we could possibly automate all the business rules.  So, we did some up-front analysis on where the biggest bang for the buck would be ... on the most manageable piece of business that we'd be able to understand.  And that's where we started.

So, "small" turned into "very definable" — something that we knew we could identify the business rules for, in a specific amount of time.

Bob Dizinno

I'll add something and I guess I'll be a little more blunt.  Anything is better than nothing.  I'll go back to what I said about not worrying about being perfect because, at a minimum, at least two things are going to occur.  One is that you'll start to understand, practically, how to start expressing rules.  Until you actually get into it, it's very hard to imagine what that looks like.

Also, if you're doing this as part of a project, IT will love you for it because today (at least in the projects that I've experienced) they're having to interpret, as requirements, rules that are embedded.  And this is not only coming from one or two or three requirements but from things like a note in some column that tells them that under this circumstance what I am actually doing is this when that other thing occurs.  When you didn't do that for them, they were doing it for you (and bless them for doing that), but if it turns out to be not exactly what you want then you get what you get.

Emily Springer

You can also start small with a pilot.  Choose something that doesn't really have too much impact — that's what we did.  We chose a small group of business rules — about a hundred — and worked through them and flowed them all the way through the process so that we could learn from it.  The lessons learned were incredibly valuable.

So, even if you are doing it in Excel, just pilot it ... pilot your consistent syntax, pilot your methodology.  Those things you don't have to pay for.

Gladys Lam

You had a second part?

What is the role of the IT Business Analyst when the users are doing the rules?

[from the audience]    My second question is for Microsoft.  If your users are actually doing those rules, what is your role and what do you then do as the IT Business Analyst?  Actually, to any of the panelists, if your users are defining the actual business rules then what is the role of the IT Business Analyst?

Emily Springer

I can tell you how it works at UNUM.  We have business subject matter experts who have the business knowledge and understanding.  And then we have business analysts who are specifically trained to be great rule analysts.  They do the actual rule writing. 

It's an art; it's not something that just anybody can do.  So, we have the business knowledge on the one hand, and then we have actual rule-writing expertise by the business analysts on the other.

Leslie Blumenfeld

At Fortegra we had much the same thing.  IT was critical to this because we helped them draw the rules out.  We worked with the people who had been doing this — had been trained to read the policies and read the contracts — and knew the rules in their heads.  They knew how to do it and how to interpret it. 

But if you sat them in a room and said, "Okay, tell me what you do" that was hard — they had never gone there before.  So, it was actually a very delicate process to draw that out of them.  That's where the analysts came in.  The business itself actually learned a lot during this process.

The other thing we did as IT was to foster the methodology we use to enable this whole process to take place.

Gladys Lam

Good.  I have a lot of hands and I have to go through this very systematically.  So, I think you came in first.

How do you get the business to accept the 'rules' role and not want to push it back onto IT?

[from the audience]  I'm curious about how you helped the business actually become the actual authors and take on the management of the rules.  The business users know this stuff — they know their rules; they do it day in and day out.  But they don't necessarily have that expertise.  So when Big Brother IT comes knocking on their door saying, "Hey, you guys really should own this because it's your business rules" they look at you and think, "But that's going to go in the system somewhere, so that belongs to you, IT."  And they want to push it back.       I now sit on the business side, and I manage a group of processors.  And I find myself thinking, "Okay, how do I develop somebody, somehow, to get them in that position of saying, 'You — you have all that knowledge, that business knowledge, the policies.  I need you to articulate that ... write it down.'"  I want us to be able to influence and own our rules so that we can have more control, but I'm not seeing how it's happening.

Leslie Blumenfeld

In our case, we became the enabler.  In other words, we drew the rules out of them.  I don't think that we would ever go to them and say, "Tell us all the rules for this."  Our analyst knew how to draw that out, and the business user became, in our case, the subject matter expert for the business.

[audience]

Let me take my question a step further.  I actually now 'own' (from a business perspective) an automated process that I was originally the lead business analyst on.  So, I've literally switched sides.  When I was the business analyst, I worked with the business to draw out their business rules, and the individuals that I worked with were more of the executive levels.  They were not the processors.

Now I'm in the situation where I could still do this because I know it and I understand it.  But I'm trying to build that depth within the business organization.  However, the business side is saying, "We don't have the people — we need to keep doing XYZ; we need to keep doing the business, the business, the business."  And they're forgetting that the business rules are part of the business.  How do we make that happen?  That's what I'm not getting.

Mike Lockhart

On the IT side, our issue was that we really had something on fire.  We have to manage eight million price points and all the rules behind them.  And, literally, the systems were written about a UI or maintaining in Excel with eight million rows going line by line.

Our difference was that we have a package — we have SAP but it could be whatever package you have where you can say, "Okay, I believe it's a rules engine."  Given that, our role became more fishing for capabilities.  The business may have written a requirements document with "rules" in it — "These are my rules."  But the trick for the IT partner is to come in with a head start (with a package of some sort) and engage them by saying, "Okay, now you're describing these 'rules' but you're really describing this capability.  So, I'll give you a capability and you grade me on whether you are able to do it to eighty percent."

That's hard to say to IT people.  If you go in and give them a pretty picture of rules — give them a pretty decision chart — nine out of ten will say, "I'm going to code that chart," as opposed to drawing the generic-ness out of it.  And that is difficult ... trying to find IT people who will communicate that way.  They need to realize that their role is as an advisor helping to make the rules, not writing code that does the rules.  And you, as a business person, should not ever be afraid to say, "You are not allowed to hard-code this!"  Really!  You have to say things like that.

[audience]

We actually had some rules that were so simple that it just looked easy to code.

Mike Lockhart

Right!  You need to go, "No, no, no, that's not what I mean." 

It's really hard because most people are trying to meet a [schedule] date, and so writing code will just seem to do that.  But that's your responsibility ... you shouldn't be shy to say to the IT people (even though it's treading on their territory a little bit), "No, that's not what I'm saying.  Here are the rules.  I want you to give me a capability." 

And once you get that communication going — starting little — then it just blossoms and you will find the five or ten people who want to do that for the company.

Leslie Blumenfeld

You are on the business side now, right?  You need an IT counterpart.

Emily Springer

It's a partnership.  It really is.  You have to establish that, and IT should be enabling you.

Bob Dizinno

Or you could do what we did which was to take advantage of our ignorance.  We were presented with thousands of rules and we were asked, "How many of these rules do you want to have externalized?"  We were thinking, "All of them!"  And the consultant who was working with us also said, "Why not?!  More is better!"  Our IT team actually was the catalyst for us to get to the position we now are maintaining.  They were the one who pushed us to have externalized rules.

How many of you are familiar with the software development cycle?  All of you?  Okay — Requirements, Analysis, Design, Construction, Testing, so forth.  Of those, which is the most problematic?  By far, Requirements, right?  And if you look at the literature there is virtually nothing on requirements.  (There is tons of stuff from Analysis, on.)  So, for our team, we became very, very passionate because all of a sudden this light went on:  "This is a better way of doing things!"  This is a 'rule'; this is a 'process'; this is 'data'.

Gladys Lam

Thank you.  I'm going to move on to the next question.

If you start with only a small pilot, don't you end up with two systems to maintain?

[from the audience]    Emily, you had mentioned that you started out with a pilot.  Did you have any problems with doing a small pilot but then finding that you still have this old system that has some of the same rules in it — because you only pulled some of the rules out — and now you have two systems to maintain?  Everybody knows we have limited resources, so now we're developing a new system plus we're going to have to maintain the new system and the old system.

Emily Springer

Right.  And we still have that problem, quite honestly.  We did the pilot, and we took an entire business area — it was a small business area — and put all of their rules into a rule repository and externalized them.  Great!  But we have all these other business areas and we didn't have the resources — and they didn't have the bandwidth — to do that. 

So, what we had to do was do it iteratively.  What we've done, as an organization, is to require all projects that are moving us forward to put their rules into the repository and have those rules be externalized.  It's not a perfect solution, but it is a solution that allows us to use project resources that are already allocated, instead of pulling resources and just putting them on a business rules project.

If we could have done it the other way we would have, but it just wasn't feasible for us.  We couldn't stop what we were doing to pull out all of our rules.

So, what's happened is that for a given business area they have some rules in the repository (externalized) and they have some that are still documented in Excel spreadsheets (and who knows where else).  But we are moving forward; we're moving in the right direction.  I think it was Bob who said, "It's not perfect."  That's right — it's not going to be perfect.  It's iterative.  Every time we do it, we get better.

Bob Dizinno

I heard that comment related to me so many times growing up that it's easy for me to say. <laughter>

Jerre McQuinn

In our case, I found I was specifying the same rules over and over and over, in different systems.  So I moved upstream and took those rules upstream.

In product data and pricing data, we're pretty much at the headwaters.  We're building our rules now for the systems that have their roadmaps yet to evolve — we'll be ready for them to use those rules. 

That's the approach we're taking.  So, if there's an upstream sweet spot you can find, that would be a great candidate to begin with.

Mike Lockhart

In the work we did we agreed that by moving the sweet spot upstream we're taking what's being done multiple times in many order management systems and pulling it up to product, program, and price master data.  In return we said, "We will do no harm to the downstream."  We do have the extra work of saying, "Okay, we're going to fix this upstream and then we'll move downstream as we can convince systems downstream."  We divided it that way, and we enable all the flexibility, line of business by line of business. 

What we have been able to do is cherry-pick.  We've been able to look down and say, "That's really a rule that belongs up high."  We pick it out and pull it up and say, "If you come with us, you get this for free later."  By dividing it that way we have centralized things that had been in line of business divisions.  Now, more and more, we have a core base data group at our company.

Leslie Blumenfeld

That's similar to some of the things that happened to us.  The rules part of this project focused on claims adjudication only.  There was a lot of other automation (and other modifications) that happened around it, and there were other ancillary systems that it fed and that fed it.  But we focused only on claims for rules, and we still are, in fact, until we get it right. 

Notice that I'm not using the word 'perfect' because you should never use the word 'perfect' with rules.  One of the things rules is going to do for you is make the process a lot smarter ... but in the process of making the process a lot smarter you're going to find out the things you didn't know. 

We were able to test the approach we took and also the toolset we used.  We were able to test our rules independently ... flesh them out and make sure everything was correct before things went into production.  Then, when they went into production, yes, we still had issues but they weren't the glaring issues that we might have had if we'd just coded it somewhere inside program-X on line 6005.  These were issues that the business learned something from.  They were able to say, "Hey, we've never seen that before.  We must really be doing it this way!"  They met again with us, and it turned out that they learned a few things.  We made the rules better.  That's what we continue to do. 

When they start seeing that process take effect that's where you'll get a lot of the championship and a lot of the business support.

Kathleen Barrett

Right.  This happens when they start seeing that they can improve the rules because now they know what the rules are.  They didn't know what the rules were before.

What level of detail were the rules in your initial project?

[from the audience]    I'd just like to back up a bit.  Emily, going back to a comment you made a few minutes ago about the size of the pilot, you said that you were looking at approximately a hundred business rules.  What I'm trying to get straight in my own mind is at what level the rules are.  I attended Ron Ross' speech this morning and he was talking about having the business rules at a very high level — kind of at the beginning of the process.  Then, I just came from a session with Mary Gorman and she was talking about the business rules at a very low level of detail.       Obviously, if you have a few at a very high level, a hundred can cover a broad scope whereas if you have a hundred at a very low level of detail you may have only just gotten one small bit.  Can you give me an indication of what level of rule you are looking at?

Emily Springer

I'll repeat the question to make sure that I heard you.  You want to know what level of detail the rules were for our pilot?  [confirmed]  Okay.

Because we chose a single business area, we had rules at various levels — that's the simple answer.  We had some that were higher level and then we had some really nitty-gritty detailed rules in there. 

We spanned the business area.  That's how we defined our scope.  We defined our scope that way so that we could look across that function.

Jerre McQuinn

We took a similar approach.  We started low and, as we wrote our low-level rules, we found there were rules about the rules.  So, we were able to abstract up a couple of different times so that we could get a high, broad rule that would work ninety percent of the time and then manage the exceptions.  Then the exceptions themselves later might become rules.

Mike Lockhart

We started with something that would fit in an Excel spreadsheet.  We started with the line of business that had the biggest issue, which was our retail division, but it also had the simplest rules (such as Wal-Mart pricing, Costco pricing, small retail pricing).  By starting with something that fit in Excel we could analyze and say, "Okay, we're going to take those 500,000 price points" (which you can fit in an Excel spreadsheet).

We then immediately found the high-level rules.  Absolutely everybody will say, "There are geography rules."  That's a no-brainer.  "There are currency rules."  That's a no-brainer.  And when you took out the high-level rules and then you showed them, "Here's what's left; tell me the story.  What else do you have?"  They then would say things like, "Oh, we have emerging market rules."  We kept peeling the onion that way.  We didn't make everything into a rule, but their 'punishment' for not having a high-level rule was that they then had to ask for an exception that somebody had to approve.

By peeling the onion with the set for one line of business, something that could fit into an Excel spreadsheet, we could come to a conclusion.  Now, they probably already had this in policy documents or contracts, but they just wouldn't say it that way to systems people who were maintaining this master data.

What are the characteristics and qualities of a good business rules analyst?

[from the audience]    I want to take the thought process away from tools and bring the question to a more human level.  Can you give me some feedback on what are the characteristics and qualities — skill set — of a good business rules analyst?  What kind of training do you recommend?

Mike Lockhart

For every person who comes into our group for this, we put a Sudoku puzzle in front of them and say, "Explain it."  That is a key test question.  Can you explain to me, in English, how to do a Sudoku puzzle?

One of three things happens.  The person says, "I don't like puzzles."  They're out the door.  The second one is — it's funny how people think — you explain the scripted "how to do it" and the person just re-iterates that back.  And, finally, some people will explain a Sudoku puzzle by saying, "No, this is how I do it."  They'll take your input and come back with their personal rules on how they do it.  And that is the kind of person we're looking for — someone who can take a generic thing and think lower.

Emily Springer

And that's very, very true.  You look for someone who's very analytical and who is able to take something generic and dive down and keep going.  We have one rules analyst at UNUM, and he was not trained in rules.  But we found him because he's so analytical.  It's more about how their brain works than about any training.  If you can find someone that is able to do that, and do it well, you can train him in the art of rule writing.

To answer your training question, UNUM developed a four-course training set around business rules to bring all of our business analysts to some level of expertise.  That doesn't mean that they're all rules analysts by any means, but it does help them to understand how we're writing rules.  It, at least, starts the documentation, and then our rules analyst can help them along.

Mike Lockhart

You said it — we use that phrase all the time:  "The art of it."  Finding people who can do the "art of it" with those funny questions is key because there's never one right answer.

Jerre McQuinn

We took the training from Business Rules Solutions, and that helped us, particularly with the vocabulary.  I have to put in a plug for vocabulary because without a consistent terminology, or set of terms for a concept, you're lost.

Bob Dizinno

I would add, however, that I wouldn't want to over-emphasize the analytic part.  While it is essential, the synthesis part is as important.  The ability to see the big picture and how things are inter-related ... right-brain activity type of things where you are thinking outside of that one little dimension that you're in at the time that you're actually looking at whatever you're doing.

Leslie Blumenfeld

Yes.  The two most important questions — and this is pretty basic — are:  "What?" and "Why?"  The Why? is very important because the business will tell you what they do and you need to come back with "Well, why do you to this?  What if this happens?"

Those "annoying" questions are the good ones.  Initially, IT led the effort to pull out the rules.  And, at first, the business users were a little skeptical, wanting to know "Why are you asking all these questions?"  But as they saw where this led, they started asking the questions.

Emily Springer

We actually based our training on Business Rule Solutions as well.  I just wanted to make sure I gave credit where it was due.

Where do you find that the rules end up — in the UI, in the database, in the rules engine?

[from the audience]    I have a question more on the technical side.  We're in the middle of a pilot, and our IT people have been telling the business that it's really a 33-33-33-percent split on rules between UI, database, and rule engine.  I'd like to get some feedback on that.

Leslie Blumenfeld

What does that mean?

[audience]

That means that, in general, you wouldn't see all your rules running in the rules engine.  You'd have some rules embedded in your UI and some in a database — more evenly split.

Leslie Blumenfeld

I think that's because what you have to add in front of the word 'rules' is 'business'.  This gets into the whole methodology aspect of doing the analysis and how you break up your solution.  There are things that are business rules and there are some things that, yes, you just want to take care of in the UI.  For example, if the amount is above 25 you want this thing to turn green.  But is that a business rule?  It might be a business rule if the business has to do something based on it — if there's a business effect based on that.  But if it's just "I want it to turn green" that's a functional specification.

[audience]

But these are all business rules.  What we're doing is following the BRS methodology and using the fact model and developing rules.  In our pilot, we looked at over 300 rules.  Only three of them ended up in ILOG and the other 297 were in the UI or database.

Mike Lockhart

I think that's IT back to feeling comfortable.  You need to be able to say, "That's not what I want."

Emily Springer

Yes, that's a problem.

Mike Lockhart

What we do is try to encourage capabilities.  We'll go into a project and say, "Assume that the UI is really stupid."  From our perspective, we have to take that approach a lot because we have SAP, which isn't a natural rules repository (though it is configurable).  As an IT person, I go in and challenge this way:  "I dare you to tell me that I don't need to do anything in the UI — the UI is completely dumb."  I tell them not to worry about anything technical.

In the end, they're going to say, "I want to change that rule."  So, we go in from the get-go saying, "I just want to pick out capabilities to give you and make sure that you've got flexible ways to do your rules."

Jerre McQuinn

I think the way you get there is by stressing the agility.  If you hand it over to IT to code in the UI or to code in the database then you have to go back to IT every time things change.  I think if you make agility your banner that will help you get what you need.

Leslie Blumenfeld

One of the techniques we used was to take the word 'system' out of the vocabulary.  This is easy for the business; it's really hard for IT to do. 

Pretend you don't have a system and — even if you're enhancing an existing system — think as if you don't have a computer:  What are the rules?  What are the requirements?

This way you look at things more from a functional perspective.  Some of this may even require an architect, to say, "What directly goes to the business and what should go in a SQL Stored Procedure?"  You might end up saying, yes, I want this thing to turn green — but the way that you knew that thing should turn green might be forty business rules.

Kathleen Barrett

I think it's a matter of rule governance and deciding, up front, what types of rules are going to be implemented in which solution.  It's appropriate to put certain rules in a database, but you have to be clear.  Maybe you want to say that screen-level validation makes sense to put in the front-end if it can be configurable and easily changed.  And certain applicability rules might belong in a database. 

But make that all clear and have it documented.  Have a process that people can manage and govern so that certain developers don't have free rein to put the rules wherever they feel like putting them.

Mike Lockhart

We've had discussions with some of our implementations of "dumb" front-ends, whether they're on SharePoint or some custom thing, and we have literally had the discussion "Is 'greater than or equal to zero' a rule, or is that not a rule?"  Is it a business rule or not?

The quick reaction to hearing "UI" is to say, "Oh, no, that's just a screen validation!"  But you also might say, "Wait a minute.  In my line of business I'm allowed to ask for a positive price and in your line of business I'm allowed to ask for a negative price."  So, that is a business rule.  I think that making this a UI question just clouds business sense.

Gladys Lam

I have a couple of questions and I probably only have time for two more.

Who has what role in a rule change?

[from the audience]    My question is for Kathleen.  You said that the business is now able to take over forty percent of the decisioning ... the changing of the business rules.  What does that look like from an end user perspective?  Have you changed the role of the adjudicator?  Did you have to put different roles in that business area to support making business rule changes?  I'm trying to understand how that full rule change happens and who exactly is doing what.

Kathleen Barrett

When we started, it was a mix of IT and business, but they were business analysts that were a hybrid of IT and business.  They were trained in the new skill set for rules analysts.  They were moved back into the business, so now they're on the business side.  They're rules analysts.  They have a rule maintenance application that they have access to, and they totally manage their own rules.

[audience]

So, it's not really the business user who's changing the rules....

Kathleen Barrett

It's a business person with specialized skills.

Gladys Lam

So, it's not the operational person.

Kathleen Barrett

You know how they talk about 'purple people'?  It's a purple person.

Once you are operational, how long does it take to effect a rule change?

[from the audience]    Now that you're beyond the pilot stage and you're now maintaining a body of ever-changing rules, how long does it take to go from "I want a new business rule" (or "I want to change that business rule") until the new business rule is actually in place?

Leslie Blumenfeld

I can answer that.

I've been mentioning the words 'methodology' and 'process' along with what we're doing, and at some point you could translate that to 'rule governance'.  What you'll probably do is:  You'll do your pilot (or project) first and then you'll figure out what your governance process is because then you'll understand, within your corporation, what you need to govern.  Now we have a change management process for rules ... for how rules get into the rules application and how they get changed and the testing that a rule needs to go through before it gets promoted to production.

Also, there are some things that are just "Well, we shouldn't have used 'greater than' — we should have used 'greater than or equal to'."  That's pretty straightforward.  We just change that in the process; we change it in the requirements; we change it in the rules.  We test it; we move it out to production, and everything's fine.  That can happen in a day.

Finally, there are cases where we think something is a one-rule change and what we find out is that we have a process not really the way we thought we did.  We discover it's more than just a rule — it's actually a whole set of rules.  It's a larger unit of work that needs to be managed.

This is a change management process.  It is something that we evolved as we did our project.

Gladys Lam

Any more comments?

I have time for maybe one more question.  Is everybody okay for one more question?  We're going to go overtime a little bit.

How do you test your rules for quality before they are implemented?

[from the audience]    Does the panel have any suggestions for how you can test your rules for quality before you get to your rules engine?

Emily Springer

We use some of our governance process to do that — to look for consistency and completeness.  So, to some degree there is a QA process before a rule gets to our rule engine.  And then our rule engine does some of the testing for us as well.

So, in our case, it's a two-part answer.  We look at the rule after it has been written — look for completeness; look for consistency, syntax, etc.  Then it goes to the rule engine and the rest of the testing is done there.  We also have a QA Department governing the rule once it's actually implemented.

Leslie Blumenfeld

I would suggest that you talk to the different vendors and ask that specific question because, just talking about the rule engine itself, that's a very important piece:  to be able to test the rules within that environment.  With the product we chose we're able to do this — author a rule (or set of rules) and then test those rules, with test data, directly within the rules engine.  We can actually fire off all the rules ... see what fired and see what results we got.

Then we took things one step further — we wanted to put something in context for the users to make things easy, so we built a small user interface over that rule application.  What that means is that we're able to test our rules before they ever make it into the actual calling application. 

For the most part, we know that those rules are correct in context.  And if something 'bad' happens on the front-end it's probably not the rules.

Mike Lockhart

In our case, this is essentially a pricing and a filtering engine.  SAP is the master of a lot of the data, and since you're in SAP you can send the data through and simulate whatever you want because the package is the rules engine and the place where you're trying to manage the data as well.

Wrap-up

[Gladys]    That will have to be it; I just heard my cue.  Now you can see why this is my favorite part of the program because these were really great answers.  Isn't the panel excellent! <applause>       They are just wonderful so I did bring them some gifts.  This is smoked salmon from BC Canada.  Thank you so much.  That was lots of knowledge shared — lots of practical experiences.  Thank you very much for participating.  Enjoy the rest of the conference.  There's one more day to go!  Thank you.

# # #