Panelists

Patti Rottenbiller    IT Architect, Nationwide Insurance

Michael Koscielny    Director of Regional Underwriting, AAA Michigan

Mark Myers    Enterprise Architect, Northern California Power Agency    

Jack Holloway    Director of Operation Process Design, University of Phoenix    

Garth Gehlback    STW Fixed Income Management    

Chuck Gulker    Senior Staff Product Underwriter, Nationwide Insurance

Moderator

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

.

Introductions

Gladys S.W. Lam Welcome to the Practitioners' Panel.  This is absolutely my favorite part at the Conference.  And you know why -- we get a lot of interaction, and we get very good feedback on the Practitioners' Panel.  I would like to begin by welcoming my panelists.  They are absolutely great.  I have worked with, talked to, know of all of the members in the panel, and they have vast experience in business rules.  So, this is your opportunity to get free consulting because you can ask your questions. This is how I run the panel every year.  First, I like to start off asking each panelist to introduce him/herself.  Give us some background about your company, the project you are on, maybe the tools you work with.  And also give us a couple of DOs and DON'Ts on what you've done, drawing on your experiences.  Then I'm going to kick-start the discussion with a couple of questions.  These are my own burning questions, and I'm going to ask my questions just to kick-start the conversation.  But feel free to jump in.  Any time you have questions -- you want to follow-up on some of the answers from the panelists or you have new questions -- just raise your hand and I will come over to you.  I tell Ron and Terry that this is my job as 'Oprah' and I should get paid as Oprah!  <laughter>  But that never happens. Without delay, I'd like to start with Patti.

Patti Rottenbiller

Good afternoon.  I am Patti Rottenbiller; I work for Nationwide Insurance, as an IT Architect.  I have worked with business rules for about nine years, in various roles.  I have done some rule mining, done some rule development, done some rule testing.  Currently I am working on the architecture side of the business -- fitting the rules engine application into enterprise architecture, where it fits.  I'm currently assigned to a project that is a Personal Lines Underwriting system, where we are integrating our rules engine with many different sales and policy servicing applications.

My DO for today ... I struggled with this one because I have a lot!  The one that I want to mention first and foremost is:  DO put yourself into the role of being an evangelist for business rules.  I think, especially when you are starting out with rules, there aren't a lot of people in your organizations who may understand the power behind business rules and the business rules approach.  Once you've worked with it and have seen how valuable it is, you will understand, and you need to be the one stepping out and being a champion for it.

My DON'T is something that Ron alluded to this morning in his keynote address:  DON'T try to do everything at once.  It is a huge undertaking, especially when you are just beginning.  So, try to piecemeal it.  Business rules lends itself very much to incremental approaches and incremental implementations.  So, take it a little bit at a time, and you'll learn and go on from there.

Michael Koscielny

Good afternoon, everyone.  My name is Mike Koscielny.  I'm with AAA Michigan, also known as the Auto Club Group.  I'm a Director of Regional Underwriting, and my involvement in business rules is that I've been the evangelist, if you will, of business rule technology with AAA. 

Our organization is a little bit different in that we are a member-based organization -- we are part of a Group, called 'Auto Club Group', that does both AAA membership business and insurance business in seven states in the upper Midwest, with Michigan being the primary state we do business in today.  We are a 1.5 billion dollar insurer.  This technology has been an important part of our organization and our expansion abilities over the last four years. 

To give you a little bit of my experience:  I have been in the business for twenty-seven years.  I haven't been doing rules that long because, while business rules have existed, their automation hasn't been around that long.  I was involved in some of the 'smart systems' (business intelligence) early on.  Most recently, prior to coming to AAA, I was involved in some decision and scoring models with another carrier.  So my experience is broad in that respect.

I'm a business guy; I'm not a technical person.  According to my son, who is twenty-four -- he tells me every day (because my VCR is flashing '12'), "Dad, You have to be smarter than the equipment you're trying to operate!"  Fortunately, there are technical people out there who can deal with those kinds of things.

Probably the most important DO:  Plan.  Understand who you are, what your business is about, and think about your rules in a more strategic fashion than you probably ever have before, before you venture into a rules management process.

For the DON'Ts:  DON'T sell short the testing necessary to be sure that what you've created and what you've evolved to over time is what you want.  Rules management is an evolutionary process.

Mark Myers

Good afternoon.  My name is Mark Myers.  I am the Enterprise Architect at Northern California Power Agency.  We are a small government agency, a member agency of about sixteen cities in Northern California, and we deliver wholesale power to them.

I have been working in rules for twenty years but only six years in starting to understand them.  So, it's been a very evolutionary process for me also.  I have worked at a couple of different companies, implementing rules.  The current project that we're working on is a validation and verification project in a settlement system, implementing with ILOG and a .NET application.  I work as an Enterprise Architect, 50% on the business side and 50% on the IT side.  I feel that's very important -- that when we look at our business we look at it in a holistic way and are able to traverse both sides.

As far as the DOs and DON'T, I have two things that we should DO.  The first thing is something I've said for the past several years at this conference:  We need to develop a methodology when we start this work.  While rules engines are very important, developing a methodology to define your architectures is much more important.  Defining your architecture is the second key DO because we are dealing with assets that have a life-span -- a half life greater than a couple of days.  We are investing in things that have enduring principles.

So, defining a methodology and defining your architecture are the two things I think you should spend some time on.

Jack Holloway

Good afternoon.  I'm Jack Holloway from University of Phoenix.  I'm the Director of Operation Process Design, a different kind of department that we've set up at University of Phoenix as we try to get into business rules.  I've been involved about a year and a half, or so -- didn't really begin in earnest until last Fall at this same conference in Las Vegas.

