Panelists

AS = Adrianne Setzer, Delta Technology

DC = Donald Chapin, Business Semantics Ltd

GP = Gary Peck, Nationwide Insurance

JR = Judi Reeder, Knowledge Partner, Inc.

KK = Kit Kwan, London Life Insurance Company

RH = Rolando Hernandez, BizRules.com

Moderator

*/ ?>

GL = Gladys Lam, Business Rule Solutions, LLC

Introductions

[GL]: The theme for the panel discussion is "The DOs and DON'Ts of Business Rules."      I often get phone calls from people who tell me they are starting a business rule project and they want to "start smart." They ask what they should do -- what they should watch out for.      So I thought, what better opportunity do we have here in the Forum than to put together a panel of practitioners who have been through it! With the six panelists here, you are probably looking at over a thousand dollars an hour of consulting advice. So you can look at this hour alone as giving you your return value for the conference!      I have asked each of the panelists to provide a two-minute introduction (name, title, company) and some background of the business rules projects they have worked in. I've also asked them each to provide one piece of advice on "what to do" and one piece of advice on "what not to do" on a business rules project -- one DO and one DON'T.      After the introductions I will lead off with a question that was posted on the board, and ask the panelists to answer it. Then I will open the floor up for questions.

AS

*/ ?>

My name is Adrianne Setzer. I am a senior analyst for Delta Technology, a wholly-owned subsidiary of Delta Airlines.

The business project that I worked on in order to learn more about business rules and implement them from a business rule approach involved capturing the sales data off of our tickets that are sold by travel agencies with Delta Airlines. We picked travel agencies first because it was the most readily available to us, in the format that we needed to process quickly. We broke that project into about five phases and, initially, "identifying the business rules" was phase-three. Well, that became an impossibility! When it came time to write the use cases, the analysts said, "well, we've got to do something with the business rules." The coders were ready to code and they said, "we can't do this without the business rules." We had already thought about this, and we were ready. We said, "we have the business rules almost ready for you," and we moved the business rules up into phase-one.

You know, asking the question "what are the DON'Ts?" is like asking "if I had to live my life over again, what would I not do?" Well, I wouldn't change anything. I would still go ahead and do a lot of the same things.

There was one thing that we did struggle with, though. My manager told me "find a way to integrate the business rules into your use cases." This was the most frustrating task that I have ever done! I could not do this task until I brought it to an abstract level. This is when we came to the realization that we needed a business rules repository.

This has been one of the better conferences that I have attended. We have done a lot of research and reading on business rule subjects. The other people from Delta Technology and I have been working on this for two years. Two years ago we could go out to the web and we could search and not find anything on "business rules." Now I can go out there and find whatever I need to help me learn about business rules. I think this is an accomplishment of the people who are here today. That's been great.

My biggest DO is to practice writing business rules. Look at some of these vendors -- see what their products are and practice using those products. Those are my biggest DOs and DON'Ts.

JR

*/ ?>

I'm Judi Reeder. I work for Knowledge Partners Incorporated. I'm actually "employee number 006." I wanted to hold out for 007 but I couldn't quite do that. Actually, tomorrow is my third year anniversary with Knowledge Partners -- so I am one of the founding partners.

I've been on only a couple of projects that were formally doing business rules. Most of the other times that I've used business rules we were just doing them and not asking permission -- saying "well, I thought that's what I thought you wanted the deliverable to look like!" -- and mostly they are delighted. So one of my DOs is to "always do business rules." Look for opportunities to put some form of 'templates' around the knowledge in a consistent fashion and call it a business rule. See where it goes.

A couple of years ago, I had the privilege of working with two other people who were here this week: Neville Haggerty, who's also a Knowledge Partner, and Ellen Gottesdiener, from Indianapolis. We worked together with a mid-West insurance company, and we were capturing business rules. We were working at Zachman Row-2 and doing it with facilitated sessions. We were not obsessing about the data model underneath (which those of you who know me can understand that not obsessing about data for a couple of weeks was kind of strange).

