Originally presented at the 1998 Business Rules Forum, Chicago, Ill. (November 3-5)

Introduction

Gladys: The topic of our panel is "The Business Rules Approach in Practice." We are very fortunate to have five panel members who have experience with this approach and are eager to tell us their experiences.

I'll start off by asking each panel member for some introductory remarks, giving us their top three to five "DOs" and "DON'Ts" on a business rules approach. The trick is to do this in only two minutes! Once the panelists have presented their lists, we will ask them to answer questions from the audience.

DOs and DON'Ts

David: Good afternoon, I am David Plotkin, Senior Data Administrator at Longs Drug Stores. Here is the list of my DOs and DON'Ts.

1. DO capture the rules in a format that can be validated by the business rule owner. This does not usually mean the use of CASE tools or certain other methodologies that shall remain unnamed (but tend to coincide with the last name of famous people). It can mean simply capturing text in Word or Access. It can also mean Use Cases, if you use them (we do).

2. DO capture the motivation behind the rule. You've heard this before. Not only does this educate IS and the business, but it also causes the business people to think about whether the rule still applies or if the rule is based on limitations of the existing system.

3. DO use state transitions to discover rules. Ask questions such as "What are the states we need?" "What causes a transition to occur?" "What rules cause a transition?" and "What rules prevent a transition?"

4. DO use activity diagrams to diagram your rules. Think of activity diagrams as workflows with the policies built-in-not necessarily being visible, but behind-the-scenes nonetheless.

5. DON'T ask permission to do business rules. Just do them. The business user will love you for it. Approach it as simply another piece of information those crazy Data Administrators need. It's amazing what you can get away with when people think you're insane.

Ellen: My name is Ellen Gottesdiener, and I have four DOs.

1. DO secure sponsorship. A sponsor is the person with the authority to make decisions, legitimize the project, and legitimize the business rules. They are the leaders-the ones who are going to define the scope of the project, the scope of the rules, and make high-stakes decisions quickly. They know how to make decisions, get the right resources, and so forth.

2. DO tailor your process and tailor your product to the project that you're doing. Some of the things that I'm talking about by "process" are the techniques that you use to capture your rules. How you are going to capture your rules? Tailor a rule capture tool of some sort-its products would be the models. Which models are important? Dave just mentioned several. Tailor those models-to your project, to your culture, to your team, to your customers. You also need to tailor your business rule grammar; you may have to consider implementation when you do do that tailoring. Finally, tailor how you are going to handle your "ah-ha's!" This is, of course, where your sponsor is going to be very important. You are going to discover, along with your customers, many "ah-ha's!": redundancies, conflicts, things that they can do (the quick hits) that are going to improve business processes, give them competition, or put them in a better defensive position. Know ahead of time how you are going to handle these "ah-ha's!" Work this out in advance with your sponsor.

3. DO build process improvement into your process.

4. DO be prepared for change. Practice organizational change management.

May: I am May Abraham, Head of Knowledge Management, AIG. I have successfully implemented a rules application in production, and I am looking at many more rules applications to start up. I have four DOs and three DON'Ts.

1. DO architecture. Architecture is the key for the successful implementation of rules. What do I mean by that? Organize your rules in manageable chunks. Name your rules properly-unless you do that you will have trouble down the road. Keep the rules architecture with the architecture framework of your system.

2. DO get top-level management support. This is very important. If you want to get going in a rules approach, you need support from your management. I eventually got that by proving myself in a small but important application. From that experience we created the best practices for our business rules approach. We published documentation and we have a center-of-excellence that tells everybody what we are doing.

3. DO build a strategy for the implementation of rules. Once you have the rules, you will ask "how do I implement them?" We had to have a tool to let the applications apply the rules.

4. DO work very closely with the business people. This is very important. Without the involvement of the business people, you will not have the proper requirements.

Here are my DON'Ts:

1. DON'T over-sell the rules process. You will be in trouble if you do that. Only use rules where appropriate.

2. DON'T depend on one platform for your architecture. Your architecture should be flexible enough to integrate with any kind of platform, in any kind of architecture.

3. DON'T distribute your rules without regression testing and a proper verification process.

Jerry: Hello, my name is Jerry Rosenbaum; I consult with clients getting starting on business rules. The first thing you have to know is that business rules are not a silver bullet. Since you are not chasing werewolves and vampires, it's not a wooden stake item.

