Panelists

AM = Art Moore, Knowledge Partners Inc. (KPI)

BO'N = Bonnie O'Neil, Westridge Consulting

CN = Claudina Nevis, CA Dept. of Motor Vehicles

DC = Donald Chapin, Business Semantics, Ltd.

GP = Gary Perkerwicz, Alliant TechSystems

KS = Kristen Seer, Business Rule Solutions, LLC

TY = Tom Yancheck, UPS

Moderator

GL = Gladys S.W. Lam, Business Rule Solutions, LLC

Introductions

[GL]: Welcome to the Practitioner's Panel. This is the audience participation part of the program. This year, we have two panels set up. This afternoon's is the first, and the theme for this panel discussion is "The DOs and DON'Ts of Business Rules." The second one will be on Thursday, and it is what we are calling the Gurus' Panel. So any question you don't get answered tonight -- or if you have really hard questions -- save them for the Gurus' Panel.      I'm very excited! Over the last few months I have recruited seven very fine panelists. They have vast experience in the business rules area.      Today's program is divided into three sections: At the beginning I'm going to ask the panelists to introduce themselves, to give a little background about themselves, and to talk about what tools they have used. I've asked each of them to then give some of their "DOs" and "DON'Ts" about business rule projects. Then, just in case you're shy, I'm going to start off with a few questions, just to get the conversation going. At that point, feel free to jump in with your own questions!      The purpose of this panel session is so that we can learn from each other. As I present … as I go from client to client, I always learn as much from them as they do from me. This is a good forum to do that, and I encourage all of you to participate.      Okay, shall we start? Bonnie?

BO'N

I'm Bonnie O'Neil, and I've been in the business rule area -- working with business rules -- since about 1988-1989. I worked for two database vendors, and one of those vendors used to advertise in our literature that we supported business rules in the database. One day one of my clients said, "You don't support business rules in the database!" And I said, "Oh, we don't? It says in our literature that we do." But then I went digging and figured out what a business rule really was. This got me 'hooked' and I couldn't stop. So I left the database vendor and went to work for consulting firms -- going out and actually doing business rule work. I was 'hooked'! I thought it was great

     The kinds of technology … I've really done a lot of home-grown stuff. I use COTS (Commercial Off The Shelf) tools when I can find them, but a lot of times the tools that I find don't do exactly what I want them to do so I end up extending them. Right now I use a lot of little 'baby' PC tools -- I use InfoSelect, which is a bibliographic database, and it is very interesting. I use BRS RuleTrack and I like it very much; however I have extended it a little bit by creating some auxiliary tables to do what I need it to do. That's pretty much the stuff I'm into now, in terms of tools. I have not used a business rule engine, just because it hasn't to fit into the kinds of projects that I've been working on.

     "DOs" and "DON'Ts" ... I would say that validation of business rules can be very, very tricky. One of the things that we were very successful with on a recent project is the use of an interactive, online forum that was both web based and internal Lotus Notes based, hooked into their email system. That gave our geographically distributed users the ability to communicate and to comment on each others' comments and to comment on the business rules in an interactive fashion. Then we had face-to-face meetings to back it up. That was very, very successful, so I would say that that's a big "DO" -- something to try to do.

     As for my "DON'Ts" ... I would say that it's important to understand that business rules that aren't hooked to anything won't be maintained. This is the biggest problem that I've seen. If you don't hook the business rules to a system then they don't have a really long life. As a consultant I go out and I gather business rules for a customer, but if they are "just there" where I put them then they don't live past the time of my tenure. That's why I am very, very active in looking for tools that enable us to hook the rules to real-world, working systems.

TY