We had systems people in the room and it was their responsibility to be able to track the Terms that we were using, defining down to the underlying data stores. So that aspect was not our goal. Our goal was to capture the business knowledge at the level of things like "if the condition of the insured is a broken leg, and the claim was filed within the last 4 months, and the occupation of the claimant is accountant then I'm concerned." This was the level of business rule that we were looking at.

That turned out to be very interesting for all of us. There was a lot of learning in the business community about the value of business rules simply from a training perspective.

Another place I was able to use business rules was in program specs. I was working with a telecommunications company, and we were attempting to feed an Excel spreadsheet from a marketing organization into a SQL-Server database. If anyone has tried to impose consistency on a bunch of marketers, especially when they're used to using an Excel spreadsheet which allows "NA" in the price field, putting together program specs is a challenge. We specified not only what would be allowed as incoming values but also included (thanks to Ron and Gladys' work) the error message that would come out when that rule was violated. And we were using the business rule as the error.

As far as DON'Ts, I think the biggest problem that any analyst gets into -- and business rules is an analysis effort -- is to not get into "analysis paralysis." Put your business rules out there. Let people comment on them, and get them "socialized" as quickly as possible.

DC

*/ ?>

My name is Donald Chapin. I am a business analysis and requirements consultant specializing in a business rule approach. I am based in London (in the UK) and my company is Business Semantics Ltd.

The project I am particularly focusing on for these questions was a mission-critical business capability that was cross-departmental. The business driver was flexibility over the long term. A corollary of that was management control because the current systems weren't flexible and everybody was end-running them.

It was obvious that it was a "rules problem" and that was great. It was both improved working practices and a new system -- as a single package -- so that was good. Also there were three separate business segments that were doing practically the same thing, completely independently. These were to be replaced by one business process and one new system.

What I'd like to suggest as a SHOULD is that always take time to rethink your business context, right up front in your project, using an approach a lot like what Ron Ross was talking about on Tuesday -- the Policy Charter where you deal with your tactics and your risks and your policies. This just changes the whole thing, and it made it so much easier to do everything else after that. It really transformed the whole context.

In terms of what not to do: DON'T get ahead of your Term definitions. Don't define Rules before you've defined your Facts. Don't define your Facts before you define your Terms. And do this all in a pure business sense (forgetting IT). We tried to do that, but every little time we didn't it cost us something and we had to go back. So I really encourage you to keep your Term definitions agreed as you go.

KK

*/ ?>

My name is Kit Kwan and I'm a business architect, or systems analyst, at London Life Insurance Company. We are not located in London, England, but instead we are located in London, Ontario, in Canada.

The project that I worked on was the implementation of a system using an abstract architecture, which is called the Insurance Application Architecture (IAA). So far, the implementation is successful for release one. But we did find a lot of pitfalls after the implementation. This was because we tended to drop into IT terms so we lost the business context and we missed some business rules which we only found out about later, during acceptance testing.

When I learned about the business rule approach I immediately tried to apply it in release two of our project. We've seen a lot of benefits in doing this, and I definitely recommend you DO use a business rule approach when you do a big project, especially during the requirements analysis phase.

One thing that I would advise you not to do is: DON'T overwhelm your business users with your abstract terms. Stick to the core business terms. Do not overwhelm them with jargon (like "a business rule approach") because "business rules" is simply common sense to them.

GP

*/ ?>

My name is Gary Peck. I am an IT manager at Nationwide Insurance, in Columbus, Ohio, in the Personal Lines insurance area. .

The project we did was to extend our underwriting capabilities, the decisioning capabilities (etc.) out to the point-of-sale. We did that under the constraint of having to integrate with the CRM application. In other words, we were pretty much considered like a "bolt on."

So far we've delivered the business language rules repository -- something that we developed and delivered ourselves. And we've also delivered knowledge-based application components. We now have standard rule sets in production, executing across multiple distribution channels.