1. So, first and foremost, DO make sure that people understand that this approach is not the magic answer to the world's problems, let alone their problems. It's just a tool to help you-another tool. And that's part of the problem. We've seen all these great fads that will solve the world's problems, starting way back with Yourdon, and Structured Design and Analysis, moving all the way through the data methodologies. Why should this be any better?

2. Well, we do think it's better. But you DO need to assess the organization when you first introduce business rules. In some organizations you may be able to be "up front" and simply say "Hey, business rules are very important to your cause" and they will start working with them. In other organizations, you meet up with skeptics (or worse), so you do it by subterfuge. Basically, you do all the authorized data models and the process models. Then, off in a corner, you collect business rules and "do something" with them. This "doing something" depends on where the business rules are and how you think you can get something going.

3. For every rule you find, DO ask the basic questions-the famous ones we all heard back in 7th, 8th, or 9th grade: Who, what, when, where, why, and how (the six columns of the Zachman Framework). Ask: "who" applies this rule, "when" is it applied-all the way down to "why" the requirement. You really need to ask these questions. Certainly, if you leave out some you can still succeed, but the more you know, the better.

4. Finally, DO understand the current business practice. You've got to remember that the current business practice is running the business. What do the users do? What do systems do? What do they not do? How do they help you or hurt you? You need to understand what the rules are in these cases today? You can follow this up by asking the question "Where would you like to be?" But you can't get to where you'd like to be unless you first know where you are.

Paul: Good afternoon. I am Paul Mallens, from USoft in The Netherlands.

What can I add to such long and valid list? It seems that the rules community has grown to become a group of professionals who know what to do and how to do it. So, I offer only one primary piece of advice.

1. DO always reflect the situation from the perspective of the customer's need. The analyst needs to ask: "What does he want to achieve?" and "How can I apply rules to help him evolve his business?"

Questions & Answers

Gladys: Thank you, panel members. For the rest of the discussion, I get to play "Oprah"-I wish I got paid like Oprah! I'm going to start the questions off. I will pose a topic (or question) and let the panel members have a chance to answer it. Then I'll open the floor up for two or three audience questions relating to the same topic.

Getting Started

Q: How long did the business rules project take?

David: How long did it take? It took less time than if we had done it any other way.

Ellen: I've been involved in several projects, and each project was different; the length of the period varies. The one I'm working on right now is a "time box"-which is about 2 months. That's why scope is very important.

Jerry: It depends on how many rules you are talking about. If we're talking about only a half dozen rules, and you have to get a rule engine, install and bring it up, and so forth, then of course writing a program is faster. However, if you are doing a project of any size, say a hundred rules or so, there is no way you can program as fast as you can have a rule engine work effectively and implement faster. I would say it is an order of magnitude faster.

Paul: There is, of course, no such thing as a "typical length" for a business rules project. In USoft's experience, business rules are a very effective and compact way to express business logic in order to develop information systems. In practice, one can easily achieve a 50% reduction compared to other ways of specifying systems. We have seen this be realistic in projects up to 5,000 system-level rules.

Q: What kind of a project did you define for your first business rules project? It's sounding like you folks picked, as your pilot project, one that actually would deliver an application to the business, rather than an IS-sponsored pilot to develop a set of rules. Is that correct?

David: That is absolutely correct! At Longs, our first business rules project was a mission-critical retooling of our pharmacy system. In the year and a half that we've been working on it, we have probably exposed 750 rules. And the deliverable for this project is not "business rules." Business rules are simply a tool to get us to the deliverable, which is an operating pharmacy system that turns out accurate prescriptions and fills, to get you healthy.

The Technology for A Business Rules Project

Q: Since you had a mission-critical application that you were trying to develop around business rules, the technology that you were going to use to implement those rules was probably extremely important-for example, selecting a business rule engine, implementing a business rules repository, integrating these rule tools with your current architecture and technical environment, etc. What did you do to make sure that, in your evaluation of the technology alternatives, you selected the things that were really going to work for you? Also, how long did it take before you actually started development?

David: You're not going to like this answer. We did absolutely no evaluation of the technology prior to attempting to focus this project on business rules. We did have a corporate repository in place, but we are using it only in a very limited way. We were developing a methodology for going forward with an object-oriented approach and environment-Forte/Informix relational database engine running on the backend. That was all in place, and none of that changed.