My name is Tom Yancheck. I work for UPS, and I've had something of a career change. After about 24 years on the applications side -- going from being a programmer, up through the ranks of data administration, database design, DBA, project leader of application development -- I jumped over the fence and I became a person on the user side. My function is to drive the requirements for UPS' package billing system. I drive the applications people crazy with requirements; I make their life miserable. We have two releases a year, and where business rules come into play is in 'friendly conversations' with the applications people. In other words, I talk about 'rules' and they tell me what the code does. I have to believe that the founder of UPS, Jim Casey, did not start the company back in 1908 with three major applications under his wing in Seattle, Washington! It was a business. Therefore, the word "business rules" comes into play. So I architect a lot of what goes on as far as driving the requirements.

     As for business rule engines, I am probably a vendor's 'dream date'; I have not used one. The closest we came to one was a tool from my DBA days called Cayenne, which is now what "Cool" is -- Cool Products, CoolDBA. Yes, there are a couple of (what I call) 'renegade' initiatives in the company that we are trying to corral -- initiatives where people are independently looking at business rule engines. We are trying to bring those under one umbrella so that we can all talk about a business rule with the same voice. It is amazing how business rules can contradict each other, with UPS people all over the country talking about the same thing but they appear to be talking (almost) in different languages. I call it the 'Tower of Babel.' So for rule technology there is actually very little in place, and what there is is mostly home-grown. But we have had one success with it.

     What would I "DO" and what would I "NOT DO"? I would be very flexible. I would be persistent. But I would not be a 'pain in the back' as far as trying to get the user community to adopt 'rules.' First, you have to convince them that business rules are important, that they drive the business. And to do this -- to find out how the business rules work -- you need to find out things from the business people; you need to speak their language.

     It is kind of unfortunate that the applications folks (and I am sure that there are a lot of applications people that I'm speaking to here) believe that they understand the business (and that's good!). But the business did come first, and the business rules and how the business rules drive the business are most important, even on the applications side. After all, those people who get called at two o'clock in the morning sometimes get called because a business rule is not being enforced properly.

     DON'T ever over-estimate the benefit of a business rule engine, a business rule approach, why you need to do rule books. Yes, do it, but don't overstate it. I've seen users literally throw people out of their offices because of that -- they did not want to hear it. They consider it to be the 'happy thought of the week.'

KS

My name is Kristen Seer, and I am a senior consultant with Business Rule Solutions. My background ... I have done a lot of data management work, but I have always been involved with business rules, even though I didn't know at the time that they were called 'business rules.' I remember that, in my data management days, I used to build these wonderful data models -- all the nice diagrams, with no lines crossing in the diagrams, great definitions, and all of that. And I also kept a list of all the 'left over stuff' that I needed to put somewhere -- a bunch of English language 'stuff.' When I used to review this with the business clients, I would be proud of my diagram, but they would be all over that list -- THAT was what they were interested in. So even back then, I knew there was something with this 'stuff' over here on the side, even though I didn't really know what it was.

     Over time, I became very interested in the business rule area, and I started working with Gladys and Ron in Business Rule Solutions a little over a year ago. With them, I have been focused on a combination of training and mentoring of business analysts -- to take business people and turn them into real business analysts. I have also been working on actual practical application of business rules -- doing a lot of business modeling with a number of clients to help them to discover their business rules and to build a full business model with workflow, fact models, and so on.

     I have used a number of tools. Some of the clients only have Word and Visio, so you go with that. But my preferred tool right now is the Ptech Framework, with the Business Rules Accelerator. I have been using that quite extensively and find it to be quite a good tool.

     Like the other panelists so far, I have had absolutely no experience with business rule engines. I am really intrigued by them, and I believe that you won't get the full benefit from the whole business rules approach unless you do use a business rule engine. So I'm quite excited about the prospect of that technology, but I am a real newbie in that area.

     In terms of "DOs" and "DON'Ts" ... one of the things I have found in building a business model is that you really have to be consistent and rigorous with the terminology in the syntax of the business rule. When you begin to do business rules, you should set up some kind of framework for how you are going to express your business rules. We have RuleSpeak as our structure; it is very simple and you can construct your sentences in a particular way. It helps ensure that you use the same terminology throughout, so that you aren't calling something a "purchase order" in one place and a "purchase requisition" in another. It does take a lot of work -- it's not easy to do -- but the benefit is there when you go on to maintain things. So I think that is my biggest "DO" -- make sure you have that rigor.

GP

I am Gary Perkerwicz from Alliant TechSystems. One of the things that I like about business rules in general is this whole idea of definition of terms. The definition of terms is really important. Like Kristen, I've been doing business rules since before they were 'cool.' I've been involved as a programmer, basically a developer for twenty years, involved with business rules that were expressed implicitly, in other words, not explicitly recognized as being 'business rules.'

     On tools ... Alliant TechSystems is a defense contractor. We have been using the Business Rules Accelerator for about a year. This Ptech product was introduced at the Forum last November and I believe we were the first ones to use it. So some of our experience has been with that tool.

     In terms of my "DOs" and "DON'Ts" ... what I would say, from our experience with getting people involved in business rules, is to, yes, do a business rule project. Just don't tell them that's what you are doing. That is to say, try to incorporate all of these concepts and principles in the natural, organic life cycle of a existing projects and initiatives. And for the existing projects and initiatives, use them as opportunities to inform people -- to shape their vocabulary and introduce

