Panelists

Brian Stucky, Enterprise Rule Steward, Freddie Mac

Mark Davis, MIS Development Manager, First American Field Services

Ingrid Hentsch, Initiative Manager, The Economical
Insurance Group

Lynn Almoro, Data and Decision Integrity Manager, American Express

Bonnie Moonchild, Project Manager, Washington State Dept. of Social &
Health Services

Alan Demmin, Demmin Software Consulting

Moderator

Gladys S.W. Lam, Principal, Business Rule Solutions, LLC

.

Introductions

Gladys S.W. Lam   We've come to my favorite part of the conference.  This is the Practitioners' Panel.  I've moderated this Panel now for the last six years.  Since there have only been seven conferences, I've missed just the first one.  Each year it is more fun ~ every year I hear more experiences.  We have better discussions; we get more and more out of these panels.  So I don't want to delay any more.  Let's get started. We've put together a fantastic set of panel members.  Their experiences span from home-grown rule engines to commercial rule engines ... from inference-type rule projects to system-type rule projects.  We have tremendous amounts of expertise and experience in all areas, and I urge you to take advantage of all of that. I like to run the panel by asking the panel members to please introduce themselves, and then give us a little background on the company, the projects that they've worked on, and some of the technologies in their organizations.  And then I'd like each of them to give us two of their DOs and DON'Ts for business rules projects. After that, I will kick off with a couple of my questions -- ones that I have collected over the years, questions that people seem to ask often.  Feel free ... don't be shy.  If you have questions, jump in.  Because this is really your session -- your part of the program.  This is your opportunity to ask all those questions that you have been collecting through the Conference or through your experiences where you've said, "Hey, look.  I've always been stuck here.  Let's see what other people's experiences are."  So feel free to jump in. I'm going to start with Brian.  Give us your name, your background, and your two DOs and DON'Ts.

Brian Stucky

My name is Brian Stucky.  I'm with Freddie Mac, now serving with the title of the 'Enterprise Rules Steward', and I work with the group that governs all the rule-based efforts we have across the corporation.  I came from a field where I worked in AI -- back when this was 'expert systems' -- and I have migrated to working with rules.  I have the privilege of having been associated with Freddie Mac for a couple of years.  In the mid-90s, I initially worked on some rule-based activities they had then and I came back to work with them again about three years ago.

We are currently a customer of ILOG, and we're using JRules.  We are also using their optimization product, CPLEX.  We currently have two rule-based applications in production, a third that I would call 'pre-production', another one that is about half-way through construction, a fifth one that is just now getting kicked off, and a lot of others that are very interested in using 'rules'.  I'm sure that, as we come to the question segment, I can talk more about these particular efforts and what we're doing. 

As far as the DOs and DON'Ts, there are certainly a lot of things we could offer, probably more in the DON'T category than in the DO....  For the number-one DO, I would say that if your enterprise is really serious about using rules and you're likely to have rules that are over more than one application, then DO coordinate the efforts.  At the very least, get everyone on the same platform.  Past that, look for things as simple as naming conventions for rules, and standards for capturing rules and implementing them.  Get everybody on the same page, up front.  Later on, if you want to have any chance of coordinating and centralizing, that will be a really key factor for you.

Secondly, DO communicate and educate.  Brief everybody you can, as often as you can.  Do it for the executives; do it for the tech teams; do it for the business side.  Get a champion working with you and then be an evangelist.  When you think you're done, assume you're halfway there and educate them some more.  This is a black-box technology to a lot of people.  Some people have higher expectations than they should have initially, so let them know realistically what they are in for and what rules can do.

As far as DON'Ts -- DON'T assume that, once you've found all the material for your rules, codifying that in terms of something implementable is going to be trivial.  It's not.  Leave time for it.  You will undoubtedly find gaps, inconsistencies, and redundancies in almost any kind of policy or material you're trying to get rules from.  If it has to be implemented, odds are it wasn't written for that.  As a caveat, if the material you're working with was written by lawyers, then magnify this by about a hundred.  <laughter>

And finally, if you are getting to the point where you want to put out a management interface for rules, DON'T assume it's 'one size fits all'.  Almost every vendor tool we have represented at this conference is flexible enough to give you great expressive power in the kinds of interfaces you build.  Find out what the business users need and use that.  There's a great deal of creativity that can go into this task.  Use it; it will be all the better for it. 

Gladys

Thank you, Brian.  Mark.

Mark Davis

Hi, I'm Mark Davis, from First American Field Services.  We manage default loans on mortgages.  When properties become vacant, mortgage companies want to keep track of that property; they want someone to go out and fix things that are broken and to make sure that the property is kept up until they can get out there and do something with it. 

I've been with First American for two years and that's about the extent of my rules involvement.  I came from a telco background, working on provisioning systems and portal development -- but the rules work has been very exciting. 

I came to First American because they had a problem.  They had a legacy application that was causing them to lose money, hand over fist.  So I came to look at the business process, to try to determine what to do.  It was clear that this business is all about rules (it is regulated by the government, by FHA, by VA).  The more we looked at it, we saw that it was a good candidate for rules.  So we chose to re-engineer our entire company, from the ground up, around a new rules-based system. 

We are a Blaze Advisor customer; we have been since we started.  We have used their product to implement the rules.  We have a .NET framework, with ASP and VB.NET doing the workflow and the rest -- in other words, once you have the rules what do you do with them?  It's the .NET and ASP that does that 'something with' the answers we get out of the rules engine.  We also use 'Innovator' -- their business process modeler product -- to push the business rule management out to our business folks and, ultimately, out to our customers.

I share a lot of Brian's experiences in my DOs and DON'Ts.  I'll offer some of the things we've learned in our two year implementation -- things I would do differently if I could go back and do it again.  First, I would say, DON'T start writing the business rules before you understand the business process and before you have finished the analysis.  We dove right down into the 'how' and didn't concentrate on the 'what' -- what was the problem we were trying to solve?  And we overwhelmed our business users.