What tools are we using?  You are seeing most of them right here ... and with my staff over there as well.  We have our own self-designed (desperation-designed!) databases, which we are using as we go out looking for software to house and to control and manage our rules.  So, we are still looking for that software out there.

Some DOs and DON'Ts.  One primary DO that I've been trying to do for the last year is:  Create a niche within our university -- a recognized, unique department that's not IT and it's not business.  In defining our role in between those two groups, I'm finding it's very important that we do things persistently:  this is what we do for the Office of Process Design for a business rule, and this is what the IT does, and this is what the business does.  We are defining what that new role is.  I call this 'new' because, for our organization, it has been either 'A' or 'B' -- IT or business.  We have created a new department in between.

Some DON'Ts:  DON'T move forward in your project without first starting with those business rules -- defining what those rules are.  As someone mentioned earlier today, IT is likely to say, "Let's start developing and then go ask what they want."  Unfortunately, that is more prevalent than we would want.  So, define and write down those rules before you venture on -- before even making your plan.  Get your rules first. 

Garth Gehlback

Hello.  My name is Garth Gehlback.  I'm with STW Fixed Income Management.  Our clients include institutions and wealthy investors.  At the heart of our business is business rules.  We've been somewhat early on the scale of adopters of business rules technology so we've had some bad experiences and some good experiences.  I'm happy to say that, overall, it's been a critical part of our business, enabling us to differentiate ourselves and to be able to grow very quickly, managing the change that's inherent into our business.

Going over some of the DOs and DON'Ts -- some of them you have heard already.  Clear sponsorship is a big DO.  Ensure that you've got really solid, clear sponsorship, otherwise your project will be doomed to fail.

Another one that might be expressed somewhat differently from what you've heard here is:  DO plan with the big picture, but go ahead and implement in smaller phases.  The inverse of that is:  Don't take the 'big bang' approach.  It's very difficult to be successful when you are trying to do everything all at once.

Another item on the to-do list is:  DO your homework to match the technology with the projects that you have in mind.  Not all technologies are a good fit for the projects that you might have.

And, lastly, is:  Plan for change.  That's a key DO.

Things on the DON'T do list...  DON'T limit yourself to the vision of what's already been implemented or applied with the technology.  Go through that self-discovery process within your own organization, and do a little bit of creative thinking to get a vision for how business rules might be of benefit to you -- maybe not initially, but longer term.  That might help guide your efforts to implement rules over the years.

And, lastly on the DON'T list:  DON'T neglect the people side of the equation.  If you are simply paying attention to the technology, you're going to be hard-pressed to be successful and to have really good adoption of the technology.

Chuck Gulker

Good afternoon.  My name is Chuck Gulker and, like Patti, I work for Nationwide Insurance Enterprise, based in Columbus, Ohio.  I started with the company about twenty-five years ago, right out of college as a desk underwriter, back when they still had paper applications and photos and inspection reports and motor vehicle reports -- and everything tangibly came across your desk as paper. 

After that, I moved into the staff underwriting function (in the 'ivory tower', so to speak) and was charged with trying to work with our systems partners to write business rules in an English-based system that people as non-programmers (like myself) could understand.  I'm actually the guy who writes the business rules -- sits at his desk and says, "We need all the blue cars to be reviewed by Underwriting."  I've worked primarily with Auto but have done Property as well.  The big thing that I bring forward to our company is:  This is the third generation of rules that we, as a company, are in the process of implementing.  Each time gets a little bit more sophisticated -- a little bit better rules management, for example. 

As far as the DOs and DON'Ts...  Here is the one DO I feel is really important:  It is very easy for one person to try to write a rule that they think is a rule, and just hand it off to a developer and let them just code away and implement.  But what we've found, as a company, is:  Before you do any coding at all, you need to sit down and do what you call a 'rule review', which we do. 

These are gut-out sessions.  What we do is bring forward all impacted parties to the rule, whether it is a developer, a tester, somebody from the sales operation, somebody from the line operations, and maybe someone a staff underwriting point-of-view (like me).  And we all look at that rule -- we dissect the rule and we say, "Oh, you've got that wrong."  Or another person says, "Oh, we got that wrong."  Then we go back and rewrite the rule.  Then we code it.

It slows the process down a little bit, but it reduces production errors, misunderstanding, and you get buy-in all at the same time.  So that's a real DO.  It's "DO slow down and get everybody involved before you start to code."

Another DO is:  It's a team environment.  DO try to work with your Systems partners as best you can.  Get to know them on a personal level; travel with them; be involved in meetings with them.  Really try to foster a team environment because we are all in it together.

As far as the DON'Ts go...  DON'T let other areas of your company misunderstand what rules do or don't do.  The big thing in our company is -- people say, "We've got thousands of rules!  Do you mean we're going to have thousands of outputs going to our service centers to have to handle?"  Well, no.  Only a small subset of those rules would actually impact the handling.  A lot of the rules are internal, behind the scenes.  So, don't let other areas misunderstand what rules do.  You have to keep re-educating them, if at all possible. 

---

Gladys S.W. Lam

Thank you.  Wow!  That was good.  I feel like I have learned so much already -- we can end now, right?  <laughter>

Well, I've got a list of questions.  I'm going to start off with one question, and if you want to jump in, please go ahead.

We've got a good mix of IT and business representatives here, and for the first time we have representatives from business and IT from the same company.  I purposely put them at opposite ends of the table.  Let's see if they come up with the same answers to the questions, or whether they have to toss papers to each other.  <laughter>

.

The business perspective on a 'business rules' project