CN

I am Claudina Nevis, and I am a project manager for the State of California, specifically for the Department of Motor Vehicles. My last big project was the Y2K effort for the entire state, and it was a success. Then, about a year ago, the DMV asked me to do a project to work the rules used to compute the fees collected by our department, which is a big part of the State budget -- about $20 billion. This focus of this project was the rules that are applied to collect those dollars and to consolidate this subsystem, so that we would no longer have four or five solutions, on four or five different platforms, supported by twenty or thirty people who interpret the regulations in the vehicle code, along with our policy folks who put this all together. We needed to come up with one solution. My experience with business rules is a consequence of that assignment.

     I actually inherited this project from a consultant who had worked on it for a year with little input from the business people and the IT organization. Soon I realized that we needed to treat this as a project with a lot of input from the customer. By the way, because the rules are changed very often, one of the objectives of the project was that customers (the program folks) would be able to go in and actually modify the rules. And this is a highly political issue; it produces revenue for the State, and even local governments, with regulations that impact the fees that we collect changing on a yearly basis.

     I put together a very small team but a very successful team. We then selected technology. We are using RuleTrack to manage the business rules. We have selected the Blaze Advisor from FairIsaac rules engine. We broke the project into 3 phases, and we have completed the first phase. So we have gone from nothing (from a lot of legacy code and a lot of legacy systems) to having a portion of the business implemented: the business rules documented in RuleTrack and the rules coded and executing in the Blaze product. And, by the way, we are doing this and also interfacing our solution with existing legacy systems.

     My "DOs" and the "DON'Ts" ... I have a lot of "DOs"! Number one: if you are going to do a project -- any project but especially one with business rules -- you really do need to have a good sponsor. I have been really lucky; I have two sponsors. I have a technical sponsor, and I have a business sponsor. This is a must.

     My number two "DO" ... if you are going to use new technology, do a 'proof of concept.' Select a vendor that you can partner with and who will help you out. These are new technologies, and you will need all the help that you can get. So having a business partner in the vendors that you select is really important.

     Number three "DO" ... ensure that you have a tool to manage the business rules that you harvest. We started out doing this with Word, and soon we found that we could not stay on that path. That is when we selected the RuleTrack solution.

     For the "DON'Ts" ... my biggest "DON'T" is: don't think that you can get your business rules out of the existing legacy systems if that is where they are. Reverse engineering does not give you business rules! You want to get business rules from the business people. That is a must.

     My number two "DON'T" is: if you are going to take on a project like this, ensure that you have a high-performing team. I was very lucky that I was able to assemble my team without a 'storming' phase. We went right into a 'high-performing' environment. I think that is the reason for the success that we've had.

DC

I am Donald Chapin, and I'm an independent consultant based in London. My company name is Business Semantics, Ltd. I've spent my whole career working with business people, helping them communicate what they want their systems to do, as opposed to working on how the systems are going to do that.

     Back at the beginning, in some of the internal tools I used at IBM, we were calling these 'derivations' and 'validation rules' and things like that. But the more recent business rules projects I've been working on have been customer focused. One project was a classic 'let's make a deal' project (such as Ron talks about in his tutorials) with quite a sophisticated management approach as to what deals could be offered, what deals were offered, and then the implementation and tracking of that and the feeding back into the cycle "did that deal work?" That project was very rules-intensive. Its first phase is just going into production in this timeframe. It didn't use a rules engine, but it did use a data-driven rules approach where the users could change the parameters of the rules. Another project I've just begun to be involved with is related to customer information and providing a single source of data for customers and tying that in with the various legacy systems.

     The tools we worked with … on the business side, we used RuleTrack combined with Microsoft's Object Role Modeling tool, and then a proprietary tool to tie those two together. On the implementation side, we used USoft some for prototyping, and we used RuleSpeak, mapping the RuleSpeak rules to the USoft rules. We found this to be quite a close, one-to-one mapping.

     My recommendations (my "DOs" and "DON'Ts") ... first, always write your definitions as you go, right then and there. Don't miss them -- it is so easy not to take the trouble to get people to express the definition of every term they are talking about. Just get it up on the wall. Get it captured as you go. And also get it into some tool right away.

     Secondly, I think it's really important that you tie the terms, along with the facts that the rules are expressed based on, to your data model in some way. Otherwise you're going to have a big disconnect between your rules in RuleSpeak (or plain English or whatever approach you use on the business side) and mapping them on the solution side. But if you have tied the terms and facts that you use in the rules on the business side, map that to your database (or your object model, depending on the approach you are using) then you have a lessened chance of that disconnect when you get over on the IT side.