I think another thing you really have to focus on (and Brian touched on this also) is:  DO pay attention to the need to communicate with your business users.  It takes a really long time and a lot of dedicated effort from your business folks and your analysts and your IT people to really frame up what it is you are using the rules for and what the rules need to be.  We that found to be a frustrating process for the business users.  Month after month, you are going back and talking to those folks, asking them what it is they want.  And at some point they will look at you across the table and say, "All I've seen are spreadsheets for six months; when am I going to see an application?!?"  So you really need to communicate with them that there is something coming out of this and it's going to be great and it's going to be better.  Really make them part of the process.

For my second DO:  DO ensure that you have sponsorship.  I say this, backed up by some of the comments I've heard in several of the sessions -- how do you manage executives who all have conflicting priorities?  Everybody wants to drive the project, and everybody wants their piece built first.  I think if you can focus in on those one or two key stakeholders who can carry your message (or help you carry that evangelistic message) out to the other stakeholders, you will be a lot more successful. 

Our other DON'T is something that we really needed to focus on (as I think everybody does as well).  DON'T pretend that this won't cause a culture change in your organization.  It did for us; it did for a lot of folks I've heard about.  Whether or not there will be reduced headcount because you now have all this automation and there aren't all these people touching orders (or whatever it is you do), if you can go out and really make the business a part of what you are trying to do -- really work with them so that they don't feel threatened -- you will make it easier on yourself.  And then you'll have a lot less pushback when it does come to implementation and people get new jobs or new roles, when the company looks at head-count.  So don't forget about the culture change.

Gladys

Thank you, Mark.  Ingrid.

Ingrid Hentsch

Hi, I'm Ingrid Hentsch.  I'm from The Economical Insurance Group in Waterloo, Ontario.  We're a P&C insurance group across Canada, with branch offices in all of our Provinces.  We don't have any business here in the U.S., though. 

Of the two panelists we've heard from so far, I'm probably the newest to rules projects.  I've been managing a rules project for the past year and a half and, guess what, we are doing underwriting rules.  (What else?)  This is a very popular first application of rules for an insurance company. 

It has been an interesting experience so far.  We've had our ups and downs, but I think it's been the right decision for us and I do want to continue.  I am becoming the 'evangelist' for my company so far, and I think most of my team IT members are now, which is really good.

A couple of our DOs and DON'Ts.  DO definitely align rules project with some strategic objectives of your organization.  If you can find the reasons why the rules approach to the project is the best solution, you will get your executive sponsors -- you will get those people who will be championing your project with the rest of the organization.

Secondly, it seemed very simple and straightforward but we fell into this trap.  DO definitely learn your rules methodology before you jump in with both feet.  We thought we knew enough to get started -- definitely not the case.  We could have used more help.  We found that out very, very early in the game.  It's really important that your early project members and your project sponsors and the people are going to be paying the bills for the project all understand what you are trying to accomplish.  You will be at it for a little while before they see any value out of it.  And they will be asking you why it's taking so long to get to that first release out.  It's important for them to know 'why' -- why you are doing this.

I would also say that you need to make sure, as you are adding team members to your project, that they are also aware of what this methodology is and what you are trying to accomplish.  We are trying very hard to make sure that all our other team members share an understanding of what it is we are trying to do.  We found that we were caught in the trap of assuming that they knew what we were doing, but they really didn't because they had just joined the team.

A couple of DON'Ts.  I will repeat what Brian has said:  DON'T underestimate the amount of time and effort it will take to harvest rules out of your current systems (or wherever they may be right now).  In our particular project this is the single largest contributing factor to the amount of time it has taken us to get where we are today

Secondly, DON'T start building those rules even though anybody who is a developer loves to just jump in and code.  DON'T start building those rules until you have a really solid understanding of what the business problem is  that you are trying to solve ... or what pain point are you trying to eliminate.  And make sure that you understand what the business model is that you need to have in place in order to support what it is you are going to be building with rules.  Finally, understand what those data relationships are that you're going to have to go forward with in your rule solution.

Gladys

Thank you, Ingrid.  Lynn.

Lynn Almoro

I'm Lynn Almoro from American Express.  I manage a technical group of folks, both in the U.S. and in India.  We basically manage the underwriting capability for our cards, to offer you that 'junk mail' about Gold and Platinum upgrades, Delta Sky Miles, and so forth.  You can thank me for that <laughter> ... but not right away. 

We also manage rules -- data coming in from our credit bureau partners as well.  My team manages rules for our collections.  So we deal with various kinds of rules.  But our core function is the underwriting.  That capability has been around since its inception in 1999, and we've been managing it since that point.  

At this point, we are executing on the mainframe platform, using COBOL.  But our underwriting system is at the cusp of being re-platformed to a distributed system.  We are looking at doing a proof-of-concept with Sapiens for what is going to be on the mainframe for our collections strategy.  Our underwriting is going to be on the distributed platform, and we're looking at doing a proof-of-concept for that with Corticon and Blaze Advisor.

A couple of DOs.  DO definitely engage your business partners.  There is way to get these guys to sing the same song.  It may not seem like that when you first talk to them and get their requirements from them.  But if you can templatize things -- feed them some food for thought -- a lot of times you will find that there's a certain song that everybody sings and you can get them to sing in the same key, in tune, as well.

A second point is:  DO phase your implementation.  Don't try to solve everybody's problems all at once.  This reflects some of the concerns that the rest of the panel has brought out -- management is waiting for you to implement something, and they're waiting and waiting, and it's taking a while.  Part of the pitfall may be because you are trying to solve a big problem.  But if you phase your implementation to where you may be solving a medium problem -- if you give them just the right amount of results (maybe in a shorter period of time), they will buy into this approach like that and you'll get your money.  You won't even know where money is coming from any more.  You're going to push priorities out to the business because they will be seeing how much easier things become for them.  So it's very important that you phase your implementation, rather than trying to solve the world.