Gladys:   I'm going to start with a question to the business side.  When you start a rules project what is the objective the business side has?  For example, is it for knowledge retention, or is it for communicating to IT?  Another part is:  What do you see as the biggest challenge?  What do you see as the biggest benefit?  So, really, this is a three-part question.

Chuck Gulker

I'll be glad to start.  From a business point of view, when I look at that question from my area we basically consider two benefits.  We want to document our business as best we can.  We do use rules management -- we have an in-house rules management program that we custom coded, and we are in the process of enhancing it with an external company helping us.  Our rules management helps us define our business.  So that is priority number one -- because you can't code it unless you understand what you want to accomplish.

Number two is:  We go through the rules process to ease Systems being able to program it and put it into production faster.  The better we define it, the faster we can get speed to market.  So, from our standpoint it's selfishness on two fronts:  what do we do as a company, and how do we get it in faster?

As far as the biggest challenge that we face:  A lot of time we find that speed-to-market isn't really a rules issue, per se.  We can get the rule programmed fairly quickly sometimes.  But where we are limited is that we have other areas that need to interact, whether it's the front-end needing to change, or adding a new data element, or somebody on the back-end needing to make some change.  In these cases, it's frustrating to see we've got the rule coded, ready to go, but we're limited by our end-to-end process slowing us down.  That's probably the biggest frustration -- how do we get all the areas talking to one another, faster?

Jack Holloway

I think, from a business side at University of Phoenix, our main focus is identifying the rules to give to the IT Department.  Often they're given a new change in a project or in a system, and there's a date saying "By January 1, get that in place."  Too often there is a scramble:  "What are the rules we need to understand before we go out and start tweaking our systems?"  And, "What are the systems that are being impacted by that?" 

What we're trying to do is, one, document what those rules are, before IT goes and makes those changes.  We need to understand what else is going to be affected.  And also, making sure what's already in there is correct.  Some of the concerns we have are for the data integrity -- the integrity of the data that already exists.  We want to know:  At the same time as they are fixing (or adding in the new stuff), can they fix the incorrect stuff so it's not feeding the new project that has just been put in?  Right now my primary concern is communicating with the IT world so that we clearly define those rules before IT moves forward to make the changes.

Mark Myers

I would add that, from our perspective, we have a lot of people in the baby boomer era who are going to be retiring.  Our industry is looking at something like 40% to 60% of the people in the next five years are going to be exiting.  So from a business perspective, getting all of that knowledge documented is really key.  In our EA (Enterprise Architecture) effort, capturing those rules is the number one priority.

The second thing we look at is:  When we look at a legacy system and say, "Um...  that legacy system is going to be around for a required amount of time," then we'll extract the rules out of the code and move to implement the rules in a way that is much more manageable, going forward.

It's really a two-fold purpose:  One, to retain knowledge, and the second purpose is to have better automation and changeability in the future.

Michael Koscielny

As an insurance carrier, one of our most important criteria is consistency in the decisioning and accuracy in the same process.  As was mentioned earlier today, we are a heavily regulated industry, and compliance is a very important part of that.  As regulators come and look at our processes they are looking to see that the consumer is treated equally across all the product lines that we do.  Maintaining that process of consistency and accuracy, within business rules, is really critical.

The other part is then to mine those decisions that have been made throughout all those processes -- whether it's quoting or issuing automobile or homeowner applications -- to validate the rules that we have in place.  That's a critical part of this whole evolution of rules, from our perspective.  Once we've established those rules, we need to ensure that the decisions we're making make sense, in the business world.  And, if not, how do we alter those things, moving forward.

Garth Gehlback

At STW, the business benefits and the business drivers are essential.  They are so fundamental it happens both on the cost side as well as on the revenue side.  We simply couldn't keep up with making trades, making the allocation of those trades to our clients in a timely enough fashion, if we didn't implement rules.  And likewise, on the other side, being so responsive enables us to generate more revenue, to seek out and to support new clients.

Gladys S.W. Lam

Thank you.  I see some hands waving -- I will pass the mic on.

.

Business rules benefits, irrespective of the automation aspect

[from the audience]:  My question is very high level and may not even be appropriate, but since it's the realm I deal in I'm going to ask it.  It goes to the point that has been made that there are automatable and non-automatable business rules.  But in my time at this conference, almost everybody has referenced using business rules in the context of developing some sort of automated information system, in some form or another.  Where I'm at -- what we're really looking at using business rules for -- is to try to get our extremely large organization to begin to do pieces of business the same way across the organization, something that we don't do at all today.  From there we'd like to expand on ... hopefully, same day we'll all do business the same way, irrespective of which automated system is being used to do some piece (or maybe even without automation).  So, I'm wondering if anyone has any DOs, DON'Ts, or thoughts about business rules, irrespective of the IT (automation) aspect.

Mark Myers

I'll try to touch on that.  One of the things that Ron pointed to this morning in his keynote was getting to the Point Of Knowledge, which I think is exactly what you are wanting to address.  Here's one of the things that we do:  When rules are executed, certain things can be automated so those things can happen.  But there are also things that can't be automated -- things that have to be brought back to the user.  We just present those rules to the user:  these are the allowable actions you, as a user, can take.  

Now if those things change, we just change those rules and that way we get the right knowledge in front of the business user.  That gives us some consistency across the business.  Of course, this could be implemented a lot of different ways.  For example, if the system didn't implement it you might simply have desktop procedures.  We do find that systems can help in delivering that knowledge quickly and you can update it quickly also.

Chuck Gulker