In essence, all we did to make this successful-and I will say, unqualifiedly that it is successful-is to "tweak" the tools that we already were using to enable us to capture the business rules and to ensure that they got organized properly and coded properly-and coded outside of "thin processes."

So, while there was some attention paid to "methodology," in essence all we did was add small pieces to our CASE tool to capture the rules, make sure that our Use Case template enabled us to capture those rules, and go forward from there. There was no gigantic effort, no change in architecture, no nothing. We just went and did it.

Q: One thing surprised me-when each of you listed your Dos and DON'TS, you didn't mention evaluation of technology and the alternatives that are available to us. Nor did you discuss how you went about making sure the solution you picked was the ideal solution, or at least a solution you could make work.

May: One of my roles in AIG was to evaluate the "right tool" for AIG and to make it a standard for AIG. We have chosen Advisor, Neuron Data's product, as our tool. We found it very open, easy to integrate with an application, and easy to be used by business people. Also, we don't have to use a proprietary objects structure in Advisor. It was very flexible for us, so we chose that tool. These were the criteria we had.

David: Remember that we were asked to give you our top three to five DOs and DON'Ts, so I think the answer to your question there is fairly obvious. Yes, tools are important, and we evaluated some (including Paul's tool). However, it's not in the top rung of what you have to consider. At least, that's my opinion.

Ellen: I agree, definitely.

Q: How do you start a business rule engine evaluation project?

May: The first thing you need to determine is: "What are the criteria? What do you want? What does the business need?" Before you pick a tool, you have to understand what your business needs are. If you identify those first, then you can look for the engine. Don't go look for the tool first.

Jerry: You also have to understand your environment very well. How accepting are they of new types of "boxes?" For example, if you select a tool that requires a different type of server, will your organization accept that? What are the boundary conditions they can put on you? They may tell you to find the "best" tool, but if the one you find runs on the wrong platform, you're dead. This happened to me on one project. I located a great tool; it happened to run on Data General equipment. That was great, except the answer was "IBM" and this tool did not run on IBM. Therefore, I lost. From that I learned: Understand your environment! Understand your environment hardware-wise, software-wise, and technology-wise. Make sure the underlying technology it a "fit;" only then will the software you select have a chance of fitting.

David: As an add-on to that: You must also have a "fit" with the skill sets you have available. I was extremely impressed with the USoft tool, but am I going to sit and write SQL? No. However, that's what had to happen if we used that tool, and I didn't have the resources. That basically meant either I was going to have to get someone to do that for me, or we were going to have to look elsewhere.

Paul: As a vendor, I would like to add something to that. From our perspective, it's relatively hard to get business rules technology sold to a customer. Consider the effort we have to spend-to identify the customer, qualify the customer ("Is he serious?" "Does he have a budget?"), and then go sell it to him-it's quite a long distance. So, from our perspective, it would be very good if you would be professional in validating what you need as a potential customer. It's a question of not having the vendors to do the work of the gurus. Please list the criteria for your rules tool evaluation; that would help us. For example, how do you expect a tool to help you in rapid application development? If you don't care about cost, please say so. I've seen it several times. We go in and they say they want productivity. In the end, they decide they don't mind the cost of programming, and they don't buy it.

The Skills and Education

Q: What kind of skills do you look for to carry out business rule capture?

David: You need a good facilitator.

Ellen: You want the people who are too busy or not available. Those are the ones you really need.

David: This is where we have an advantage. We have the absolute "dream" business users, people who have been assigned to the project 100%. These are the ones you need and you just have to have-they expose the rules to you.

Not only that, you have to ask, over and over: "Why do you have this business rule?" "Why do you have this business rule?" "Why do you have this business rule?" There is more than a little people-skill involved in asking questions such as "Why do you do this?" and "Why have you done this for twenty years?" in a non-threatening manner. But that is the information you need, and you have to get it without irritating your business users.

Jerry: You must talk to your business users. And don't just randomly pick them or pick them from the top down. Ask yourself, and other people on your team, "Who are the people we can talk to who are not afraid of their shadow?" Certain business people are afraid of their shadow because they say, "If you do this, it might mean that my job will change, and if my current job is not needed then I will be downsized." You have to watch out for that, and look for people who feel secure-especially as the first people you talk to. Later on, you can talk to the others.