A couple of DON'Ts:  DON'T rush into making a rules engine decision.  It's very important that you don't fall into the trap of "Okay, this one sounds great.  I'm going to go with that."  That is the more costly route, rather than taking the time to do your due-diligence.  I think these vendors are great in sharing the information that they have -- letting you know how they can help your industry.  But you need to be real picky.  There's something out there that's a good fit for you, but you need to do the work to locate and pick that.  For example, we're not tied down to one rules engine.  If this is our capability; that engine works.  Given this other capability, then that engine works for that.  So this is something to keep in mind.

The second DON'T is:  DON'T think that you can easily automate the harvesting and mining of rules from your existing code.  Don't under-estimate the human factor in that.  Because if you think you can buy the software and it's going to harvest everything and you're just going to plug that into whatever you have -- home-grown or rules engine product -- your delivery is going to be compromised.  Remember that the quality is more important than how quickly you get there.  Because that becomes your credibility about business rules in the long term.  So be very watchful about that.

Gladys

Thank you, Lynn.  Bonnie.

Bonnie Moonchild

My name is Bonnie Moonchild, and I currently work for the State of Washington, for the Department of Social and Health Services.  The system that I work for pays $100 million a month to providers of services to the citizens of Washington State.  We do it with a million-plus lines of really, really old COBOL code.  And, unlike Lynn, no matter what I do, nobody throws money at me.  <laughter>

We started out doing succession planning and realized that we were really at risk because we didn't know the rules of our business and the people who did know the rules were walking out the door.  They were retiring; they were doing all sorts of other things.  And as all of you who have legacy systems probably know, finding new COBOL programmers is not an easy thing.  So we knew that we needed to position ourselves for change.

We're working with Corticon, and right now we're gathering in all of our rules like crazy.  Next Spring, I'm starting a project where I will not only gather those rules but use those rules.

My first DO is about courtesy.  If you're going to ask people to give you a lot of their information, DO look at the things that are already in place before you start.  Don't go and ask someone a question that you could have picked up from the documentation that's sitting around.  Look at your process models, your use cases, your data dictionaries -- also, the user manuals, desk manuals, forms, records, test cases.  If worst comes to worst, you could even look at code.  But try to be prepared when you to talk to users, and they will be much more open-minded.

Everyone else has talked about getting people up to speed on what you're doing.  So I will add, do that for your technical staff, too.  Don't assume that they're just going to jump in on this idea of rules and say, "Oh, yeah.  That's great!"  You need to spend time getting them on your side.  Then you'll have some good people to work with you.

My other DO is:  DO manage your rules project as a project.  Have a timeline; show your progress; be able to say, "I'm this far through it."  That way, when people come to you and ask, "How come I haven't seen anything yet?" you can answer, "This is our plan; here's where we are; here's where we're going; this is when you will see things.  Here is the next thing that you will see." 

My DON'Ts are:  DON'T skip any steps.  You need to define those terms.  You really do.  And you need to use those terms in facts.  Then you can make your rules.  If you skip steps you're just going to have to go back to the start, and you'll annoy everyone around you.

Also, DON'T ignore your 'data' people.  If I can, I always do a project with a data analyst with me.  Maybe my vocabulary, when it ends up in the database, will have some differences.  But (to use this example because there are a lot of insurance people here) think about what it would be like for your business people if the rules call it a 'policy' and your database calls it 'customer service'.  It makes for a disconnect in your business that you really don't need.  So if you can work with a 'data' person it's really helpful.

Gladys

Thank you, Bonnie.  Alan.

Alan Demmin

Hello.  I'm the late write-in candidate, so please vote for me.  <laughter>

My name is Alan Demmin.  I'm an independent consultant.  I'm currently on contract with the California DMV.  We've been pursuing a major re-engineering effort for the last few years, trying to modernize the systems.  I actually started at the DMV in 1997.  Can anyone guess what I was doing?  Y2K.  We all survived that so we are able to continue on.

About that time I went back to school for my Master's degree in Artificial Intelligence and Expert Systems.  So I am more or less coming from the 'science' side of things -- studying the RETE algorithm, which is the basis for all of the rules engines today. 

At the same time I happened to sit next to a very sparkling individual, Claudina Nevis (who you may know from the very first rules conference), and we got started talking about business rules and a project that she was looking into.  It was a mission-critical piece of the system, and it was very rule intensive.  But more importantly, the bottom line was that they needed to deliver change faster. 

I have a good example of that.  As you may know, in California we have a new governor.  And one of the first things that Governor Schwarzenegger did (actually, within the first few hours) was to repeal the vehicle license fee ("car tax") in California.  In California we love our cars.  And so this is an area of the system -- vehicle registration fees -- where I can see this 'deliver change faster' capability being used as a political advantage in the future, even as it has been in the past. 

So, the DMV went through some super-human efforts to deliver, and I wish our work could take credit for delivering that promise, I really do.  However, we weren't in production yet.  But we were working on that part of the system and, for us, it was only one rule change.  Unfortunately, there were a lot of other legacy areas of the system that had to be changed, and they went through quite an effort to deliver something that -- if you think about it conceptually -- shouldn't be that difficult:  stopping a fee from being assigned (or changing the percentage). 