One of the things that I think we've done very well and I definitely want to do again is we DO want to deliver free-standing application components. I think that's important, in general, and in rules-based architectures I believe it's especially critical.

One of the things I would do differently is we need to do a better job of completing the analysis phase. In our organization we are constantly "re-inventing the wheel"; we don't have an engineering discipline when it comes to completing analysis. So we need some assistance there.

RH

*/ ?>

My name is Rolando Hernandez, and I'm with BizRules.com. I have been in the business rules field for over ten years -- back when it was called "artificial intelligence" and "expert systems," and I've stayed with it.

Right now I'm an independent consultant in the business rules area I'm trying to figure out what customers and businesses need -- what you are looking for, what sort of services or solutions you need so that I can figure out a way to deliver them to you. I would like to help companies manage knowledge and build one-to-one personalized customer relationships, hopefully using rule-engines. I think rule engines are the key to CRM and one-to-one relationships -- strengthening your customer relationships is what I'm going to be talking about.

My background is working in large companies. I have led and worked on strategic projects for companies like Mobil Oil, Pepsi-Cola/Brazil, Burger King Corp., EDS, Royal Caribbean Cruise Lines, and the Government of Canada.

My experience with rule engines is building rule engine strategy/business rule strategy for Mobil Oil, and working on the Canada Social Security re-engineering effort -- rewriting the Social Security System -- which was a massive rule engine effort.

For my DOs and DON'Ts, I would start with: DO get business and expert buy-in -- without that you will be wasting your time. DO find all the existing knowledge sources -- the manuals, the emails, the notes (everything that has been written). DO research -- become an expert in the field before you have that first meeting with the "experts" so that they're not wasting time giving you trivial, basic information. Without that, they'll feel your are wasting their time.

My top DON'T would be: DON'T do it fast. The first project will take time. DON'T build a rule engine; buy one. Finally, DON'T say "this is the Holy Grail" -- the answer to everything. Please remember what happened to "expert systems"!

How do you sell (promote) moving to a business rule approach?

[GL]: I'd like to open the panel discussion with what seems to be a "burning question" running through the whole conference: "how do you sell (promote, preach) business rules?" How can you make the organization realize that a business rule approach is the way to go?      A related question is: "Who in the organization should sponsor business rules?" Who should you get buy-in from? Rolando, you said that it's important to get buy-in. From whom should we get this buy-in?

RH

*/ ?>

Get buy-in from whoever has the checkbook! I've struggled with selling this to IT, but at the end of the day, they say "well, that's great; we know we need it, but the business isn't asking for it -- they don't demand it." And we don't have time to wander back and forth.

JR

*/ ?>

There are a number of ways to promote business rules, I think I certainly agree with Rolando -- don't make "business rules" the silver bullet. And I also agree with Kit when she said it's not necessary to call it a "business rule approach" because you certainly don't want them to think that this is the first time you've considered business rules.