I'll tell you, the biggest kind of rules that we would like to automate but can't is what we call 'account level rules' -- rules at a client level.  We have our Homeowner products and our Auto products written separately and stored separately, in a lot of different ways.  We have a lot of rules we would like to write where we bridge somebody's account level, but we have a hard time doing that from a data integrity perspective -- in the way our data is structured -- so we end up having to refer the case.  Then a screener or underwriter has to manually go into the cross reference and look at things.  

We have a lot of rules that we're in the process of documenting; we put in our rules management tool, but sometimes we have to shelf things for future technology or future database merges, things like that.  In other words, we do use our rule management system, and rules in general, to mine and record rules that we can't necessarily mechanize now but we might in the future.  By recording them with a tool, at least you begin to know where your gaps are.  

Michael Koscielny

I think an important part to consider in this, too, is that when those decisions are made to have someone else -- some human intervention into a process -- those can then be as consistent as the rules themselves are.  And these are auditable type activities within any organization.  

It's a common practice in the insurance business that certain things can't be automated, as Chuck described.  But that referral piece can be made consistent.  And then, really, it narrows the focus of those supervisors who have to work with the people to be sure they are doing things right, as opposed to -- without rules -- 100% manual intervention, which is a much more difficult process.

.

Approaches to rules capture

[from the audience]:  This is a question for (probably) Jack.  I want to know if you have been participating in any rules standards?  I see that there are many rules engine vendors but there's no common standard.  Do you have any views on that?

Jack Holloway

Any views on a particular aspect?  ... on rules management?

<audience>

Rules standards -- standards for capturing rules.

Jack Holloway

I almost hate to characterize it, but it does seem like rules capturing and rules mining and getting with the users comes down to an 'art form'.  It's knowing how to work with the users, knowing where the information is stashed.  At the University, we have manuals and pamphlets; we have websites; we have different items at individuals' desks.  Plus, we're trying to get information out of people just about to retire -- it's lodged in their heads as well.  What it comes down to is the art-form of knowing how to ask the questions to pull that knowledge out. 

Then there is the challenge of identifying the difference between assumptions of the business people and just what they repeat because they have heard it from someone else, who repeated it from someone else, ten years ago.  It's whittling things down to:  "What is the need for and the goal of that rule?"

In fact, one of the practices I've taken is to have the assumption that "No rule is correct."  In other words, assume that whatever I am told is not correct, and then I try to validate each thing.  I know this sounds very weighty, but at the moment you can tell ... "that's real," or "that's not real."  There's a book, Blink, that talks about this -- that feeling of "that's just not quite right!" 

So part of it is art-form and another part is saying, "I just don't believe that rule" -- of course, saying it tactfully!  It's looking for validation of what you are being told.

Chuck Gulker

I would agree with that 100-percent.  We are mining rules with a company we bought a few years ago that has a different channel of putting business on the books than I'm used to at Nationwide.  And, depending on who you interview, you might get an underwriting opinion that, "This must be must be mechanized."  But then you ask somebody else, or you get a staff opinion, and hear something else. 

So, in an important way, a rule does need to be validated.  It gets very frustrating because, a lot of times, rules are so hard-and-fast; you find that it's programmed that way.  And when you have human judgment as an underwriter a lot of stuff is kind of grey.  So you really need to make sure you do validate things ahead of time.  That's a very good point.

.

Preparing the data for 'business rules'

[from the audience]:  We all have heard that rules operate on data, and we all know, also, that virtually all of our applications have varying degrees of 'garbage' in them.  So my question to the panel is:  Do you folks do some sort of data profiling before deploying rules?  How does this affect your rule development and deployment? Mark Myers I want to try to try to repeat the question to be sure I understood it.  You want to know about if we do any kind of data validation prior to writing the rules? <audience> Well, in a way.  But what I was thinking of is:  The rules are only as good as the data they operate on.  That's a fundamental assumption that I'm making.  And yet at the same time, I'm asserting, as a matter of fact, that virtually every application in all of our organizations has different degrees of 'rubbish' (bad data) in it.  So, my question is:  When you deploy rules, when you develop rules, do you do any preparatory work?  How does it affect your work?  What have you learned?  What are the tricks?  (etc.)

Mark Myers

I think the answer is, yes, there is a lot of preparatory work.  Let me just briefly address the data.  

Prior to writing any rules we go through a fairly rigorous project of trying to define the facts and all the terms that we're going to use in the rule.  We define those first.  Once we've done that, then we've written our rules based on just those terms.  Can you picture a 'closed system'?  In other words, if I write a rule and I haven't defined a term, well, that term can't go in the rule.  So, it's a 'closed system'.  

Now that I've done that, I know the 'data' that I need.  When I develop my business domain model it's going to be populated to run those rules, and I'm getting that data from my business side using the business names that we've developed previously in the design session.  There's a pretty rigorous process to do that in the business rule approach.

One other step that we do on the data is:  This varies by application, but -- when we bring the data in -- a lot of times we have a whole set of rules that simply validates the data.  For example, if I know I'm bringing in a piece of data that's supposed to be '100' I might have some rules that have calculated an estimate of that data.  And if the data that I'm receiving from another company isn't close, then I have exception rules.  Those exception rules are the rules that actually fire (as Ron talked about this morning).  There's a very strenuous process to develop that aspect of the data.

Jack Holloway

Earlier it was stated that rules are only as good as the data in the system.  But that's not quite true.  The rules are good.  It's whether they are followed or not -- whether they are implemented or not.  If we take Ron's premise that 'structural rules' cannot be broken, then it means that we have assumed that the rule is good.