The fee computation project has been implemented in stages.  We have the first couple of stages in production, and the third one is really close.  (In fact, I'm lucky to be here.)  We're using Blaze Advisor for our rules engine technology.

Some of the DOs that I would have:  Probably the most important is the fact that you're here.  When we started our project we had no knowledge of any business rules movement (or anything).  In 2001, about a year into the project, Claudina and I came to the Business Rules Forum, and when we got back we completely changed everything.  We realized that we were doing a lot of things that were wrong, and we attached ourselves to some methodologies and studied them, and that really helped put us back on the right track. 

Engaging the business experts, and even management, was also important.  It was a high-visibility project -- very political at times -- and we needed to obtain those stakeholders as well.  I'm re-iterating a lot of things that have been said here, which makes me feel good.  ("Wow!  We're in the same boat.")  It was important to get a sponsor that could understand what we were doing and had the vision as well.

I also want to mention that I went to Cheryl White's excellent presentation about culture.  One of the things I'm going to take back from this conference is understanding the importance of culture shock.  Yes, you're doing the project.  And, yes, you're bringing about new technologies ... maybe new infrastructure, perhaps a new methodology.  But you also want to introduce that change gradually -- if not 'fly under the radar' -- so that you don't overwhelm -- because you can get a lot of resistance, in a lot of different areas. 

I will qualify that, however.  I have had both experiences.  I have had the experience of being pushed away, but we've also had a lot of people in the organization who really embraced us and wanted to be a part of the project.  I was actually a little surprised at that.  So be aware that there are a lot of people who do want to do things better.

Because of that -- a lot of people wanting to get involved (basically wanting to define the whole business) -- it was very difficult for us to manage scope.  So this would be a key thing to be aware of as well.  You may pick a part of your business that is a logical domain to do this in, and yet what you may think is small will grow rapidly.  Over time, we attracted all these people who wanted to get involved, and suddenly we weren't defining a fee system; we were re-engineering the entire terms and database for the whole organization.  While we wanted to take this on, and we appreciated the enthusiasm, we did have to scope it and say, "Okay, we'll do that part later.  Right now we do have to deliver fee computation."

Some of the DON'Ts are:  DON'T rip out IF-THEN statements from legacy code thinking that they are rules.  A lot of you here are probably saying, "Duh-h-h-h!"  But I'll tell you that this was one of the approaches that was taken in the beginning, and we were somewhat on course to develop a rules system that was going to be more difficult to maintain than the legacy system itself.  That's the definition of a major failure.  We recognized that, and that was the point at which we started investigating rules methodologies.  You can get ideas of business rules from legacy code; you absolutely can do that.  I'm not saying you can't.  Just realize that rules are not the IF-THEN statements that some programmer put in.

Finally, this is more of a reiteration of what others have said:  DON'T buy your technology before you have at least some exposure to the methodology.  If you think that a rules engine is going to solve all your problems, look at the methodology, look at the business side first.  Then you will be better equipped to evaluate the different rules engines and products that are out there.

Gladys

Thank you, Alan. 

.

How do you measure 'benefit' of a business rules project?

Gladys:  At this point I would like to ask a question that seems to be the most urgent and pressing question people have.  It comes up over and over again; it came up in my Birds-of-a-Feather session.  I get it all the time from my clients.  And I'm sure a lot of you would like some answers to this question.  So I will start out with this question and, after that, if anybody has questions just raise your hand and I will try to be as fair as possible to get to everyone's question. The question I want to ask is about ROI (Return On Investment).  How did you measure 'benefit'?  Have any of you done any ROI-type analyses on the projects that you have done?

Lynn Almoro

One of the challenges for us in starting out the underwriting system was that, at that time, there were pockets of people doing their own underwriting, in their desktops, and the biggest challenge was convincing them that if we pulled this all together into the big system, using rules, it would be okay.  That was back in 1997 when the project started.

So we couldn't quantify, as a dollar value, what we would save -- what would be the ROI.  The biggest factor for us at that time was time to market.  I know that to some industries this may apply (and to others, not).  But at the end of the day, whether you measure it as 'time to market', or as the number of days it takes for a change to be implemented, that was the biggest selling point for us.  Typically, it would take (say) sixty days from the time we wanted to change a FICO score threshold, and get that tested and implemented.  And now, my team is doing that in three days, by changing the rules. 

So the fact that the additional 57 days we're giving the rest of the business to carry on, means that you guys get your mail about your Delta upgrades a lot quicker.  Because we're in a race with Capital One (or with some other business), right?!  Or for balance transfer, or to call someone to get them to buy my insurance, versus another company's.  Time is critical! 

So getting the change done in the quickest time is what counts.  And you can do that with 'rules'.  That, I think, is the biggest buy, rather than saying, "This is the amount of money that I can make for you."  That should be embedded in the process already -- the fact that you're getting more people into your insurance company (or you're getting more cars out there), that in itself is the 'return on investment'.  How you get that done quickly and accurately is the key to why you want to do it in 'rules'. 

Sometimes we get too caught up in the whole 'ROI thing'.  Yes, you do need to keep in mind that there is an initial cost to getting rules implemented -- there's always that.  But in the long-term the benefit of cutting down implementation time is far greater than that initial investment which, after all, applies for any architecture change, whether its rules engine or people or BPM tools or whatever.  Things need to get implemented in that new architecture.  In that way the change process itself is a good investment.

Bonnie Moonchild

Being non-profit we have to measure things differently.  On the tax project that I'm starting up, when I looked at what it would take to do it with all-IT staff, I would have needed 30 new COBOL programmers, which I didn't even think I could find.  But I measured that against what I am going to do:  I'm going to do the project with 5 CPAs and one C# programmer. 

For me, this is something I can show to my management and say, "Thirty people?  Six people?  Here's the money we save."  We save money by saving people time.

Brian Stucky

Both of these two are relevant for us.  I'll add a third.  The very fact that we have taken policy that, previously, was inconsistently applied (or applied differently in different areas) and now have it one way, means that for our primary business of buying loans we are buy all the loans we should and we're not buying the ones we shouldn't.  That in itself is a great return for us.  Our customers are happier, and our auditors are happier.  That's critical.

We know the data quality that we have coming in now is better than it was with the other systems.  I can't give you a dollar amount yet, but when we combine that along with time-to-market and the resource shift, it will be pretty large.