A lot of times, when IT tries to talk with the business environment, there needs to be clarification of what we're talking about. We think that our words make a lot of sense, but if we don't show examples of what we're talking about it's awfully hard to get across the concepts. Knowledge Partners uses a series of templates for the different types of business rules. (I don't think that we are unique in that fashion.) When I start talking business rules to a client, I try to use examples of business rules that are likely to be in their environment. I think that certainly is one of the ways to go.

Another technique is to find anecdotes -- stories where business rules that didn't work, or weren't followed, or weren't documented, or conflicted. Again, it's finding out about the business: finding where the surprises have been (either positive surprises or negative surprises) and suggesting how documentation of the business rules for everyone to follow might have avoided some of those problems.

DC

*/ ?>

I was fortunate that there was someone in the organization whose job it was to see that IT supported business objectives -- a manager who was in between the two. He was key in understanding the IT side. Once we got past that the business side was really easy because, in my opinion, it's just natural to business people.

GP

*/ ?>

I guess I would have to echo that comment. Of course, in our organization the business side is the one that's controlling the dollars. They tell us to work on the project; they tell us to stop working on the project. In a large insurance company we spend millions and millions of dollars every year on existing legacy code. So if you can prove to them that you are going to cut legacy cost down the line or provide them with more flexibility, they're going to want it.

AS

*/ ?>

One of the things that helped us was not a person, it was an event --"Y2K" -- because we had to revamp a lot of customer services. Now that we've gotten past that, some really good, vision-minded management has come on board to our company both on the Delta Tech side and on the Delta Airline side. And on the Delta Airline side we now have someone who is a data architect who had been involved with "rule approaches" before. This is really going to help our vision. I almost hesitate to say this, but we're going through another reorganization. However, this time we're going to re-align to a business rule approach. So I don't think we're going to have as much convincing!

Another thing that helps are the vendors out there that are pushing their information out on the web. Our business customer, Delta Airline, is going out to the web to see what's available. Now they're actually coming to IT saying, "can we put this in?" This is really helping us get support to take a business rule approach and move forward with it.

JR

*/ ?>

I think that what we're seeing is that it depends on the type of business rule that you're trying to deal with. One of the things I'm learning from this conference is that we need to "put adjectives in front of business rules." You know that if I'm talking about business rules in COBOL code that's a little bit different than if I'm talking about business rules when I'm at the manager or the director level.

In the company where I'm currently working, we are trying to assess business rule mining as a way of uncovering the best sources for a data warehouse going forward -- doing both data quality assessments of its data content and business rule mining. In this case, the sponsor is going to be within the IT organization. Once the dollars have been delivered for the data warehouse project, how we put it together is probably going to be protected from the business community. This will give the organization a chance to experience business rules, somewhat "protected" from the business area. We will also be able to provide that in the business metadata once the data warehouse goes up.

Unfortunately, like a lot of answers I think that the answer has to be "it depends." If I'm trying to deal with strategies and visions and goals and policies -- from that perspective -- and I don't have a business sponsor, then I certainly don't want to take on that role.

RH

*/ ?>

I just remembered one relevant experience. I've been consulting at a major cruise line for the last two years. We were not doing business rules, but I was trying to sell them on Blaze as part of rewriting their reservation system. It was a struggle -- IT really didn't want to deal with it.

Meanwhile, while we were doing that, the business went out and bought a package called Callidus to help them with commissioning of their field sales reps. Marketing bought and implemented that package without telling IT. Eventually, they called IT for help. But until then, IT was not involved.

The irony is that Callidus uses the Blaze rule engine. We were in IT, struggling to try to get them to look at Blaze and they didn't want to deal with this. But Marketing was able to bring this package in because Callidus lets them define their own commissioning business rules.

GL

*/ ?>

So how does the story end? Did IT go on and get Blaze?

RH

*/ ?>

No, they have only Callidus. Marketing is entering their own business rules, and IT only helps them with the system is down.

The Stability of a Business Rule Approach

[from the audience]: Something that has struck me at this Forum is the terminology of what "business rule" means. There seems to be a lot of disagreement. When I try to sell my manager he will ask me the questions, "what's the leading thinking about what a business rule is?" and "what's the likelihood that in six months to a year there's going to be different convergence or leading thinking?"       I would like to hear the panelists' thoughts on whether they think there is some convergence ahead, or is there more likely to be a major shift, say, in a year or two? I'm concerned about portability issues down the road with what we develop if we start today.

JR

*/ ?>

I brought this issue of terminology up earlier when I said that I feel we need to "put adjectives in front of business rules." There are a variety of approaches within the whole area of business rules, and certainly those of us familiar with the Zachman Framework fall back on that to help sort things out. While I'm not sure whether I need to differentiate rules by the Columns in the Framework, I certainly need to differentiate business rules by the Rows -- the "perspectives." In other words, am I talking about a business rule from a managerial, business owner perspective? Am I talking about a business rule from a systems analysis perspective? Or, am I talking about a business rule from an implementation perspective? I think that's the least we need to differentiate, when dealing with those perspectives.

It was interested to note that most of the vendors here are involved in some level of implementation -- not all of them, but most. And even these vendors still have different environments for rule capture and rule implementation. In between the capture and the implementation is the analysis area. That's where we have the mapping of the business term to a method or to an object attribute or to a class in the implementation.

So, we have the "owners' perspective" of the business rules -- the capture part of a business rule is Zachman Row-2. The analysis (the mapping of those business terms to the underlying data structures) is the Row-3 perspective of the business rules. And then whether the business rule is implemented in Java or C++ or COBOL or something else, that's the Row-4 perspective of the business rules (in my mind).

GL

*/ ?>

Does the rest of the panel have anything to add to that?

DC

*/ ?>

I heard a second part of that question asking about "standards" for business rules -- in terms of exchanging them. Could you elaborate on that part of your question?

[audience-member]

*/ ?>

Yes, I was hearing so many distinctions -- some people were saying "don't worry about what a business rule is: it can be a process; it can be procedural things." So what I'm concerned about is, if I'm going to buy a vendor's product that has such general assumptions, is it likely that I'm going to lose some value because the product is trying to do something that is a little more eccentric compared to what the general thinking is focused on now? And in a year is that likely to change? Or do you think we will still be treating rules in the same way in terms of their attributes and where they fit in Zachman -- that kind of thing.

DC

*/ ?>

The closer you get to the business level, which is your original source of business rules, your rules are only going to change as the business changes. And the worst you'll have to do is then map them to some new implementation technology by this systems analysis approach that Judi mentioned. So I would try, as much as possible, to capture your business rules at the business level to avoid that problem.

Business Rule Engine versus Database

[from the audience]: As a follow-up to that question, I would like to focus in and talk about rule engines, rather than business rule tools in general. I read some comments by GIGA and META, Gartner Group (etc.) -- several reports that indicated that there won't be a market for business rule engines. They are advising people that, if you want to use a rule engine, look for a database product or an application server product that can generally do what a rule engine can do. I'm a "believer," but I want to know your opinion. [GL]: Panelists -- what kinds of rule engines are in your organizations right now? And what is your opinion on those?

GP

*/ ?>

We're using Blaze Expert, and we've been relatively successful at getting what we need done with it. We plan to continue using it.

GL

*/ ?>

Kit, do you have a rule engine as well?

KK

*/ ?>

No, we do not. Actually our project was somewhat object-oriented in terms of its design, but the rule technology is just a traditional COBOL implementation. It might be interesting to find out if we could convert. that to some kind of a rule engine.

JR

*/ ?>

Personally, I don't have a lot of experience with rule engines, but some of the other members of the Knowledge Partners family are in the middle of writing a book on business rule technologies. They are taking a case study and giving it to any of the rule engine vendors that are interested, asking them to respond to the same case study using their technology. I think what will happen from this is an ability to take the same information and compare across different interpretations, different rule engines' capabilities, and be able to see the strengths and weaknesses and determine which technologies are appropriate for you.

One of the things that I've been proselytizing for several years is to try to take your business rules and have them be part of your RFP. That way, when you go out to vendors they know exactly what it is that you need to have done because you have your rules stated in that templated fashion. (I'm assuming that my business rules are going to be templated, even up in Row-2. This gives some consistency of format that I don't always see in the presentations on business rules.)

I think that the jury is still out. My guess is that there is going to be a lot of shake up among the business rule vendors.

DC

*/ ?>

Just a comment on the advisors' comments about there not being a market for business rules -- recommending that you should instead use a database and so on. It occurs to me that, if you were here on Tuesday night and heard Chris Date, his whole point was that rule engines really can be thought of as a database, and that the databases are just data stores that serve it. So I suppose that this could be a common way of understanding what they were talking about, although one doesn't know that these advisor groups actually had that in mind.

GL

*/ ?>

Adrianne, does your organization use a rule engine?

AS

*/ ?>

In our organization there's not always a lot of visibility into what's being done from one department to another. I did find out today that we have Informatica in-house, and we also have a PC, AION-based rule engine that works off about eight different backend reservation systems projects.

We've had about 3 or 4 rules-based approaches for projects now, and it's only during the past two years that we've really had a good start in our company. In the vision that we have right now we're looking at putting in a repository just to manage the rules. Also, we see several rule engines; I don't think just one rule engine is the answer. And, it may not even be a rule engine; it may be what has been discussed here -- a database that acts as a rule engine. We're still looking for some of these answers as well. We're just getting going in this.

GL

*/ ?>

Rolando, do you use a rule engine?

RH

*/ ?>

I've used mainly AION.

Business Rule Engine versus Business Rule Repository

[from the audience]: Listening to you all speak has raised another question that gets back to the issue of standard definitions. I am hearing that we need to have a "rules repository" -- some place to hold the rules -- but not necessarily a "rule engine." And I'm also hearing that both of these can just be databases.      So my question to you is: what is the difference between storing my rules in a database as a repository and not necessarily having an engine? What is it that the business rules repository does that the business rule engine doesn't (or vice-versa)? What's the difference between those two, or are they the same?

DC

*/ ?>

Here is a general distinction between a rules repository and a rule engine -- repository is about managing the rules; the engine is about executing them and applying them in an automated fashion to some process or context.

GP

*/ ?>

One of the benefits I feel that we have from a rules repository is now we have a consistent understanding across all our organizations, of what the rules actually are. In essence, to put the rules into the repository we had to go through policy and procedure manuals, we had to go through documentation, and we had to go through program code. And after we did all of that, in combination with our business partners we went through a review and approval process.

The rules we now have in production are published and identified. They are acting the way it says in the repository. It's not some decision that has been left up to a programmer to interpret; it's pretty black and white. That's the big benefit I see today.

One of the things I think we can go forward with, having a repository, is that we can begin to employ knowledge management of those rules. Previously it was elusive because you couldn't get your hands around it -- you couldn't share this kind of information. For example, one of the things I'm hoping to do next year is to take part of that repository out to my end customers -- the people who are selling the insurance -- so that can understand why those rules are appearing on the screen.

AS

*/ ?>

I agree they're both in a database -- they have to be. I can't just dump stuff into a Word document anymore, and I can't dump it into Excel spreadsheets. We tried that, and we knew it wasn't going to work. Even Access -- it wasn't enough for us to be able to put our thousands of mined rules into and be able to work with.

KK

*/ ?>

I agree with Donald on the difference between the repository and the engine -- -- one is execution and the other one is for documentation and management. One advantage of a repository is you hold all your manual rules as well as your automated rules. You have one central place where you can go to find both of these types of rules. And it doesn't necessarily have to be in a "database" -- so long as it's in a central place where everybody else can find things.

JR

*/ ?>

I certainly agree with a lot of what has been said here. But we've been focusing mainly on the "must" rules here. When we talk about a rule engine we're pretty much assuming that we are dealing with "must" rules.

Going back to the first question (how do you sell this?), one of the mistakes that we sometimes can make inadvertently is to leave the impression that all we need is a rule engine and then we can get rid of all the managers who are doing any of the thinking. There is a tremendous amount of Row-2 business rules that are heuristics (as Ron would say). They are the "shoulds" or they are the "mights" (I think that there are two levels of optionality). If I have a batch system, it's pretty difficult to put a "should" rule into a batch system!

So I think that we have to realize that the rule engine has some areas that it can support well -- the "must" rules. But there are also a lot of additional rules that we probably want to manage, make available on the web, and generally have available for people as an assistance. We do need to make that distinction.

From Rules Repository into Rule Engine

[from the audience]: Some of you already addressed this informally, but I'd like to hear more about what did with your rules after you identified them and put them into a repository? If you are doing this with separate rules repositories and rule engines, how do you bring this together -- to execute the rules and incorporate them into a "system"?

AS

*/ ?>

Right now, our rules repository is just version-1 and really we need to do a better job here. We took those rules, and we had coders that coded C++ from them. This was a mistake, but we couldn't get the other end to talk. We almost had a rule engine in to be able to execute the rules. But then we had a change in management, and they wouldn't sign on the bottom line.

However, we do have someone who manages the rules. This is the way it works now: they analyze the rule, make the changes, and then hand it off to the programmer. For the application we have, we really do need to get a rule engine to go with it, but we aren't mature enough yet. As I said, we're only version-1 so we really a bit more maturity than what we have now.

KK

*/ ?>

In my implementation we try to translate core business rules into IT terms and then we code them in our COBOL programs, which we call the "object methods." So all our automated rules are in COBOL programs.

DC

*/ ?>

We haven't actually implemented yet, but there has been quite a lot of evaluation and research on how we want to do that. The Terms and Facts part of the business rules are in an Object Role Modeling (ORM) tool that's in Visio Enterprise, which will generate the normalized Entity-Relationship Model and then the database. So that's the way we plan to carry that part forward.

We're also working with a rule engine vendor where the way they express their rules, in a declarative fashion, is almost one-for-one with the [Business Rule Solutions'] RuleSpeak business statements that we've collected -- not a hundred percent, but close. So we're hoping for this to be quite a straight-forward mapping for us.