What we look at is:  What should the rules be, regardless of how bad the data might be, in the system.  We have to take it for granted that there are some areas of bad data out there.  And with that assumption, that knowledge, here are the rules that must be followed.  Now, comparing those rules -- getting back to IT -- we can say, "Here's our checklist of rules.  Show me in the system where this is being executed so that it follows this rule."  From that point we can find the deviations from that, so we can then say, "Oh, this status is not firing off at the right time," for example.  And then we can trace back to what caused that to be.

Patti Rottenbiller

I think Mark absolutely right in that you do need to make sure that the data is there and that you understand what it means.  So when you are talking about developing a rules engine or doing a rules-based project, you absolutely need to make sure that that step is part of the process and built into your timelines.  

It can be a very daunting task, especially if you are talking about many legacy systems that you are working with.  So, as Mark alluded to, you do need a process to define those terms and to define that data so that everybody comes to a common understanding of what it means.  Otherwise, your rules are not going to function like you expect them to.

Chuck Gulker

We're in the process of doing that rule definition -- defining the terms.  As we speak now, I see one of our programming people from Nationwide here laughing because it's very frustrating!  Just trying to define a line of business product hierarchy at a company like ours is not all that simple.  What channels of business do we sell?  What do we want to call it?  

And, unfortunately (or fortunately), we're in the process of redefining a lot of things -- our rules management tool, how we fire our rules,....  So now is a very good opportunity for us to sit back -- we have a lot of years of experience doing this -- and say, "OK, how can we make it better?  Let's all agree and let's publish it."  We keep our focus on the goal:  "It's going to make it better down the road because we won't be generating so many defects and misunderstandings."

.

Rules governance and mitigating the impact of change

[from the audience]:  My question is one pertaining to governance, and this may be more specific to the insurance sector.  What tools or techniques do you use to manage the large-scale ripple effects and costs that result from day-to-day contractual changes or policy changes or changes to rules made by standards bodies?

Patti Rottenbiller

I can speak to that.  One of the things that we've done, as Chuck mentioned earlier, is develop a rules management application that exposed all of those rules.  It allows us to have access to them, basically, on any kind of characteristic that we want to look at.  So, we are able to track the rules from beginning to end -- to understand what the change was that was made, who made it, why it was made, when it was implemented, and what the results were, coming out the other side.  

So, yes, you're right.  In the insurance industry this is something that you absolutely need to be aware of, and it's something that you need to define for and to build for.  

But, to repeat, it's not an easy thing.  It's not something that you always get buy-in for because it's one of those behind-the-scenes aspects.  Still, it's very important to get done.

Mark Myers

I've used two different tools.  I've used RuleTrack, which is an Access-based tool, and (recently) I've been using RuleXpress, which is a rather new tool (and one that I think is going to be showcased at this conference in the next session).  

Both of them are good.  But there are always challenges in developing a tool to do all the things that rule management needs.  So, I think these tools are just now coming of age.

Chuck Gulker

And no matter what tool you use to track changes -- what rules management tool -- you're always going to have the human side in any rules management.  (Now, I may be wrong ... maybe there is a way to mechanize this and, with the programming people we have in this room, perhaps we can hear what they think.)