Gladys

Anyone else?  Okay, I'm going to start with the audience.  Who has a question?

.

Have you measured productivity of your development staff?

[from the audience]:  Has anyone on the panel measured productivity of your development staff prior embarking on this approach?  For example, function points for developers -- anything like that?  And, if you did, that would be an excellent number to give.

Ingrid Hentsch

The problem we were trying to solve in our group -- the one key benefit of our project -- was to enable us to improve the rate of rule change in our underwriting system.  Now it can take anywhere from four to six months.  That's because we are dealing with a typical COBOL legacy system.  I'm sure we have a function point number for what that effort is, but I couldn't tell you what it is. 

We haven't achieved that yet because we aren't in production.  But our goal has been to try to reduce that 4-to-6 month effort to, at the most, three or four weeks.  And most of that time would be in testing.  From the analysis of what it is that we're going to be putting in, and then the testing afterward, we really do anticipate that we will be saving a lot of developer time with the structure we're putting in -- say, from four-to-six months down to three-to-four weeks.  We haven't proved it yet, however. 

Alan Demmin

I don't think I have an exact measurement to answer your question, but I think I do have a relevant example.  There is an individual on our team who is a Senior Analyst.  He's a business analyst -- works on the business side -- and would never consider going in and doing a COBOL change or an Assembly Language change.  Those are obviously reserved for the programmer.  But we did have a point in the project where we had sent everybody off to training on the tools we were using, and we found that there were some things that any one of the team could actually do.  At one point, we had a problem with the rules and this person was able to go in, step through rules, look at the business process, identify where the problem was.  He made the change, tested it, and got it back into our test system by himself.  I left one night, came back in the next day, and on my chair was "Problem fixed!"  That was some immediate feedback we've gotten. 

Now maybe you're not ready to move immediately into the mode where your business personnel are directly updating rules -- we're probably not there yet either -- but I think the promise is there that there are some things that can be done a lot faster than they used to be.

Gladys

Here's another question.

.

How did you find the right business rules methodology?

[from the audience]:  Several of you have mentioned the importance of establishing and defining your methodology before going in to actually create the business rules.  Obviously there is not a standard yet for how to write business rules, or how to organize and structure and manage rules.  There are probably a lot of places to go.  How did you go about finding the right methodology?  Do you have some suggestions?

Lynn Almoro

Last year was the year that I first learned that there are these numbers of people who actually do business rules.  I'd always thought that American Express was crazy because we've been doing business rules for so long and we had to build our own home-grown engine.  We didn't know that there were all of these vendors out there.

When I came to the Business Rules Forum last year, I became aware that there was such a thing as a methodology for doing rules.  After that, one of the things that we've done in our underwriting capability is to assess where we are, as a capability -- are we up to par with the rest of the card businesses, are we far behind, or are we ahead?  This helps identifies the scope of how much work we have to do.

What we did was bring in Business Rule Solutions; Ron and Gladys came in and evaluated our full end-to-end process, not just rules but workflow process and business process, and how we implement things.  What are the tools that we have?

Once they'd done that, the next step was to educate senior management.  Ron and Gladys came in and -- traveled to Phoenix, traveled to New York -- educated our management team, letting them know, "This is what 'business rules' is all about.  This is where you are now, and this is what you need to do next."  At that point, we set out the scope of what we needed to do. 

We have to do it in stages.  Don't try to move the whole thing you're doing (in our case it was underwriting) and push it into a new system all at once.  You have to 'pilot'; even if it is just one little thing, for example, balance transfer or Delta upgrades.  Just move that up into production  and then you can say, "Hey, look at that!  The light at the end of the tunnel is actually there.  This wasn't just some concept."  After that, you can get bigger and bigger as you ramp up more things into this new rules execution environment that you are creating.

There are different methodologies out there.  It's just a matter of what you are comfortable with.  Take what applies to you.  You don't have to buy (or use) the whole package.  Different industries have different ways of doing things.  But, regardless of differences, there are basics that you want to make sure you keep in mind. 

Mark Davis

We did about the same kind of thing.  We didn't have any idea about what rules methodology was when we started.  We knew we wanted to implement the rules engine, and we made a mistake that some on the panel have already talked about -- we ran out and bought a rules engine right away.  It turns out that we made a decision that we're happy with, but its not always going to work out that way.

We had Fair Isaac's Blaze people come in, with their Quick Start program.  We went through their methodology and that was an interesting process.  At the same time, we ran right out, bought the rules engine, and got some developers who wanted to learn how to code in the Blaze Advisor.  When the Fair Isaac Quick Start people came in, they started talking to us about 'defining terms' and working with flows, and model this and model that.  And every day, all we wanted to do was have them show us how to code in this thing.  To their benefit, they never would; they always pushed back, because I think they knew that -- as the other vendors and panelists have said -- it's methodology, methodology, methodology.  If you get it right up front then the technology is the easy part.

.

Can you really have business users modifying the rules directly?

[from the audience]:  We see touted in a lot of vendor rule literature that, specifically, you can have business users essentially modifying your rules directly.  At this conference, I have heard opinions ranging from 'It's the greatest thing since sliced bread!' to "You must be mad!"  Where do you all stand on that?

Brian Stucky

That is really a critical point for Freddie Mac moving to using rules in a great many of our applications.  In our industry, our marketplace changes so rapidly that we need the technology to make the changes and we need to throw it into the hands of the business users.  The state of the technology now has brought us a lot closer to being able to do that comfortably than we ever has been, but it is still a learning process and not one yet that we have fully undertaken. 

To me it's really a matter of two things.  Number one, taking advantage of the expressive power from the vendors to create interfaces that are absolutely intuitive -- as easy to understand as possible.  Business analysts are not dumb; they know their business.  They can figure some of these things out.  Do I want them off writing IF-THEN statements to their hearts' content?  No.  And I don't intend to have them do that. 