Q: It sounds like many of you have been doing these projects for a while now and you have business rules as an ongoing process. However, I would assume that the first time you implemented the first round of business rules, you went through some learning-for example, it took you some time to evolve the templates and the process. Now that you have been through a rules project three or four times, have you noticed significant gains in the life cycle of the implementation of business rules? Independent of the number of rules gathered, generally speaking do you see that you have been getting progressively faster, and higher in quality, in the implementation of those rules?

May: Definitely things have improved as I go along. Now I have only one production application in place, but I have multiple more in the works. From the first project I learned a lot. From that experience I created a template. The next project is an application that is going to be used in thirty-five countries; it will be in production next year. I am doing things step-by-step. It is very progressive.

Also, it is very important to document and publish what you have learned. You can't keep it to yourself. You have to train people. You have to let people know what your are doing-give them samples.

Ellen: I would like to add to what May is saying-it's really helpful to the team to have metrics around things. We built process metrics around the rule capture. We know in our first 3-day workshop we captured about 35 rules. In the next workshop, on the first day, we were up to 55-that's another 20 rules. The following day we were up to 90 rules. That was 40 rules in one day, and that wasn't even a full, complete day-it was an "8:30 to 2:30 day." So, yes, the group learned. And the metrics are really, really useful so that you can keep improving the process.

David: In addition to the education curve in capturing the rules, we are finding improvements in the education curve in building methods to implement the rules on the service manager objects. We are at the point where it used to take a programmer a week and now they are turning these things around in an hour or less. Literally, they know how to do this stuff. Furthermore, you start to see "patterns"-the same code is getting used over and over again because "Oh, this is a validation-a 'comparison to a value' kind of rule" or "This is two values being compared-it's a 'greater than' rule!" The programmers start to see this, and the code starts to fall into templates, in and of itself.

Paul: Actually, specifying rules is a very natural thing to do-after all, most design techniques require the specification of rules at some level, in some form. I find that the most difficult step for people to make is the shift from linear, step-by-step, thinking to business rules. As business becomes less linear every day-more driven by events from demanding customers-such a mind-shift is one we will have to make for sure!

Q: Do you ever have a conflict in which the business user tells you that the rule is "A" and the IT person tells you that the rule is "B, that's the way the business is run?" How do you resolve that?

Ellen: This is one of those "ah-ha!" moments-something you need to have a process for managing ahead of time. First of all, you have to validate that this is true because, after all, it may not necessarily be true. Hopefully, you will discover this kind of conflict together with the business people since it may require some kind of follow-up. In any case, these are things you do need to anticipate in a process you work out in advance.

Jerry: You also may discover that the program does process "A" (which is absolutely true) and that the business user does indeed do process "B." But what they have not told you is that they are "cheating"-in other words, there are work-arounds. You really have to find out "what on earth" is really happening. What is the system doing? What are the people doing? How are the people getting around the system? Users are often very happy to tell you how they get around the system when they are given a chance to complain about the system-to tell you how bad the system is. In essence, the key is to determine what is the real story and where is this funny work-around resulting in the program doing "A" while the business is doing "B?"

Implementing the Business Rules

Q: Is it your recommendation to implement all rules in a rule engine, or do you have guidelines for distributing rules between applications, rule engines, and databases?

May: I have set up some guidelines. I do not say "put all the rules in the rule engine." This is especially true when you are just starting. In the beginning stages I would not recommend that anyone put all the rules in the rule engine. Do it step by step.

I approached it this way: I separated out the complex rules-set them aside-and did the data validation rules first. After that, I tackled the qualification rules (and things like that). It is really important that you identify the elements most crucial for your application. Do not attempt to put all the rules in the rule engine; that is not a good idea.

David: I'll go along with that. We basically have two classes of rules. On the one hand, we have the rules we've coded that are fired by methods that sit on these manager objects that watch for things to happen. But at a simpler level, an awful lot of the rules that fire in a pharmacy are really database-level rules and really lend themselves to operating at the trigger level. For example, rules of the type where something has to happen automatically every time you create this new record-where every time you update this record, this has to happen. These are the simple cases, in which you can essentially isolate the change to a single row or to a simple set of rows where a simple WHERE clause will find them for you. These kinds of thing really lend themselves to being done at the database level.