AM

I'm Art Moore from Knowledge Partners Incorporated (KPI), founded by Barbara von Halle who is the President. I've been in information architecture for longer than I care to say. I have worked with Barbara for a good deal of time, which a number of us in the Company have. The areas where we've been involved in 'rule' projects would include: business rule mining from legacy code, business rule capture and analysis, business rule methodology improvement, business rule training, and some custom repository development.

     In the area of tools to support this work, we have primarily done custom repository work. One of those cases involved making some extension of System Architect. In the business rule mining area, we've worked with a number of different vendors that you don't see here -- Seek, Relativity, Netron, and Pie Technologies. We have worked a little bit with a couple of the rule vendors on some projects.

     The big "DO" I would suggest … you want to get business rules going that solve a business problem, which I think echoes some of the things said here already. By that I mean that you don't try to sell 'rules' per se; you try to solve a business problem for a business sponsor. The "DON'T" side of that is … don't try to sell rules "because they are good for you" -- you know, that familiar of 'data management' approach!

     There is another aspect of this "DO" and "DON'T" that is in terms of the methodology work. If you are going in to improve the methodology in general, don't approach their 'methodology improvement' activity with a "'rules' is the newest silver bullet for everything" attitude. We have had experience not doing it well this way, and then changing and doing it better another way. Instead, present the approach that "'rules' is the missing piece that hasn't been addressed before." In other words, whatever the methodology framework being used, you are adding rules to it -- to enhance it -- as opposed to trying to sell it like it is the latest and greatest thing. There have been too many sad stories about that.

---

GL

Okay. That concludes 'section one' of the panel discussion. Now, for the 'part two': I will begin with one or two of my own questions. Then I anticipate that there will be a lot of audience participation. Feel free to direct your question to any specific panelist where you see the specific question is on their expertise. Okay -- fair?

Getting started on a 'business rules' project

[GL]: Question number one. I get this in our seminars and also last year at the Forum -- this question comes up all the time: Within the organizations you work with, how does a business rules project get started? Do people just come in one day and say "Let's do business rules! We really like it!!" … or do you see a pragmatic approach? What are your recommendations?

BO'N

I agree with Art. I think that a business rules project is not a 'business rules' project per se. I do a lot of data warehousing work and data migration work and data quality work -- those are my three primary areas of work-- and in the process of that work I capture business rules. To me, business rules have always been a means to an end -- I always capture them, and I always put them in a database, even if it's my own home-grown database. Like Art I have also built my own custom repository when I didn't have one to work with. I am thrilled that RuleTrack is around so I can just pop it in a COTS tool -- that's really a nice thing. But I think that you don't really go out to do a 'business rules' project; business rules are a means to an end.

AM

I would certainly agree with that. I think Art was right when he said that!

[from the audience]

I would be interested to hear more from the business people as far as your response to this first question. What we've heard is more from the technicalside. So, I'd like to hear about the initiation of a 'business rule' type project from the business management folks who are here.

TY