JR

*/ ?>

The first of my two examples was the spreadsheet going into a database from the marketing organization. There the programs were written in Visual Basic, and the business rules were the error messages. That's the only way the business rules were implemented.

In the second case, the insurance company, for a number of reasons the rules were not going to be implemented. One of these was that it is illegal to capture some of the data that is needed to fire the rules. (And the conclusions are also illegal to capture.) So they were going to use the business rules more from a training perspective. So there was no goal of implementing per se in this case.

Their major area of pain in the mentoring system they used for the new claims analysts. It required a significant amount of time from the experienced people in doing some of the initial training. They had a new class of trainees coming in 3 months, and they needed to have more effective training material. Since most of their rules were not "must" rules -- they were "should" rules -- we were able to use their business rules for the "guidance" part of the training. In fact, there was a secondary insight that came out of this. They felt that with a little bit more work their rules could be tightened up significantly.

Business Rule Maintenance -- Who and How?

[from the audience]: We know that it's important to capture the business rules in a repository, but there's a second part of this job -- their maintenance. What kind of strategy have you used to sell "who's going to maintain it?" and "how is it going to be maintained?"      We all know that a business rule can be put in today and in 15 minutes it can be no longer valid. Could you speak about the strategy of getting the people to actually do the maintenance of the rules once they've been captured?