Now, of course, you want these kinds of rules to be the ones you don't expect to change very often. The trigger rules should be the very simple ones such as: Whenever I update this record I want this column to carry the new system date. We would do that with a trigger. Yes, it is, in fact, a business rule-a very system-oriented one. Typically, I would not want to implement things that are likely to change from a business standpoint as a pile of triggers-mainly because that it makes it very hard to maintain. On the other hand, if you know where the rules are being implemented-in which triggers-you at least know where to start looking.

May: The transaction-intensive rules should be in the database-not on the rule engine side. That is today. Down the road, you may be able to implement these elsewhere, but don't do it in the first stage. I didn't.

Jerry: Remember, DBAs love triggers (and stored procedures). You don't want the DBAs upset. You have enough battles with the DBA as it is; you do not need more battles with them. Cooperate with them; give them a whole bunch of the rules sitting in a database. Just make sure you get a few of the rules so you can show them how this "rule thing" works. Eventually they will come over to your side.

Paul: I just gave a presentation to the DATABASE Club. The members of this club know the answer very well: "Rules belong in the database! Otherwise, they will get broken somehow." Our viewpoint, however, is that rules belong in a rules layer and that it should be fully transparent where the rules are executed. In practice we know that firing the rules when you "hit" the database is too late. Usually it's best to be as close as possible to the user because the user wants feedback as fast as possible. However, burying the rules in the windows-layer is no option. There are too many replications then, and they are hard to manage. Separate layering and automatic firing is the best.

Ellen: From a project management point of view, regardless of the technology you're using, you may find (as we have on our current project) that there are various "levels" of rule enforcement. Furthermore, the rules apply at various levels. For example, that level could be a jurisdiction level, role level, and so forth. In the project we are working on now, we are capturing the action for the rule. From an implementation point of view, the plan is, first, to implement the "must" rules-the things that always must happen. Then we will tackle the more complex, heuristic-based rules. We plan to handle these a little bit differently, and later on.

Jerry: Another key issue you have to watch out for is that this is not an all-or-nothing world. If you mandate "Everything has to be in the rule engine," I think that's what is described as a "nuclear event." You will die. It will not work. You will have wonderful failures and then that will prove to everybody that rules clearly don't work. There are too many unforeseen things-things you haven't even thought about. Therefore, the better approach (in virtually every technology, not just business rules) is to come up with a slow migration path, one that's logical to your business. In the business rules world that means: Do some of the rules. Pick ones that you are sure will be quite successful first. And then start venturing out from there.

The guidelines these other people have given you are very good guidelines for what to pick first. Just make sure that, even if everything falls into that first category, you don't pick everything. Take just a selected subset. This will let people start saying "Well, gee, if you do this in rules it will cost us only X dollars." This is especially true if the rules change a lot-people will contrast this with things that were programmed-things that both took a bit longer and cost a fortune to change. Over time, people will start to see why rules should become more important.

Q: Can we implement business rules without a rule engine? If so, how?

David: Well, sure. Obviously this can be done because we have implemented rules and we are not using a rule engine.

Jerry: Business rules can be implemented in all sorts of environments. I had the opportunity (much to the chagrin of several people in the IS department) to demonstrate that you actually could implement rules in COBOL on the mainframe-providing you have programmers who approach the task with some intelligence. You cannot expect to do this with, say, report writer "coders." If you have real programmers you can do rules in COBOL on the mainframe-and it works.

May: Some other alternatives: You could implement the rules as modules in applications, or as object structures. You could use "home-grown" technology approaches, then slowly migrate the rules into another technology down the road.

Ellen: There are triggers in databases. In a development environment such as Forte you can use "service manager classes" that manage the implementation of the rules.

David: Finally, when rules are implemented outside of the automated system, we call this "best practices."

Q: Do you have a recommendation for a method (a process) for moving from requirements into technical design and on into the actual implementation of rules?

May: Here is my experience: We have created templates, from scratch, for doing all the processes-from defining the objects (putting them into Rational Rose), then on to doing the analysis. We have defined rule analysis templates. We have also defined rule integration templates, for integrating the rules with the applications. In other words, this addresses: "Once I do all those rules, how do I integrate them into the application?" The application developers need to be able to integrate the rules easily into their systems so we created a template for this. This lets us hand things over to a developer and say "Go use the rule engine." Finally, once the rules are in production, how do you maintain them? I need to have a template for rules implementation as well, but I'm only just preparing this now.