Since I'm a defector from the applications side, I can speak for both sides. And I can say that I never really worked on a 'business rule' project. No one ever came in and said to me, "Go out an do a business rule project." (with the exception of one that was a prototype to prove that there are business rules out there). Every project or every requirement or every initiative that we undertake in my organization has some business focus.

     In fact, in my opinion we need to downplay this more than we do. There are 51 business analysts who, twice a year, go and talk to my peers and my counterparts and ask the same (excuse me!) damn questions over and over: They ask, "Can you tell me what the rules are?" and "Can you tell me how this works?" From a business perspective, this is the last thing you'd want to do to some people. I was explaining to someone just today ... I have a gentleman that I cannot send people to any more. There are skulls and crossbones lying outside his office; you cannot go see him -- there's just no way. If you do, I will get a phone call within 5 minutes, telling me, "Don't send that person to me again!" And, you know, in some ways he has a point! You're saying, "You're asking me the same thing over and over -- cut it out!" It comes down to rule management; it comes down to the rule book; it comes down to knowing the process. But unfortunately we are fighting the problem of understanding the business -- business and applications people -- who knows better?

     I go through this every day. I am the champion of business rules at UPS. I have been fighting -- no, I can't say I'm 'fighting' any more -- I have been pushing and have successfully gotten us to a certain point. I think we can move forward from there, but we have to educate everybody. But in these tough economic times, I can't go through the contintual re-education process that's needed.

     People at work are telling me -- and it's a great 'UPS-ism'-- it's "partner, you're taking money out of my pocket!" Your asking me the same question ia like asking a driver to go to the same address and deliver the same package, every day -- over and over and over. We might be doing it by mistake -- not intentionally -- but that is in effect what we're doing by having people go to the business people and constantly asking those same questions.

GL

So are you saying a business rule approach will solve some of that?

TY

It's starting to do that now because I actually can see Klaus in the hall and have a conversation with him.

GL

And did you start labeling the project of collecting this information a 'business rule' type project, or is it just a project of understanding?

TY

'Business rules' was always part of the business initiative. There was always a business opportunity, a product definition, something that was being introduced to the business.

     Basically, I look at each project as having three components: there's a consumption of data, there's a process that consumes the data, and there are business rules that enforce what goes on. All of those intermix somehow.

Any bold thinkers out there?

[from the audience]: I know the panel has said, "Be careful; don't just do business rules for business rules' sake." But what if you wanted to be very ambitious and you actually wanted to go into an organization and say, "Look! I think business rules are really important. It's going to impact your system development life cycle; it's going to cause you to change your way of doing business." Is there any indication that there are organizations out there that are that ambitious -- that are thinking about things in this way? Is there maybe a top executive or some highly-placed person who is saying, "Look -- this has got to be more than just providing incremental value in projects that we do every day." Any big thinkers out there?

CN

I'll share with you my experience. The project that I'm doing is not known as a 'business rule' project. It's just a project to improve the maintenance of the business rules.

     However, I have to say that the customers that are on my team (and I have a team that is very customer-centric) -- the customers really believe in this now. They have been with the project from the beginning; they participated in the proof-of-concept and the selection of the products that we are using. When it came to training, I included them in the training. They came to 'see what it's like;' and they loved it! And I have to say, they were able to perform as well as the technical folks that I had. They are now real believers.

     As a matter of fact, one of them has moved on to a new job that is not in this program any more. She accepted the job on the condition that she would still continue to participate, because she really believes that there is a future in what we are doing. So I think that the success is that the customers realize the value and that they are involved from the beginning.

Can you get 'rules' from the legacy system?

[from the audience]: My question is directed to Claudina and to Art -- something that you each said. Claudina said, "Don't go to your legacy system source code to get your business rules." And Art said, "You can get the rules from the source code." Our organization deals with legacy systems that were built long before even Structured Analysis came out! I'm wanting to hedge my bets -- I'm thinking I'm going to find the business rules in the source code.

CN