And that relates to my second point.  This is a whole new breed of business analyst that we have to work with.  It's a 'rule writer', a 'rule analyst' -- someone who has a technical ability, along with their business savvy.  There's going to be a great deal of training and hand-holding and finding the right kind of people who are amenable to that task.  Right now for us it's pretty clear the ones who are getting a grasp of it and some who are probably just not going to get it. 

But we'll move slowly, and right now it's very much hand-in-hand with the technical side.  And it will continue to be that way until we get to our comfort level.

Bonnie Moonchild

I work with social workers -- not people who most of you think of when you hear 'business people' -- so when we did training, we trained half IT people and half social workers.  The people who took to it were ... half IT people and half social workers.  The social workers who took to it were really amazed at themselves.  One of them kept saying, "I keep getting the right answer.  I don't know why!  I keep getting the right answer!" 

So, I think you can't necessarily predict who it is that will do best with it.  Although, if you have someone who has never had a logical thought in their mind, <laughter> they may not be your best candidate.

Alan Demmin

I would add to the example I just gave:  I think the real power in that case was that we had followed a methodology -- to define our process, define our terminology -- so that we could speak the same language as far as how we communicated with the business and then how the business was actually implemented. 

There is still a translation there.  A lot of the rules engines do offer a very intuitive interface, but it's probably not at the level where your eventual decision makers on business rules probably won't necessarily want to use the tool -- but our analysts?  Absolutely!  Even business analysts or technical analysts absolutely had a fairly easy time using the tools that we had.

But of more importance for me was that we had now defined an area of the business that hadn't been defined before.  (Actually, that's kind of scary to realize.)  In any case, it was now a formally-defined process that we could all communicate about, and I would think that, eventually, we do want to bridge that gap and narrow that translation as much as we possibly can. 

I think that, on the business side, we probably want to become more structured as to how we define the business.  And then on the technology side, we want to be able to get to the point where it's even more of an English-like syntax.  And, someday (hopefully) maybe we can meet in the middle.

.

When the project ends will you transition the maintenance back to the business people?

[from the audience]:  It seems like all of your projects have done a good job of defining the business through process, terms, and rules.  I assume all your projects end at some point.  Is there a transitionary pattern that you have set forward to transition that intellectual capital back to the business to own and maintain?  And if not, is there a risk of that intellectual property being owned and maintained within IT?

Lynn Almoro

That is an excellent question.  I think that question really applies more at the second stage of business rules implementation.  Once you've have it out there and it's productionalized, one thing I would recommend everyone keep on their radar is the workflow.  When I say 'workflow' it means:  when your business has a change to the rules, how is that handled?  So, if you have sixty business partners and they all want their stuff done, who goes first?  How you handle that is part of your workflow. 

One of the things that we've done in our business is push the ownership into the business to prioritize the requests.  We've automated their submission of changes to the rules.  We've templatized on which rules they would want to change.  We've given them a playground and a sandbox where they can go to experiment with the existing rules.  But we don't allow them to make the changes automatically.  We give them a sandbox to play with and tell them, "Let us know what your rule changes are, and we'll let you know what we can do for you."  We give them a service level agreement:  if it's low complexity we'll get done in three days; if it's medium, it's seven days; if it's high (super high?) two to three (or four) weeks. 

Ensure that you have the workflow established, like this:  we give you something to validate, you go use the user interface, these are the files you need to validate, and then you need to sign-off within 48 hours.  Once you give me your sign-off it moves into production. 

That workflow needs to be established so that no one points fingers at another person saying, "Well, you didn't get that done on time!" or "You didn't send it in to me correctly!"  or "You didn't have your requirements clear!"  And it avoids everybody trying to vie for which request should be done first.  All that should be pushed to the business because the business knows which requests (which changes) are most important to them.

Brian Stucky

For that very reason, for that particular problem, we developed the concept of a 'steward group' at Freddie Mac.  And we have 'stewards' for rules and for some other technology areas. 

That group is the one really responsible for retaining and passing on the knowledge that we've gained, even after the projects have ended.  We think this is really important because this has been a constant problem in the past -- and probably for everyone else here as well.

.

Is there anything special you can tell us about the kind of pilot project?

[from the audience]:  My question is about pilot projects.  We always look for something of fairly well-defined and limited scope -- something that can produce visible results.  Is there anything unique about a business rules project when you select a pilot?

Bonnie Moonchild

'Keep It Simple' -- just like any other IT project pilot.  You want to have some richness to your project; you want to keep it very contained, but you do want to show value.

Ingrid Hentsch

Was your question what kind of a project you would choose for a pilot project for rules?

[audience]

Is there anything different about a business rules pilot project, as compared to the run-of-the-mill project?  We know about visibility (and so on); is there anything else to look for in a business rules pilot?

Ingrid Hentsch

I would say that it's not that much different from running any other kind of pilot project, whenever your technology is what you're trying to prove.  Keep in mind that it's going to be new technology to your organization.  Other than the rules component being new, there may be a new technology component that you're going to need to work through as well. 

But I think that the biggest difference is that you will need a lot more business people involved in your project from the very beginning to make it a success.  That's been our biggest difference.

Lynn Almoro

I can add one bit of cautionary 'fine print' to the question of picking a pilot.  I would say to not pick one that is low complexity for a technology.  It should be something that is of medium importance to the business and then of medium to low-high complexity on the technology side.  

I say that because there has to be a balance.  If it's easy on the technology side, you have to ask, "Why is it so easy?"  When it's easy, there's a reason.  You'll want to evaluate the value -- the incremental value that it's adding to your business.  At the end of the day you'll need the business buy-in, more so than the technical buy in, because while the technical folks are the ones who are going to get the job going, the business is what will keep it going.

Mark Davis