All these frameworks have to be established. Then, you have to publish them in a place where everybody can access them. We publish a lot of documentation: We have to educate people; we have to promote what business rules are to the people who don't know about this yet. This is key.

Ellen: I think May's point about "templates" is extremely important. We are doing a similar kind of thing-we've designed templates for capturing the rules with business people, and those map pretty directly to business objects. This way, we can have the architects, the business modelers, and the IT people (who understand the data and the objects) all participating in the workshops. They are able to do the mapping pretty well.

Another observation that I would make is that it is critical to have the designers participate in the discovery and validation process. This will make them better architects. In some of the environments that I've been involved in, we have worked with Forte designers (such as Dave's shop). On another project, the designers will be using C++, Java and a Sybase backend database. It's not the technology that matters; it's having a good design.

Jerry: Another thing you have to watch out for as you move into implementation is the programmer who wants to "tune" things. You may have a great design, with all the rules put together very well. And then some programmer says "I don't care for this. I think I can do this better if I wrote the rules in ..." their favorite language, of course! This will happen. You have to keep a very sharp eye out, and you have to educate these people-either by "real" education or with a 2x4.

David: I'm going to agree both with Ellen and with Jerry. I believe very strongly that your developers need to be in on the exposure of the rules so that they can understand where these rules are coming from.

We too are capturing the rules using a template. Once the rules have been exposed, we map them to the business events that trigger or evaluate those rules. From there we map to the system events-the create, update, delete events. We break out the rules and code them separately, as separate methods, either attached to business objects (as we originally did) or (more recently) to what are called "manager" class objects in Forte. Using these manager class objects, you can, essentially, have objects that "watch" for things to happen at a higher level and trigger things as necessary. If you've mapped your system events to the rule methods (the methods that fire the rules, that actually do the evaluation and stuff the databases with the appropriate values) then Forte really lends itself.

Since we are exclusively a Forte shop, there is not going to be any "favorite" language being used. The project manager carries around a very large 2x4 that she calls "the persuader." It's actually painted pink and has a handle on one end labeled "the API" because that's how she communicates if she needs to.

May: One more thing about the life cycle. In most cases when you are doing business rule applications, you don't have all the rules initially. So what do you do? What I did was: I defined the process and I classified the rules. This let me know, "These are the type of rules I am going to get"" I classified and organized the rules that I had initially and they became part of the production application. Now, after the system has gone live, we are getting more rules. We are being asked, "How do I add this rule?" You need to have a mechanism in place to add new rules. That's one of the key benefits I could prove. We could easily add new products. When the system was first established we had only five or six rules, but now we have more. How would we do this without a rule-based approach? I do not know how people used to do it.

Jerry: Program!

Q: Do you distinguish between simply "recording" the rules vs. "executing" them in the system? How about the rules that are "outside" the automated system-those followed by the business people. You cannot really "drive" the actors because they are external players.

Jerry: Let me take an example. I recently had to analyze rules for managing contracts at a foundation that works with behavior problem students from the various school systems. In all, they have about 1500 contracts that they get from the various agencies they deal with. Most of the rules about handling these contracts are very straight-forward. We expect to see certain things in any contract. For these kinds of thing, the rules are straight-forward: As you analyze the contract, make sure things are there and make sure the values are reasonable.

But sometimes you run into "off the wall" things that just show up in a contract and you have no clue what they mean. In this case, the only rule you can tell the person is, "If you see something interesting give the contract to someone to check into." For example, one of the recent contracts said that the agency had to comply with the Clean Water and Air Act. This was part of the contract because, for that particular agency, in that particular jurisdiction, this was required wording in all their contracts. So, fine-but knowing that, somebody still must sit down and figure out if this actually means something to us. That's a very people-focused process-we could never automate that part of the rules. For another example, in an insurance claims system you might say ,"Standard claims are handled by this set of rules" (automated). 

Assessing the Business Cost of A Business Rule

Q: Has anyone been able to attach cost/benefits to rules? Specifically capturing how much would it cost to enforce (or not enforce) a rule.