AS

*/ ?>

We came here looking for this answer too!

Actually, the enterprise group that I moved to is going to be a manager of the repository artifacts. So while we may not entering and updating the business rules themselves, we'll be managing where things are. This is going to involve a lot of people. In fact, it's not just one group; it's a lot of people. We have to get the whole company involved in this.

DC

*/ ?>

In the Policy Charter that we developed on our project, this was actually one of the tactics. The approach that we targeted was to have the business rules from the business point of view worded in a way that was natural for business people. This was to be separate from, of course, the rules that are actually driving the rule engine. The target was to have the business people be responsible for keeping the rules up in RuleSpeak (which we've adopted). This would just become part of their jobs because these are the people who are changing the rules in the business -- making these decisions in this area already. In this way, we have targeted having business "owners" for the business rules.

We still need to work out how this was going to be handed across into the implementation. Issues like how tight a loop with response time (etc.) is going to depend on the technology solution.

GP

*/ ?>

We've done something very similar at Nationwide. Our business partners have an actual team that maintains the English version of the rules. Then my developers take that and program the rules. Getting the business partners to stand up and take ownership of the rules -- to actually form an organization -- has worked out fairly well.

The Scope of Successful Business Rule Projects

[from the audience]: Can any of the members of the panel tell me how wide your success has been? Has it been across an entire enterprise? Or has it been scoped at a particular application?

AS

*/ ?>

We have had success, but we kind of did this initial project on our own because we didn't get the business support -- it kind of "fizzled out." We'd had a lot of change in management and this has really hurt us. As you know, we have completely new CIOs on board in both organizations and with that you get the trickle-down effect. So we had to carry it on our own.

But, yes, we have had success with a business rule approach, and it's going forward. Now the business players (both at Delta and Delta Tech) have realized our project is not just a "project" -- this is "enterprise." So the activity has been moved into an enterprise area. In fact, we are reorganizing (restrategizing) now about how to carry not just the business rule but other components or artifacts that are related.

GP

*/ ?>

At this point, our success has been limited to Personal Lines Automobile insurance. But just this week we're beginning a prototype with Personal Lines Property insurance. The work effort to incorporate that included adding about seven additional classes of data to represent the policy information and simply reusing the underwriting rules classes that we had for automobile insurance. We only had to add in the additional rule elements (or rules) needed for property underwriting.

RH

*/ ?>

In my presentations I talk about a massive rule engine project in Canada. Perhaps you have heard of ISPR, or maybe the Client-Service Delivery Network Redesign? This was a $300 million project to engineer their income security (social security) programs in Canada before Y2K. EDS won it, largely because they pitched a rule engine. However, after this project exceeded $400-500 million, the Government of Canada cancelled it.

That's a massive failure! The government spent over $400 million. On a second try at the system, a lot of the original problems areas were redesigned -- it had been written in PowerBuilder and had not been designed with the Internet in mind. The rewrite provided an Internet front end (etc.). However, the one piece that they did keep from the first project was the rule engine -- the core piece that handled thousands and thousands of rules.

So the work we did with that rule engine -- capturing all those rules -- was not lost. It was kept, and it was actually used as the starting base when they redid the project. And that rewrite finished on time. As a matter of fact, the Veterans' Affairs Department started using the rule engine.

So the point I want to leave you with is that the rule engine really saved them, after wasting so much money on a false start.

GP

*/ ?>

Our situation is extremely similar to that. We've been working on this project for several years. And the first two go-arounds of it died off -- not because of the work we were doing but because of the GUI effort that we were supporting.

First they were looking at a Lotus Notes front end, but they couldn't get the functionality and performance out of Lotus Notes. So that piece died off. Then they looked at a total package rewrite, not only to replace the distribution channel but also to replace the back-end as well. A lot of money was spent -- I'm not at liberty to say how much (I don't think I've ever been told). That project died as well.

Now we're still moving forward. Throughout all that, our project continued to receive funding. We have had to make very few modifications to our interfaces to any of those organizations, as those other projects efforts came and went.

Did I get it??? ~ Summing It Up

[from the audience]: Okay, maybe I'm a little slow, but I think I just now "got it" after 3 days! So, please tell me if I'm right -- because I really want to be able to present this back to our business and technology groups. Here is what I now understand.       You have your business rules repository that the business people pretty much maintain. They put their rules in there, preferably in something close to the way they would naturally talk about their rules, as a part of their job.       But eventually the rules have to get into a rule engine so they can be executed within your application. In most cases right now, the rule engine does not have a direct connection to the repository. So there is a translation that must be done -- primarily by a technical person of some sort, who would actually encode the plain English form that was in your repository.       The only thing that goes into the rule engine are the "must" rules. All the other kinds of rules still need to be recorded -- so the rules of all kinds are maintained in your repository. But only the "musts" go into your rule engine.       Today, in most cases, the rules get embedded into your code, because there may not be connectivity from the engine to the rest of your application. In the perfect world, there would be a direct connection from the rule engine to whatever application, whatever platform you are deploying in. And maybe that may come along sometime. Is that the whole process?

AS

*/ ?>

That's correct, and that's what I want -- that connection between all the pieces. For me the ultimate goal is to be able to have a total rules repository and from it put the rules directly into whatever rule engine or database (or whatever) and have that be a seamless part of the running application. However, today I don't have that. It's not here yet.

GL

*/ ?>

He's got it! So that's a worthwhile trip. And it's a good note to end on.