You have to go to the legacy system to get some of your 'technical' rules (the 'electronic' rules -- however you'd like to call them). These rules are in the legacy systems that have been around for thirty years. These rules get changed every year. The rules are very complex. As a matter of fact, I was told, time and time again, "We can't put this into a rules engine because it is so complex. We have to keep it in a procedural language."

     Having the technical reference that you get out of the reverse engineering you do is good to have, but I tried -- the first time -- to have this extracted and presented to the customers so that they could buy off on what I was calling the 'business rules.' But that didn't work at all.

     And so what we're doing now is we're having the business people actually develop the business rules. They went onto the web; they did a lot of research and they came up with a process of documenting. It probably does not follow Ron's discipline but it works for them, which I think is the important thing.

     So having the 'technical' rules documented is good as a reference, but it can also limit you if you are trying to put things into a rules engine. You have to be careful and use it as a reference.

BO'N

I find that analyzing the data from the legacy systems has been very important to us. We've used tools like EvokeAxio to go out and analyze the data. On the last project, though, we did have someone sift through the code and gather all the edit rules. So we have done that as well. But I find that analyzing actual data is extremely helpful.

AM

I would answer it in two parts. First, in the way we have designed our approach to rule mining, you are certainly well-advised to narrow your target. You will find out (these are not statistically hard numbers -- they are the empirical numbers that we've gotten so far) that, out of all the code, maybe 35% of the code really contains rules. And out of that code, if you do some initially 'archeology' (as we call it), you can narrow that focus even more. And then in that area of code you'll find out that there's only 10-35% of the attributes that are really the key ones of interest to you. So it may be appropriate to apply rule mining techniques only to a small portion of the system.

     My second point is that, although the tools can be good, you do have to be careful in the way that rule mining is sold by the vendors. You will find that some are selling not just rule mining but re-engineering. Their target in doing that is, in some cases, to say, "You don't have to look at it all; we're just going to take it from here, wrapper it, and put it into new technology." And in doing that, as was pointed out earlier, you don't really discover what's in there. The output you get is, in some cases, just a way to slice the code, to be able to put an object wrapper around it, and to put it into another technology architecture. So in that case, you haven't really uncovered anything from a logical perspective.

     If you can narrow the target to a core area, then you can apply a combination of tools. You can do mining from the legacy along with some work on the other end, to abstract that up so it's actually something that the business can validate. That can be useful. But you have to apply it with some judgment, obviously.

KS

I'm going to take a bit of a devil's advocate point of view and give an opposite opinion -- to stir up some controversy here. When we go into a client, we tend to only look at as much of the as-is scenario to give us a basic understanding of the business and to identify their current problem.

     We really do not spend a lot of time on the as-is. We like to keep the clients focused on the to-be of the future vision. This is because we have found that sometimes the clients just get too bogged down on the way it is, and you do get stuck with some of these artifacts and things that you're only doing now because you are constrained by the technology that was used at the time, or the particular regulation that was in place which no longer applies.

     So we tend not to spend a whole lot of time on the as-is -- we focus them on the to-be.

Any other legacy considerations?

[from the audience]: To Claudina ... on the motor vehicle tax system, if they ask you to make it web-accessible, how much would it impact the performance of your system? Would your system behave the same way if the data was made Net-accessible?

CN

Let me provide a framework for you -- for the current system that we are designing: the technician interface remains the same, and the systems that use this code remain the same. We are just changing how these regulations are coded and executed.

     But we have found that, with our solution, a big plus for the solution that we have is that it's really easy to put a web front-end onto it, which we've done already, to market our solution -- to show management how easy it was to put a web front-end onto it.

TY

Just one small point ... do you know how many DOT-COMs went out of business because they thought they could take a backroom legacy system and just put it up on the web, without consideration for the rules that it would (or would not) be enforcing, left and right?

     I know of a company that was selling knives, and it forgot to check credit limits. Once they went on the web, things were going out the door like crazy -- and we as a company loved it because we were shipping things like crazy. We started to observe, "Hey, wait a minute! We used to send one package car there a day; we're sending four and five!" Then all of a sudden, their company started to say, "You know what? We've got to start selling receivables because we're not getting paid."

Connecting rule tools?

[from the audience]: Claudina -- you talked about using RuleTrack and the Blaze rules engine. Is there a connection between them?

CN

Yes. When we started to work with these two products they were totally independent. But halfway through, we realized that maintaining the business rules on an ongoing basis was really important -- they're an organization asset. We came to realize that being able to link the business rules to the 'technical' rules would really be a great value.

     So I put the two vendors in contact with each other and as a matter of fact there's a demonstration today of their results. Or if you go to the Blaze booth, they will be able to demonstrate it. We have not yet used it but it is there, and I was very impressed. They had their prototype up in less than a month -- very successful!

[from the audience]

Donald, as a follow-on to the tools question, I think you mentioned that you used a couple of tools: you used both a Microsoft tool and RuleTrack. First, what Microsoft tool was that? And what were some challenges or lessons that you learned in merging those two tools?

DC

We used RuleTrack -- and we used the terms in RuleSpeak in RuleTrack, which connects the rule statement and the terms -- and then we mapped from RuleTrack to the ORM metamodel. That worked well.

     To do that we used a predecessor of the tool that's now in VisualStudio.NET beta 2. It was called VisioModeler and that's actually now available for download from Microsoft, free. It combines business concepts and facts and rules in one model and will then generate a normalized entity-relationship diagram from that, and then on into the physical database. That's what we used to bridge from terms and facts on through into the database.

[from the audience]

Did you have any particular challenges?

DC

Well, it was a new tool so we had to train people, but that went well. And we had to train people in RuleSpeak (and so on). I'll be discussing more about the lessons learned in my Thursday talk.

Criteria for rules tools?

[from the audience]: I've heard some of you say that you have extended some tools. And I've heard some of you say that you have used different tools. I'm a little bit confused. Is there anything that you can give me that I can use as criteria for selecting a tool? We don't have the option of choosing every tool. Do you have general criteria that you would use for, say, rules mining or repository or an engine -- something to say that a tool should have at least this or that kind of capability?

KS

At last year's Forum, Terry Moriarty did a wonderful presentation on that topic -- looking at different requirements for a good tool. So if you could get your hands on a copy of that, I think you might find that helpful. I thought it was just excellent -- I went, "yes, I want that! And I want that!!"

[from the audience]

There's a link to that material on the web.

[ed. The URL is:   www.BRCommunity.com/a2000/b044.html ].

Processing rules (procedures) and business rules?

[from the audience]: Are 'processing rules' considered part of the 'business rules'? Everyone appears to have a different opinion. One manager says, "No, take these rules out. They are part of processing." Other people say, "Leave them in! They are part of the whole set of business rules that have been defined." Even in the classes today, you hear different opinions from class to class, people to people. You're the experts! What do YOU say?

KS

What I tend to find is that generally for business rules if you follow a declarative approach, that's usually a really, really good bet. Those are non-process oriented; those are the 'what' not the 'how.'

     But then I find that once you start working with the IT folks, perhaps doing things like Use Cases and so on, some of those get transformed into 'process' rules. They might be worded a bit differently -- a little more 'technically' -- but you usually do have some kind of underlying business rule that is the genesis (the origin) of that 'processing' rule.

TY

Someone said it before -- "consistency"! There has to be a consistent terminology. I have these very 'feisty' discussions with the applications people. They say, "Okay, I can write rules code. I can write COBOL code -- very structured." So I say, "Go ahead, write your rule. Then, show me what the first word is: Is it a verb? Is it an action word? What's the structure of it?"

     The point is … I tell them there is a standard for writing the business rule. I can't tell you that it is this followed by that followed by this, but there is a consistency in form. Four or five years ago we were struggling. But now I think we are approaching a point where -- with the Business Rules Group's excellent document, and Ron's material that is available through Business Rule Solutions -- we have an approach to documenting a business rule.

BO'N

I do a lot of migrations. I do a lot of mining of legacy business rules. And I find that I do classify legacy ("processing") rules differently. I will classify them, for instance, as a 'legacy artifacts' or 'system rules' (as opposed to 'pure' business rules).

     From there, I like to evolve and synthesize and refine that list of rules so that, at the end, I end up with 'pure' business rules. But in the process of doing a migration, those legacy implementation rules and artifacts are really, really important. One good example is the case when the client begins to see how much of their business has been tailored toward the legacy artifacts, and then you can point out and say, "Look! You can free yourself from these legacy artifacts when we migrate to the new system! Isn't it exciting that you won't be bound by your business process being tied to these things."

     This then becomes a liberating thing -- it truly does. So for us, there has been extreme value to capturing these legacy artifacts. But we do classify them as such so that then we can pull them apart from the 'true' business rules.

     What we're working on now is the path (or 'heritage') of a rule. That's difficult to do! In fact, I'm trying to extend RuleTrack right now so I can have this path -- to be able to trace it through -- but also to be able to show the user only the current rules (the true rules). Then if they wish they could also trace the heritage. I'm working on that now -- that's my current job -- because I find that the legacy artifact stuff is very, very important to track.

Validation rules and business rules?

[from the audience]: This is a 'poll' question to settle a debate we've been having: are rules about validating user input 'business rules'? For example, say I have a screen where a user puts in their birthdate and I need to know a person's age. I have a lot of rules based on your age, so I want to say things like: you can't be more than 110 years old, and you can't be born in the future. Are those 'business rules'?

BO'N

I think that is an 'edit rule' and I think there is usually a business rule behind it. So, no, it's not a business rule.

AM

Do you want us to raise our hands? I vote "yes."

KS

I agree with Bonnie.

[others]

Yes…

GL

We have four 'yes' votes, and two 'no' votes.

CN

I think it's a rule that you have to do something with it, so you just go and do it. Whether you call it 'business rule' or not is really not an issue.

[from the audience]

Why don't we let Ron be the tie-breaker?

GL

No, sorry -- Ron's not allowed to talk!

Explaining 'rules' outside this room?

[from the audience]: You all have such a passion for this business rules approach, and I was wondering how you explain this to people outside this room … because it's still such a 'secret'; it isn't mainstream. I believe it's coming … but then I've been saying that for ten years now. So I wonder how we can explain this to someone outside this building who doesn't know about 'rules' -- can you do that in ten words or less?

CN

I'll attempt to answer your question. Here's what I did. We took the project that we were given -- nobody called it "business rules"; it was just "give me a better way of doing this business." We came up with a group of concepts, and we showed management how easy it was to implement their rules. Then we took the project and broke it up into phases, and we had a deliverable on that first phase.

     So in my opinion, what you do is you take the business need and you actually implement a portion of it. You show people how much easier it is to maintain and how the customer can actually participate in changing the rules. That's my 'marketing strategy' -- you actually do it.

BO'N

Here's one for you: a system goes 'legacy' -- not in nine months or a year -- it goes legacy when you stop requirements gathering. So what I would say is that the business rule approach represents continuous requirements gathering; requirements gathering never stops. The other thing I would say is that this approach represents giving the maintenance to the business people, where it belongs.

DC

In the project I worked on, I actually leveraged the requirements (the business drivers for the project) which were flexibility over the long term and financial control. The reason that those were the business drivers was that the current system was so inflexible that over fifty percent of the financial transactions in the system were going outside the system, through spreadsheets and so on. So there was no business control.

     In this situation, rules were inherent -- it was about pricing and deals and so on. So it was, in that sense, self-evident that it was a 'rules' problem. They understood that they could not change their rules because the system was not flexible enough.

     So I actually found things in the business situation -- the business drivers, the business problems. But then I did have to explain to people what this approach was and how we could get the benefit from it. Bit by bit, that's what we did.

The culture-change aspect of business rules?

[from the audience]: It appears to me that one of the main things we are changing is the culture. We are getting business users to become self-sufficient (like they should be). But the culture that seems to be prevalent is that business users 'order' and IT people 'deliver.' Can you speak to some of your experiences as to how you managed the culture change portion of this exercise?

KS

In many organizations it's a very gradual change. I've seen some organizations with the attitude of "yes, I like this business rules stuff, but we want IT to take care of it." So they start off with that. But then they start to realize, "Say, this isn't that difficult" when they have their business folks sit down with their IT folks and the tool. At that point, they want to start to take possession of the rules.

     I think it really depends on your organization -- the culture of the organization -- and it's going to evolve over time. You want to do what fits in that culture and then migrate so that you get to your ultimate goal of the business being in charge.

GP

I'm going to be talking about some of these things in my presentation on Thursday, but in our case -- at least in the defense industry -- it's happened almost naturally. There have been significant reductions in the defense industry over the past ten years, and the rate of reduction has been higher for IT than it has been for our customer base. Because of that, we are so thin in our ranks that some of the responsibilities that have been traditionally held by IT folks are now being taken on by others -- they have to be. We have some of our users who are taking on a more active role, for example, in project management. It has been quite an interesting experience.

     Nonetheless, I think it's good for them to be taking on this responsibility. I think it's good for them to be actively engaged in this and for us to be in more of a support role and working with them. So my answer would be that it's sort of 'just happening' to us.

[from the audience]

Basically, to clarify your case: it appears that your change was driven more by a compelling event that was not directly 'business rules.' The compelling event was 'reduction.'

GP

Yes, our change has been a function of the business itself. There have been other drivers that are involved there: mergers and acquisitions have also driven us as well. So we have a variety of pressures, but they have been happening organically.

---

GL

Time flies when you're having fun and you know what? It's the end. The time's up! I know there are still some hands up. Please save those questions for the Gurus' Panel. Special thanks to the panel members; you folks did extremely well.

# # #