Personally, every time I version a rule -- or what we call 'suffix a rule' (which I won't get into here) -- I always document what was done and why on a free-form comment log.  You can't really mechanize a human mind, per se.  Sometimes you just need to type in why you made a change.

We want to get to the point where we can attach Word documents, for example, as part of a release.  Nothing is better than saying, "On version 2, I made this change because of this or this or that" with my initials by it, and with any comments.  Then any co-worker, or any programmer can understand what was done.  This gives us nice narrative logs, but it requires that I had to spend the time to put it in there when the change was made.  

Mark Myers

I agree.  When doing rule management, we find that those kinds of comments are much more important than just versioning it in the rules engine, which gives us things like the date it expired, or date I put it in this class, or an annotation in an Oracle trigger.  It's the actual management of the rule that, to us, brings greater value to our business than any implementation we did that automated things.  

Garth Gehlback

In our implementation the rules can be self-documenting.  As long as the author of the rule puts in the statements, it's not only something that can be managed at design time but it's also is available at runtime.  Then you've got a full audit -- traceability for that rule and the changes that have been enacted over time.  

Michael Koscielny

I think it's critical that you have some guiding principles when you are in the rules management process, particularly in the area of documentation.  It may seem like overkill to some, but being an insurance carrier we rely on the whole requirements process and change control, with fully documented templates for all of our rules in a spreadsheet that's a living document.  It has all of the versioning documented there.  

And probably more important for us is that we never change a rule.  That is one of our guiding principles:  we always expire and create new.  That gives us this legacy of what's happened to those rules.  This is particularly important in a process like ours; many times we have to go back multiple versions of a rule to recreate what in fact happened back many years ago because of some coverage issues or loss considerations.  

It's important not just to limit what you document to what's available in the tool you might use.  Duplication of what the tools supports sometimes, I think, is a benefit to you.  But you do have to watch that the owners are consistent, because otherwise you end up with problems from not having consistency in the documentation.

.

Business rules and business process redesign

[from the audience]:  I was wondering if any of you have conducted any business process redesign efforts prior to doing the rule harvesting.  Did any of you fundamentally change the way you were doing business?  ... or offer your services in a different way?

Jack Holloway

Actually, before we got into rules, there was a great deal of redesign of the process underway.  For example, we're looking at redesigning Admissions processing at the University -- all the financial aid processes -- wanting to get away from paper.  We want to get rid of that and go entirely to imaging.  At the time we began, I was not aware of the business rules philosophy.  Just instinctively, I think that we put in rules such as, "At this point it goes to person-x and then to person-y."  

But rules do tie in very closely with your processes.  I think that to properly do a process or redesign of anything you have to first understand what are those terms on which they're based and those rules that work with the process.  This helps ensure that the things that flow off your process will get to the right place, at the right time, under the right conditions.

Chuck Gulker

I'll tell you, for the company I work with the process management (or even just understanding our processes within a Fortune 100 company) is a nightmare!  For example, we have rules that dictate, for a Personal Lines Auto, what kinds of documentation they may need.  Do they need good student grades to give a discount on an auto?  Do they need a picture of a car?  Do they need some kind of coverage rejection form?  

And then, we may know the type of documents but we don't know the process,  Do they need to keep it in the agent's office?  Do they need to send it in to the service center?  Do we need to log them?  How is this stuff routed?  Is it imaged?  Is it this?  Is it that?  

We find that rules are kind of 'in the middle' -- between the process and the program.  And we can't do anything until we begin to understand things.

.

The need for specialized rules engine technology

[from the audience]:  For implementing a business rules-driven business application, do you think that use of specialized rules engine technology is absolutely mandatory?  Or have any of you successfully used a Java or .NET-based business rules application?  For a second, related question:  What have you found to be the best argument in favor of supporting the investment in specialized rules engine technology, compared to using J2EE or .NET?

Garth Gehlback

In our case, the very nature of our fast-changing business and the policy that needed to be implemented made it necessary to go with a business rules product.  In fact, the applications that we've had in the past are so difficult to update -- with different regulatory changes, with different portfolio requirements from our different clients -- that it was just simply too difficult to do.  And it would be too difficult to do in a custom way, as well.  

So, having a specialized rules engine ...  actually, you called it "specialized" but I would rather call it "general purpose" software.  Having a rules product at the core is what's enabling us to meet our customer demand.

Mark Myers

I think the question you really have to answer is:  Do you have a business that's changing or not?  

If you're in a business where nothing has changed in the last five years, you do not need a rules engine.  You can build a perfectly good application.  In fact, I have an application that's been running for twenty-five years that we've never touched.  It calculates the water flow down a watershed and allocates shares -- that doesn't need to be changed.  

But there are other things that definitely change so much that you need to surface those aspects -- this is where you really need that technology.  This was the justification we used for a rules engine.  

Now, we don't implement everything in a rules engine.  After all, you have rules implemented all over the place in your company.  It's where you have things that need to be changed, that's where we put in a rules engine.

Patti Rottenbiller

To add to that I would say:  If you have rules that are shared -- shared among multiple applications, among multiple lines of business -- those are types of rules that are prime examples to be implemented in a rules engine.  

Plus, to repeat something Chuck and I said in our earlier presentation:  Regardless of whether you have a rules engine or not, I still think it's incredibly important to have a rules management application that exposes those rules to the business so they know what the rules are.  This is important, even if the rules don't change.

Chuck Gulker

We're trying to get to the point where we build what we call 'control files'.  We have some old screening technology that actually allows a complete novice (someone who can't even spell 'programming') to go in, hit a couple of PF Keys on their keyboard, and turn things on and off; they can even change some minimal variables.  

Like a lot of companies, speed-to-market is what we are after.  So, we are trying to get to the next level of these control files, trying to identify what things really, really change and what things need to be changed quickly.  Then we will try to put those things in the hands of our field underwriters in a point-and-click environment.  It's all about speed-to-market.

.

Internal data standardization; selling the discipline of change control

[from the audience]:  Two questions, if I might.  The first gets back to the data issue.  For companies with multiple systems, 'claim' looks different to each of these systems.  For example, several systems could be processing data about medical claims or workers' comp claims.  They're all 'claims' but the types of data -- the ranges of valid values -- are very likely to be different.  Take, for example, EDI transactions; they have their own standard set of values.   So what I am wondering is:  Do you try to translate things to some universal business object that has a standard defined list or range of values, and then invoke the rules engine against that standard?  Or have you put the rules engine inside each of the legacy systems so that you're actually writing rules that talk in terms of those various, legacy range values?  Where they are different, you can't really share very well across application boundaries.  So, while the concept might be the same, the implementation would be different because of those differences in formats. My second question is:  Has it been difficult to get the business to embrace the discipline of change control, configuration management, QA, etc.?  A lot of the disciplines that "slow IT down" are sometimes the disciplines that we invoke purposefully to try to produce a more quality product.

Patti Rottenbiller