If I could add one more thing.  One of the traps with picking an easy or low complexity pilot, is that when you harvest the rules, you're going to be fooled into thinking that you are better at it than you are.  <laughter>  If you have millions lines of RPG code, or COBOL, and you have a business that is turning over people -- the knowledge workers are going -- you could be in trouble.  We found ourselves scoping the second phase based on the success of a relatively easy pilot.  And we really underestimated the amount of time it would take to harvest those more complex rules.  So I say, watch out for that.

Alan Demmin

I'd like add one more thing, too.  Often with a pilot project you can align what you want to do for the business with the technical scope so it's easy to identify, "Here are the modules I'm going to re-write."  But (especially on the projects I've worked on), we had clear definition of the pilot part of the project, but the business rules were spread across different modules.  So it was a little bit more of a challenge to say, "Okay, we want to do these business rules, but how do I turn them off in the four to five to eight modules that they're in?" 

This is near and dear to my heart because scoping was definitely a challenge, especially at the beginning -- both from the technical side (how are we going to limit what we are going to do?) and on the business side (how do we limit the current focus while looking to the future?).

.

If you have your rules in both 'operational' and 'executable' forms how do you keep them in sync?

[from the audience]:  My question is about the operational versus executable forms of rules.  The rules that we have, are they primarily executable?  Do you store the operational form somewhere?  And if you do, how do you manage to keep them in sync?

Brian Stucky

We do have both.  I think you've really hit on one of the key issues that we are facing right now.  They are rarely in sync, sadly, because there is nothing that ties us between our systems for documenting the requirements for what the rules are and where they are actually implemented. 

So we follow what I consider some of the source rule repository steps that KPI would mention, with anchor points and use cases pointing to a set of rules that are in nothing more than an Excel spreadsheet, in many cases.  But there is nothing that directly ties somebody making a change in that source to what's implemented in the system.  That's a huge problem point right now. 

I don't have any good answers right now.  I have heard some things in the last couple of days that may get us down the road a little bit better.  But right now, this remains an issue for us.

Alan Demmin

I would reiterate that we have the same issue.  We have our business rules in Microsoft Word, so we don't run them.  Actually, this is something that is on my wish list.  A lot of the vendors that I've seen seem to want to offer the business side of it -- and maybe even claim that they do -- but the work that you do up front, of finding your terminology and organizing your processes and decisions (and especially terminology) -- I don't see the tools out there that I can engage the business users in and have them use the tool, as well as the analysts to arrive at the solutions.  But hopefully soon.

Lynn Almoro

I feel a little bit more fortunate.  It has been seven years after it all started for us, getting into the underwriting rules.  We have templatized the rules capture without using any GUI interface.  As part of our workflow we require our business partners to use the same template where we've documented the business rules.  (Now mind you, this is as archaic as a Word document.)

In there, we actually have the business rules; we reference the rule number where that business rule is being met.  At that point, if they want to make a change they will make the change in the Word document, and submit that as their change.  Because they've played in their playground and they've identified that that's the change they want, our rule writers and rule architects will then reference that. 

Once the change has been made we save it back into our Lotus Notes database where, at that point, on the next iteration if they want to change it again they can reference back to the same Lotus Notes database, which has a fresh copy of the operational set of rules. 

We are in the process, in of some of the proofs of concept that we're going to have, of looking into automating that.  We're creating interim solutions to have a back-end database with a web front end so that they can enter it there. 

But certainly there are interim ways.  Don't think that, "I'm going to wait until I have a rules engine, and I have a BPM, and I have this, and I have that."  You don't have to wait!  You can create something in the interim.  Just make it accessible to the business.  I think that's opening up the channels of communication.

Ingrid Hentsch

I just wanted to add ... we had a similar kind of experience.  We're using JRules on the project, and we had the naive notion that we'd be able to take all of our harvested rules and they would miraculously change into something structured to look like an IF-THEN statement that we could put right back into the JRules repository.  It came as a complete surprise to us to realize that we needed to build something in between. 

For us, it came down to, not so much getting a handle on the rules we're harvesting as it was to getting something that works as a communication tool between the business side of the team and the technical side of the team.  What we ended up doing -- don't laugh -- was build a Lotus Notes database.  What we then did was structure it so that we had templates that the business analysts were taught to use, and these were in the formats that we wanted the rules eventually to look like.  We have the users using this Lotus Notes database.   

We also use this database to track all of the decision trails that show how they actually ended up coming up with some requirement.  This is especially important when you are getting into inconsistencies of rules, gaps, anomalies, conflicts ... you will find you usually end up getting three or four people involved in making a decision on what the rule is actually going to be.  And if you don't keep track of that, it's going to come back to you in testing, when somebody's going to say, "Oh, I never agreed with that."  We started using this as an electronic paper trail so that we can say, "Yes, you did agree to that about three months ago." 

What we also did was set it up so that we capture all the dimensions that we want to use to keep track of the rules as we are defining them.  Not just the status a rule is in (such as 'reviewed by the business', 'signed off by the business') we are also using all the dimensions that we care about so that we can go back and do all our own simple reports and queries against it, for dimensions like "What region is it in?"  "What effective date applies to it?"  "What line of business does it apply to?"  It made it a lot easier for the business analysts to keep track of that giant base of rules that we've rapidly been building.

The last thing we did was build in the hook that lets us track the rule in Lotus Notes into the implementation.  Note that it's not a technical hook -- it's completely manual.  But it does allow us to track the rule-id that we established in the Lotus Notes database to the rule that it eventually applies to in the JRules repository. 

.

How volatile are your rules? Does anyone have rules that change daily?

[from the audience]:  I have a question about the volatility of rules.  Does anyone on the panel have rules that change daily?  If so, how is this situation handled?

Lynn Almoro

I have one that changes weekly.

[audience]

Okay.  Then that gives me an idea of the situation.  So even though it was said that rules can be changed frequently, no one is yet dealing with rapid rule change.

Brian Stucky

No, we have rules that change daily -- a great number of them.

Lynn Almoro

That's right.  It's not the same rule that changes but we do have changes going in like mad.

[audience]

What volume do you have in that?  What is the number of separate changes, all going in in one day?

Brian Stucky

You know, that really varies.  In large part, what will happen is that some of our changes are turning a rule off or changing it slightly per conditions.  But everything that we have that surrounds our pricing -- much as you would see interest rates fluctuating -- that impacts us daily.  Right now, with the selling system that we have, I would guess that maybe we have anywhere upwards of 50 a day.

[audience]

So how's your debugging problem?

Brian Stucky

For those changes right now that is largely (no, completely) handled by the technical team.  And we are only restricted by how often we are able do patches up to our system.  Technically, we could update the rules much faster, but we are pushing that up very slowly. 

So, it's technically not an issue; it is more of a process issue for us, ensuring that we get everything done to validate that a given change is going to be safely made without any other impacts.  So if we have a pressing change, that's typically not an issue.

[audience]

After you've changed the rules, you run against a test model?

Brian Stucky

Yes.

.

What are you doing for your business rule 'metadata'? Have you considered a business rule repository?

[from the audience]:  I would like to hear a discussion of the panelists' understanding of business rule metadata.  Is it something you are concerned about?  Is it something that you have decided to tackle?  And if you've thought about it, have you thought about a business rule repository, or are you just using what's at hand?  In what direction might you wish to go in the future?

Lynn Almoro

I'm not sure, when you say 'business rule metadata', what you mean.  I like to think it's 'meta rules' -- something about the rule.  We use the template, really, to keep that intelligence about the rule.  One of the things that Ron kept drilling in my head was that the biggest issue we have with our team is the turn-over.  These people are the smartest group of risk management folks around -- PhDs and Masters up the whazoo -- but when they leave to take another job, the intelligence goes with them and we're stuck to have to explain to the new person how the rules work. 

So what we've done is essentially just that.  We templatize the way the structure of rules is, to tell the new people what the rule is doing.  And then they can just access that from the Lotus Notes database (as a repository). 

We are evolving this on the data end -- to have something more like a web-based back end with a front end to access the information.  That it is very important.  It was a tough lesson for us to learn; we didn't get started on this until four or five years into the project.  And I would not recommend that at all.  I would definitely say if you can get this started at the beginning of the project, do -- please, do.

Alan Demmin

Just so you don't feel like, "Oh, oh.  I can't go any further!"  I would add that our project is seriously lacking in this area.  We are doing the best we can to manage traceability by including policy and legislative numbers, attaching these numbers onto the rules in our Word documents right now.  But it's a lot of manual work and there's a lot we can't do because of it.  Tracking changes is going to get harder as we go. 

But we've recognized that we couldn't have that hold us up, and we didn't have the time to go and evaluate, searching the world to see if there were tools out there to help us.  We're at that point now, but I wish could have done it ahead of time. 

So don't let this necessarily stop you -- I really appreciated the comments about 'don't let this hold you up'.  Yes, you're going to wish that you had a tool; you're going to wish that life could be easier, but I think it still is worth it to pursue the project and just get as best a job done as you can.

Gladys

Terry said we can go until 4:30 so I see one last question that we can get in.

.

How do you handle the effectivity of terms, definitions, and business rules?

[from the audience]:  How do you handle the effectivity of terms, definitions, and business rules?  What I mean specifically is:  at the California ISO we are governed by a tariff.  We are rewriting our tariff; our terms are changing.  Those terms were used in contracts, which means there are different rules associated with them.  How do you handle 'effectivity'?

Lynn Almoro

We have various reporting capabilities that we've built and enhanced this last year.  We can report on the data, for example, whatever deviations FICO scores might reflect.  Say the numbers are always coming in with values between whatever the 'magic numbers' are.  Then, if we have the case where that data is always coming in zero, something is going to fire and say, "Listen you're about to mess up about 95% of your rules because your FICO scores are all coming in as zeros today.  You have a feeder problem." 

On top of that there's also rule integrity were we count how many times each rule fires.  And there's an average -- it's like a graph that's always certain because the rule stays the same.  Here we are looking at how the rule has been functioning.  So if that rule is firing a hundred times, plus or minus, on a daily basis, and today that rule has fired five hundred times, somebody gets notified by an email that says, "Listen!  This rule is firing 500 times today.  I don't know what the problem is but somebody had better go over there and look at it!" 

Admittedly, we didn't think about the data and rule integrity when we first built the system.  While we were building we didn't obsess about data and rule integrity, "We know we're perfect.  We're writing these rules just fine."  But at the end of the day it turned out to be so critical -- so important because of dependencies we couldn't control.

Gladys

Part of the question is about versioning the terminology -- the terms used in rules -- something is implemented now and a change to the terminology comes in.

Alan Demmin

There are things lacking on the terminology side because we don't really have a terminology database yet.  Hopefully, that will be forthcoming.

On the rules side, managing our documents is somewhat done within the rules.  We do try to handle effective dates that way.  And in the rules engine itself there are a few different ways to handle it.  They have a feature of being able to limit what rules are effective for a given time period ( and date period, if you need that level). 

Finally, we do have our repository itself stored in CVS and, with this, we are able to do versioning of a rule set as of a certain time.  We have found this helpful to us.

---

Gladys

Well, we are out of time.

We have had excellent questions.  I am most impressed because if you have been following these panel discussions through the years you will know, every year it gets better,  You can see that in both the questions and the answers -- how far along in terms of the projects, the maturity of business rule products, and the initiatives that are going on in this industry.  I'm very impressed.

Thank you everybody.  Thank you especially to the panelists for coming up with answers to the questions so quickly and to the point.  Thank you.

# # #