Ellen: I've been involved in a multi-year project on which they did a cost-benefit analysis using the EVA (Economic Value Added) model. The goals of this project were to standardize business rules-the structural rules in manufacturing systems globally-across 140 applications. Their EVA was $180,000,000 over a 12 year period.

Q: (clarification): I wasn't talking about total project, just for an individual rule. This would be something closer to analyzing a rule's potential life cycle before I decide to put it in place. I might consider things such as: "If I enforce this role, will I get some payback?" "How much will it cost me?" and "What do I gain, in terms of opportunities?"

David: If go to the individual rule level, I don't think you can really attach a meaningful cost, certainly not in our system. Many are things that are intangible-if we don't enforce this rule it's going to take us slightly longer to fill a prescription. Certainly, we could put a cost on that but is it worth the effort to do so? Of course, obeying regulatory rule is a "big ticket." If I'm not compliant, that could cost me $150,000 a year.

May: I was helping to write a business case for one of the business units. We had a tough time writing the business case because we could not come up with any numbers. So what I did was to get the maintenance cost they used to have on the old (current) system and I compared that to the new (proposed) system.

Q: (Clarification): My question relates to the cost of the decision about a rule, one way or the other, not about the cost of automating its execution.

Jerry: There are two questions you might be asking, and I'm not sure which one it is: One question is: "What is the business cost of having (or not having) the rule?" period, based on business issues. The second question has to do with the cost of implementing and maintaining the rule by a rule engine vs. by a program. I think you are asking about the former.

Assessing the Technical Cost of a Business Rule

Q: I am interested in the second aspect of Jerry's question. Are any of you familiar with any publication, or have you published anything yourself, that shows the cost of using a business rules approach-whether it is just for analysis, or all the way through to implementation-as opposed to not using a business rules approach?

Jerry: Let me give you a simple example that's a little unfair because it happens to be insurance underwriting. I say this is unfair because insurance underwriting has always been rule-based, period. An example of a rule could be: If the driver had more than 3 accidents or more than 7 speeding tickets then classify the driver as "high risk."

Since they have always known about rules, the question quickly moved to ,"What would it cost to program as just 'normal programming' versus using a rule engine?" The factors we looked at were, on the programming side, the effort to set up the database with all the parameters, coding the parameters, and writing programs against those parameters. On the rule engine side, we have the effort to set up the rule engine and then the effort to implement the rules in the engine.

We found approximately a two to one advantage in setting up the rule engine first and using it to implement the rules. Note that this ratio does not include the rules maintenance cost, which itself is a tremendous saving. Our savings of two-to-one was just for putting the rules out in the first place.

Business Rules and OO

Q: Is object-oriented analysis "good" or "bad" for business rules?

Paul: I think that business rules will soon be taken over by UML-adepts as one of their prime issues. Coordinating rules between objects is causing complex messaging which they won't to be able to manage from the components-viewpoint. The OO people will soon make business rules their issue. They need to solve the coordination issue between business rules, but they are doing it from a technology perspective. That is a flaw in the business rules effort: We are not succeeding in convincing these people to take more of a business perspective.

Jerry: A very big issue in object-oriented analysis and design is: How much do your designers and analysts believe in the concept of encapsulation? If they are 100% true believers that everything is encapsulated, the best thing you can do is offer them your condolences and come back in a couple of years. By then, they will have another project underway to solve the problems they are creating. On the other hand, if your OO people understand that certain things must be shared-"minor" things like data-then you have a chance with them. Those same people will soon discover that rules also have to be shared-because rules are not the responsibility of any single object; they are shared between objects. So the big question about OO is do you have people who believe in 100% encapsulation, or can they break that mold. Those who believe in breaking the mold have no problem in dealing properly with data, no problem in dealing proper

Ellen: I'm discovering that a lot of people in the object-oriented community really "get it" with business rules and recognize the weakness of distributing responsibilities across a large number of objects. They also "get it" that managing the rules and knowing where the rules are is an important issue. Following some of the things going on with the UML, I see a start, but it's really at the end of things with the Object Constraint Language (OCL). This is based on predicate logic, so that's definitely not something you're going to ask your customers to write or look at! Just like all methodologies, you have to expect things to start to develop toward the end of the life cycle and eventually move forward. I am encouraged; I think that there are some developments in the object-oriented community where that is going to start to happen, but it will take time.

© 1998, Keri Anderson Healy