I can speak to the data question.  (I'm wondering if you work for Nationwide, with that kind of question!)  <laughter>  I'll tell you, we haven't figured it out yet.  We've tried kind of a combination of all of the things that you mentioned.  

For the rules engine application that we have currently implemented we did standardize on an XML logical data format.  And that did make things very easy to implement inside the rules engine.  As we move forward, adding more legacy systems, that's not going to happen.  So, we're still trying to figure that out; we're crossing that bridge.

We are taking an approach right now where we are defining a meaningful data structure inside our rules application, one that makes sense to us and makes sense to our business rules.  And then there will have to be some sort of a transformation process that happens before the data gets to us so that we can execute our rules.

Mark Myers

We've done both a Java and a .NET implementation.  And, on the .NET side, we're creating an object model that we then populate and pass that into the rules engine.  We are creating that domain model based on our fact model and the analysis we did up front.  We're trying to base our objects on the responsibilities of the business so that they become changeable with the business.

Michael Koscielny

We've gone the route of having the model and the rules engine be consistent and building the translation.  We did this because not only do we have many legacy systems that we're trying to integrate into this but now we're also getting data from outside vendors.  

As an insurer who deals with independent agents and captive agents there are agency management systems that are looking to bridge data and make the process of doing business with insurance carriers a lot easier.  But those systems are in different languages.  So, it's important that we can address that by having a consistent set of data that the rules engine looks at.

On the other side (your other question)...  You never have to convince an underwriter that structure and testing is important!  At least, that's the case in the insurance business.  And, if underwriters are the people who are the business evangelists in the process, they'll be on your side immediately.  

That's been my biggest mantra -- to constantly talk about testing.  To my mind, they don't test enough.  Right now, we participate in the user testing in the Underwriting Department throughout any deployment of rules because it's critical.  Whatever happens, whatever change we make, whatever new release ... it has to be as accurate as we can expect it to be.  The last thing we want to do is "test in production"!

Jack Holloway

To answer the second part of the question:  Does IT mind (are they bothered) by being slowed down, in a sense?  I'm going to piggyback off the prior answer:  It might take more time up front, but that time should have been spent in any case.  You should have that culture in place where you are spending additional time up front so that you are not finding those problems in production and spending additional, exaggerated time trying to fix them.  It comes down to that cultural change at your work -- a culture where IT says, "OK, we're going to trust you, business, to give us a complete set of definitions up front.  And when we code that, we'll get rid of those errors."

I love what Jan said earlier today -- that it's easier to not work around the errors if you don't create the errors in the first place.  That is so true.  It comes down to writing your business rules properly.

Chuck Gulker

That's why I put this into one of my DOs:  Before you code anything, spend the time to have all affected areas -- developer, tester, business, sales people -- all look at it together.  And then do the coding.

At Nationwide we keep track of our defects religiously.  We categorize defects two different ways.  They are either (1) a requirement error on the business (which would be, for example, my error) or (2) a coding error.  And we -- on the business side -- are just as  guilty of putting in the wrong requirement.  And, then, we end up having to do an enhancement or a tweak to the system.  But, either way, an error is an error -- it's something not working as an end user intended.  Those requirement errors are just as bad.

.

Approaches to handling business change

[from the audience]:  This question is related to business change.  For example, if you have a business that is changing and you find this changes a business rule, what kind of impact analysis do you do?  Is there a standard methodology (or a process or an approach) that you follow to do your business change?  I am especially concerned about the many downstream systems that might be built on this business rule.  Any tweak to the business rule is going to have a lot of impact on the downstream systems.  This is particularly true in the data warehousing world I come from.  We have so many analytical applications that are built based on the business rules that are set forward.

Garth Gehlback

We're using a system where that kind of change impact analysis can be done at design time.  So, using the modeling tool, we can determine what all is affected by any given change, ensure logical consistency, and then actually to go through and check business intent and consistency, before ever deploying those rules.  So, there's a great deal of confidence in how we deploy change -- that we've got it right and that we've guaranteed (basically) that we've got logical and business integrity after any of those changes.

Gladys S.W. Lam

The question is:  Are you following any standards?

Garth Gehlback

I'm not aware of any standards that are driving the change impact process.  I'd love to hear about some, if there are any.  But we've been successful using the system that we've got.

Mark Myers

On other systems I've deployed what I call 'hot deployment' -- you saw that at lunch today, where you change a rule and it instantly updates.  That's really cool, but it can be really dangerous.  So I don't ever deploy that kind of thing with rules.  Once the business user puts in the rule change then that has to go through a change process.  IT can deploy it once it has been tested.  

So, yes, there is a process there.  Even though you can do 'hot' deployment for rapid change, I don't recommend it.

Michael Koscielny

One thing we do... we follow the same process for change as we do for new development.  We go back to the beginning -- the entire group -- and do requirements gathering, with impact (obviously) because now we're changing something, so we take that into account.  But with every change we do start at the beginning and follow the same rigor that we would if we were going to develop something brand new.  Gee whiz, it's fun to put something in and see what happens immediately, but you've got to test this stuff!  And you've got to test it more than you've ever tested anything.  

If there was a wish I could have, it would be that the providers of rules tools had regression testing capabilities built in that were robust enough that you could really anticipate every possible iteration of the change that's being put in place.  I'm sure everybody at this table has put a change into production, and a week later (or less, usually two days!) there's a problem.  If it's Saturday, by Tuesday I'm hearing of the defects we just did because we broke something in the chain and we didn't test it thoroughly enough from a regression standpoint.

Chuck Gulker

I agree.  But the problem in the real world -- and we've all been there -- is:  Some kind of late-breaking development will come ... some new product, or you get a late requirement, or the programmers are screaming that their cutoff is tomorrow, or they need a rule by lunchtime.  Okay, so you have this great methodology and sign-offs and rule review sessions, and everything else.  Then it comes down to the fact that they need a rule, and they need it now, to code NOW.  You don't have a lot of chance to go through a lot of stuff.  And I guess that's why they pay you what they pay you.  A lot of times you just write it and hope it sticks.  

The way around that would be to have more lead time, to get business requirements regarding the product sooner etc.  But that's all for a perfect world.  I've written so many rules literally with 30 minutes notice.  I know that's not conducive to good rules, but unfortunately that's often just the way it is.  And we've all been there.

.

Selling business rule 'features' to the business person

[from the audience]:  Actually, I have two questions.  The first one is for the business people:  What business rule ideas did you buy into?  And, for the technical people:  What business rule features did you try to sell to the business people?  My second question is:  What features do you miss most in your existing tools?  What do you wish you had? Gladys S.W. Lam It's Christmas time!!  <laughter> Jack Holloway Could you clarify the first part of your question -- are you asking what we need to do to try to sell the concept of a business rule?   <audience> I am asking what attracted you to the business rules approach?

Jack Holloway

Oh.  I love simplicity.  And I love efficiency!  That is probably the biggest thing that attracted me to business rules.  To me, it came down to a 'true/false' statement:  Here is the rule, with clarity for everyone. 

What I saw happening in our IT world was coding that went into place based on someone's paragraph they wrote of an opinion.  Business rules get rid of, strip away, the opinion part; they get us down to that important nugget of information.  Plus, the rule is consistent, regardless of what day or what year or what person.  It's the same piece. 

So, that's what really drew my attention to this thing called 'rules'.  If we can really cull down all the fluff that's in our systems (and in our training of the new staff) to the business rules, I thought:  This has a long range and a wonderful payoff.

Chuck Gulker

I would agree.  I think it's the objectivity.  When you're dealing with insurance (and we all have cars that we have to insure, for example), rules takes away some of the subjectivity of underwriting, which, depending on what product you are selling, is a good thing because we want to get exposures classified right.  That means people are going to be priced right for their insurance. 

Without rules management you're again at the whim of some new underwriter (and I was one of them!) who might have had two weeks of training, right out of college; the next thing you know I have three districts of agents and I'm supposed to be an 'expert' at slotting these things in right.

So, rules management allows a little bit more guidance -- mechanical guidance.  And if you can externalize the rules you're even that much better.

Gladys S.W. Lam

I hate to do this but the time is coming up close and I still see a lot of hands up.  I can only do one more question.  Let's do this one final question and then, unfortunately, I have to call things to a close.  Otherwise my co-chairs will drag me out of here with a hook.

.

The role of the business / rules analyst

[from the audience]:  This session has been a bit of an epiphany so far.  Our organization has been talking about this business rules approach for a couple of years, and I'm just recognizing that we haven't been living it.  There's that talking the talk versus walking the walk kind of thing.  I've had some discussions with Jack after his session, and we discussed his idea of this third body -- the pure business, pure IT, and then this business analyst group in-between.  I'm starting to recognize that my team is in that role.  But, for that business analyst, Jack has talked about how it's a bit of an art, as opposed to a science.  Yet for that declarative rule there is still the ambiguity that's involved with the English language -- Dr. Silvie talks about all these pitfall words.  So, I can hire my grade-3 English teacher and say, "Boy, bring it all back."  But, short of that, what would be the key competencies that you look for in that business analyst, between that hard science and that art aspect?

Jack Holloway

Gumption!  It's a different type of person to hire.  And a different type of person who thinks.  

I put up some quick examples of some questions that I ask when I'm trying to find that business analyst.  But what triggers me when someone walks in (and usually after five minutes I can sense, "Ah, this person just might have it!") is their innate curiosity.  Also, I look for them to say, "Validate that for me."  They inquire; they didn't take it as fact right up front.  They are willing to question things.  

Also, It's willingness to work in a grey area.  This is important because, if you aren't reporting to IT and you're not reporting to business, often you are making decisions for both areas ... maybe not a 'decision' but a recommendation.  And that person has to have confidence in themself and confidence in the business.  

Of course, experience in the business helps even more.  If the person has worked in that particular area for five years, it's great.  But in my particular area, it's not mandatory that you've worked in the University of Phoenix for five years.  I'd be happy to take someone off the street.  I cannot train the art of interviewing (really, it's 'interrogating') the different people.  It's the ability to strip away assumption vs. fact vs. want vs. need.  I can train them to the business needs that are out there.

I have gone through interviewing books, trying to find the best questions to identify that critical mind.  I have always joked that maybe my ultimate test would be to grab a Rubix Cube and say, "Go!"  Do they balk, or do they try?  I'm looking for that mentality -- that puzzle solver who likes to do things like that.

Mark Myers

There are some excellent articles by Kristen Seer on the BRCommunity web site that address that very question.  I think one was written about a year ago, and there's also a current series that is running this month.  So you might go there and take a look.

[ed. The URL to Kristen's article is:   www.BRCommunity.com/a2005/b255.html ].

Patti Rottenbiller

I'd also like to mention this important thing to think about:  No matter how your organization is structured, you're looking for someone who is willing to step outside of those boundaries.  At Nationwide we have a fairly traditional organizational structure, where our business community is lined up according to the products.  Our IT application areas are lined up according to the applications that they support.  

When you are talking about business rules, especially rules that are shared across many lines of business and many organizational units, it doesn't always work.  So you have to look for people who are willing step over those boundaries and think, "OK, I'm not just in Auto Underwriting Systems today.  I have to think about how this applies to Commercial .. how does this apply to Life?"  

You really need those people who cross the line, both ways -- from IT to business, and from business to IT -- regardless of how you are organizationally aligned.

Gladys S.W. Lam

Someone gave me a note that says to look into IIBA -- International Institute of Business Analysts -- at IIBA.com.  

[ed. The URL is:   www.IIBA.com ].

Michael Koscielny

The only other thing I would add is:  Don't be afraid to ask for help.  The initial deployment of our rules engine came with the help of a consulting firm, who brought in business analyst expertise.  They helped teach our business analysts how to begin (and also helped cull out the ones who couldn't).  So, don't be afraid to bring in outside resources to give you some assistance early on in the process.

In summary, the business analyst has to have some irreverence for both sides -- enough to challenge each one of them to get the real truth about what the rule is.

---

Gladys S.W. Lam

I hate to do this, but we are over our time.  I'm sorry to those who still have raised hands and we didn't get to you.  But my sincere thanks to the whole panel.  You've been great!  Absolutely great!  Thank you all for participating.

# # #