Panelists

Bonnie O'Neil, Westridge Consulting, President

Dave Carl, CIGNA Benavioral Health, Director of eCommerce/Data Warehouse Development

Denis Kelliher, Allied Irish Banks, Principal Software Engineer

Frank Cunningham, AT&T, District Manager

Mark Madigan, IT Cadre, President

Mark Meyers, California ISO, Manager

Moderator

*/ ?>

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

Introductions

[GL]:  Welcome to the practitioners' panel discussion.  This is one of my favorite parts of the Forum!  This is my fourth year of moderating this panel discussion, and I have to say, four years ago one of our criteria for the practitioners' panel was to have people who were actively practicing business rule type projects so we could learn from their experiences.  Four years ago, that was a challenging task.  We had to really goad and bribe people to come up to the panel.  This year I had so many practitioners it became really difficult to pick. But I think that we have selected six who really have been working actively on business rules projects in the last few years.  They've had a lot of different experiences, covering all different areas.  So together I believe we can learn a lot! First, just a bit of how we run this Forum panel:  this is the audience participation part of the program, so I'll start off by asking the panel members to please introduce themselves. After that, I'm going to start off with a couple of questions. But this really is YOUR forum, so -- after those introductions -- any time you have a question, just raise your hand and I will try to be as fair as possible to cover as many hands as I can.  We have a large group and usually we have lots of fun in this session so ... relax and come up with questions that you have always had but were afraid to ask. Now you have experts to ask.

Gladys S.W. Lam

*/ ?>

Okay. So, thank you panel members!  I would like to start with each of you introducing yourself and then giving us your experience and business rules projects, a word about what tools you use, and a "DO" or "DON'T" to tell our audience.

Okay. Mark?

Mark Meyers

*/ ?>

Good afternoon. My name is Mark Meyers. I work for the California Independent System Operator -- our job is to run the transmission grid in the state of California. We've developed rule projects within our Compliance Division, which mainly monitors the compliance of transactions within the California markets.

Using the Blaze rules engine, we've just recently implemented about five different rules projects in the last year and a half (or so).

As far as the DOs and DON'Ts go, most of mine are DOs, with one DON'T:

• DON'T do a rules project when you have other projects that you have to do if it's your first time out. Doing something in parallel with new technology is really difficult.
  
  
• DO use Use Cases.
  
  
• DO use a repository to store your rules. Excel and Word documents just don't cut it.

Denis Kelliher

*/ ?>

I'm Denis Kelliher from Allied Irish Banks in Dublin, Ireland. I've worked with rule bases for approximately fifteen years, more recently around the credit delivery and assessment, credit management, and debt recovery areas. The type of tools that we use are Strata, which is supplied by AMS, TableBase from Data Kinetics, which we use to implement behavior scorecards, and credit scorecards developed by FairIsaac. We also use CACS Anywhere supplied by AMS, which is a debt recovery system. All of these three products implement rules in different formats -- some have user input; some don't.

In terms of DOs and DON'Ts...

• DO allow the business to manage and implement their own rules because they know their own business.
  
  
• DON'T overcomplicate. Be pragmatic.

Frank Cunningham

*/ ?>

I am Frank Cunningham. I'm with AT&T in the consumer part of the business. My group actually started out as a data management organization, supporting the needs of 'consumer.' We evolved into a combination of 'doing data' plus the business rules. For the last four years or so, we've been doing a lot of work with rules, in the specific context of key data that help drive the consumer business. Most recently (in the last six months or so) we've begun implementing a formal rules management process and developing a repository. We're looking to put more rigor around the process we'd been using prior to that.

Technology-wise, because we are really focused more on the business aspects of rules and working with the business to get business people to isolate and define rules, we are using System Architect in an extended form to act as our repository and capture point.

My DOs and DON'Ts ....

• One of the biggest DOs that we've found to work for us is to make sure to have a good relationship with the business and to ensure that the business understands the value of the rules in their context. They basically need to 'get it!' ... they need to understand what the rules mean and how the rules impact their day-to-day operations.
  
  
• DON'T try to do everything at once. Pick things out that are going to lead to the biggest value back to the business. As I'm sure is true in any case, the number of rules that the business deals with is in the thousands, so it's good to focus in on those that are going to be of the biggest value.

Mark Madigan

*/ ?>

Good afternoon. I'm Mark Madigan, President of IT Cadre. We're a management technology consulting company, focused on rules-based solutions. My history with rules goes back to my days when I was the director of billing and product reference at MCI. At the time WorldCom decided to purchase MCI, I decided to go to start IT Cadre. And given recent events I'm rather happy I did that!

As far as the technology, the history I have is with ESI's Logist and has been focused in a few areas that are strategic lately. These include auditing and customer care, logistics, and also some government applications.

From a DOs and DON'Ts perspective, ...

• I think the one DO that I would have to emphasize (as mentioned already) is, when you're just beginning with rules, to identify a problem that's very meaningful for the business as the initial area. Do something that can really demonstrate value quickly.
  
  
• From a DON'T perspective, I would say DON'T go and try to sell a complete change of process to business rules before you have that initial success. Going through and demonstrating the value before you take the next step is really important.

Dave Carl

*/ ?>

I'm Dave Carl, Director of eCommerce and Data Warehouse Development at CIGNA Behavioral Health. CIGNA Behavioral Health is a company that provides mental health and substance abuse benefits to health plans and corporations.

We recently built a web system that essentially replicates the decision-making process that a care manager goes through when we're deciding whether or not to authorize more care. We have an internet presence now, so that our network of therapists can come online and get additional coverage without having to call somebody in our business to set up a meeting, wait on the phone, and all that. It's a Java-based application, but we use Haley CIA server and Authorete to execute and build the rules that execute the decision-making process the system uses.

As far as the DOs, I would say...

• DO make sure your object model is fairly well complete before you start to author rules.

And in terms of DON'Ts, ...

• I would say DON'T ever assume you've got the 'last' business rule you're ever going to get from your business analysts.

Bonnie O'Neil

*/ ?>

Hi, I'm Bonnie O'Neil, President of Westridge Consulting. I've been doing rules work now for over ten years, in one form or another. I'm very creative -- I'll go to a project that is NOT a rules project and figuring out a way to sneak 'em in!

As for the kinds of technology ... I've been involved in lots of different rules repositories, so I really am in the rule mining, rule capture, and rule storage aspects of business rules.

For my DOs and DON'Ts ...

• Definitely DO use a repository. This is a very important part.
  
  
• I would echo the opinions of some of the other panel members -- DO be simple. Just try to capture the rules, even if they are simple rules, simply stated.
  
  
• DON'T get hung up on how you're going to put the rules in ... just get them captured. Later on you can normalize them and simplify them and so forth.

---

Gladys S.W. Lam

*/ ?>

Okay, thank you. One thing I should add is that this panel discussion is taped and transcribed. We then put it up on the Business Rules Forum web site and also on the Business Rules Community web site. It's one of the most popular items on the website because there is a lot of information given. Partly this is because of the questions that YOU ask.

I'm going to start with a couple of questions that are usually the 'burning questions' from previous conferences. After that, feel free to raise your hand with your own questions.

.

How do you get sponsorship for rules type projects?

[GL]:  For this initial question, we have one that comes up all the time:  How do you get sponsorship for rules type projects? How does this kind of project come about? For example, does somebody go out to a conference like this and come back and say, "Hey! We need to do RULES!!" Or does a developer go out and say, "I like this rules engine. Should we do rules?" How do you go about getting sponsorship? What is the right approach? Frank, do you want to take this one first?

Frank Cunningham

*/ ?>

In our case it was a little bit of a 'V8 moment' for the business. We had a situation where notification letters had to go out to our customer base for rate changes, and, because of underlying rules issues of how data was managed across the various legacy platforms, customers who were supposed to get the notification got it but a lot of other people who shouldn't have gotten it got it too. This kind of smacked the business between the eyes -- in terms of understanding how rules relate directly to how we understand who our customer is and how that affects the running of the business and the cost of running the business.

So that was how we really got the sponsorship. They had a real life example of how rules help run the business.

Gladys S.W. Lam

*/ ?>

At what level is your sponsorship ... what position in the company?

Frank Cunningham

*/ ?>

It's driven from an Executive Vice President level. That's one level below the President of AT&T Consumer.

Mark Meyers

*/ ?>

Our projects were initiated in a collaborative effort between a business unit (I'm from the business unit side) and the IT side. We had issues with just changing rules in our environment. We get a lot of regulation changes from the regulatory commissions, both the Federal and the local California side, and we needed to respond to them.

Our architects came back and said, "Well, inference engines might be a good idea for you, but really we don't have time to investigate that for you. We don't have that in our architecture. Why don't you go see what you can find out and bring it back to us."

So, as a business unit, we went out, did some limited research, and came back with some suggestions. With their help, we got it implemented in the architecture where we could start using it.

.

How do you classify your business rules type projects?

[GL]:  My next question (unless anybody wants to add to this one) is on classifying the business rules type projects. What are they? Are they rules engine type projects? ... business-driven business rule management type projects? (etc.) What would you classify as an ideal type of project for someone trying to get started with a business rules approach?

Mark Madigan

*/ ?>

In my experiences with a rules engine, I would say that the best kind of project to start with is a business project because it is really a change of paradigm -- one where you are actually able to have users define rules in their own language and understand them ... one where you have the ability to do something very quickly and to show the power that a user will have to be able to see and understand and actually return an ROI very quickly. In telecommunications right now, it's interesting that there are very few dollars being spent after years of driving revenue and tons of capital. So there's very little to go around, but there is a real focus on identifying a way to find increases in profits and revenue by applying a rules-based system that can automate processes and find errors.

I would definitely say that I think there is a lot of value from the IT perspective and that's evident. But when you go to a business person it may not be evident what a business rules approach will bring them. So if you can do something that eliminates their pain and gives them new capabilities -- new ways to do things -- that is a very powerful first step.

Denis Kelliher

*/ ?>

I think there's actually a mix here. It depends on what the business wants. We also have the case where the business people are very close to the process that they want to implement and they want to be in the position to manage it and to refine on an ongoing basis. This is as opposed to throwing the requirement over the wall to IT saying, "Give me a new product." In this case, they're going to control and evolve their process. So, I would see a difference in that respect.

.

Have you experienced any resistance to rules type projects? If so, from where?

[GL]:  We talk about getting business involvement. Do you have experience where IT gives you resistance with rules type projects? Is it vice-versa, where the business gives the resistance to rules type projects? And how do you handle either kind of situation? Or is your sponsorship so clear that you have smooth sailing all the way?

Dave Carl

*/ ?>

The way it works for us is that the business proposers suggest projects that they think are strategically important to the company, and they leave it to IT as to how they are implemented. In other words, they don't come to us and say, "This is a good business rules project; let's try this." They say, "We want to be able to achieve this, within the organization." Then, we decide what sort of process or technology we're going to use.

For us, business rules are involved in everything that we build. One of the key factors we've been looking at to determine whether or not to use a business rules engine or product is the delineation between what we're building and our legacy system. So many business rules are buried in our legacy system that if we have to go in and harvest or re-engineer those then we're going to get bogged down. If it's a new project (even if it interacts with a legacy system), then the legacy system can still stand on its own in terms of the rules. That makes it a lot easier to implement, especially if it's a first-time project.

Mark Madigan

*/ ?>

I think today nothing is really easy. Projects are difficult; capital is constrained. But what is interesting is that this area is growing. Given the very challenging economic times -- with technology probably having as difficult a time as it has in the last ten to fifteen years -- the fact that this is an area of growth within technology is interesting. It's something that proves its value and is making progress right now.

Mark Meyers

*/ ?>

One comment I'd like to add to that is:  when we started our business rules project, one of the benefits we wanted to get was to be able to change rules rapidly. But in the final analysis, the real benefit came from the front-end of the process -- with being able to document our rules, to understand our rules, to have clearer requirements, to be able to see our business in a way that we could never see before. And so, when we went to change it, it became very easy to change. Whether you had change it in a rules engine or you had to go change it in the code, the up-front process needs to be done before anything.

Gladys S.W. Lam

*/ ?>

When you are working with the business people (getting their time for business rules and so forth), is that a challenging process? How do you get buy-in for their time to make it happen? Does it matter whether it is an initial project or a subsequent project?

Dave Carl

*/ ?>

I think that goes back to the sponsorship level that we talked about earlier. If you get clear sponsorship from a high level, one of the things you need to make clear with them at the start is that the IT department is going to need access to subject matter experts for a certain amount of time during this project.

In our experience, we haven't had a problem getting people's time even though everyone is short of time. But we do make it clear with our sponsor (who, in our case, is also an Executive Vice President) that we need people's time to do this right. They make sure that the time is made available or else the project will not be successful.

Gladys S.W. Lam

*/ ?>

How about the other side -- the technology-side? Do you encounter the case where IT says, "Look. You're not bringing in this new technology because we have our existing technology and we don't need another new anything!"? Is that something you face and have to deal with?

Mark Madigan

*/ ?>

My experience is that there is a lot of technology that has come and gone. So, yes, there is resistance to something that is new.

But I think there is so much value that if you break through the time element (of being able to get people's time) then you can move past that to demonstrate how it will make both the IT side and the business side much easier. More than anything, the resistance is just on 'time' rather than resistance to business rules as a concept.

Gladys S.W. Lam

*/ ?>

Thank you, panelists!

---

<to the audience> I could stand here and ask questions all day if you guys don't say anything....

.

How to get the right level of detail in the business rules that you include in an RFP?

[from the audience]:  I'm with a large federal government organization that has twenty-year-old legacy, mainframe systems. We're looking to modernize our applications, to get self-service out to our client-base, and to identify third party vendor solutions for support in our applications. We tried this ten years ago-- capturing all our business rules -- and failed miserably. Lots of lessons were learned, and I don't think we know what all the lessons are yet! My question is:  how do you know what level of detail to ask for in your business requirements -- and specifically in your rules -- in a Request for Proposal (RFP)? In other words, what level of detail is 'enough' so that a third party vendor can come in and say, "Yes, we have some viable solutions to meet your application needs!"?

<silence>

Gladys S.W. Lam

*/ ?>

You stumped them!

<laughter>

Frank Cunningham

*/ ?>

We are doing some similar work ... looking to outsource certain functions within our environment. The approach we took for the RFP was to capture the rules at a purely business level and not to drill them down to any kind of atomic level at that point.

The idea there is being able to get a response back from those who are going to respond to the RFP just to get a sense of how they would approach building something to support our requirements. That way, once we get to the point where we are going to select who we are going to work with, that's when we will drill down to the atomic level. We will start to lay all of that out as part of the step in the process to define the full set of business rule requirements.

Bonnie O'Neil

*/ ?>

I have a question for you:  is the attempt to produce an RFP that will solicit a COTS [Commercial Off-The-Shelf] vendor? In other words, a pat solution. For example, do you envision having list of business rules so that you can say, "Here are the business rules that this COTS package must support."? In other words, am I correct in assuming that you are not soliciting a business rule engine tool?

<audience>

*/ ?>

That is correct.

Bonnie O'Neil

*/ ?>

Then I wouldn't really know about that because my experience has been on the other side ... that the COTS tools do not support the business rules as you need them to. That make this a very tough question, and I echo what Gladys said. I am a little stumped on that one because it's very difficult.

To be clear, I do like COTS tools from some perspectives. But I don't like them from this major perspective because they just don't support rules well. What I've seen my customers needing to do is to re-engineer their business process to shove it into the COTS tool like a Cinderella slipper.

<audience>

*/ ?>

Well, we're entertaining doing precisely that. We're ready to change our business process because we're pretty confident, through our analysis so far, that there are solutions out there. Now, whether it is a 60% solution, an 80% solution ... we'll find out when we do our analysis and evaluation.

But we're still struggling to know how much information we need to provide them. We don't want to scare the industry off.

Bonnie O'Neil

*/ ?>

Let me ask you this. Are there processes that you suspect are sub-optimal ... that you may need to re-engineer?

<audience>

*/ ?>

Oh, sure.

Bonnie O'Neil

*/ ?>

Then my advice to you would be that you analyze your business rules and figure out which are the ones that are absolutely critical:  the ones you cannot bend on, the ones that are critical to the way that you do business, the ones where you cannot live with the re-engineering of that particular business rule. Then list those because those are the ones you cannot 'live without.'

Do you see what I mean? In other words, you approach it from the perspective that, "Here are the rules that are necessary -- the ones that we must have."

If you like, you can also say, "Here are the ones that we have right now, but we are open to re-engineering of these."

<audience>

*/ ?>

We’re almost looking at it in the reverse of that because there are certain applications for which we know that there are no third party solutions. We know that those are going to be roadblocks to whatever we end up getting. So we are willing to entertain vanilla versions of those things to see whether they will accommodate a good portion of our business applications.

But we’re still struggling with where do we cut off, to keep from going too deep into our rules definitions that go into the RFP. We have this concern because ten years ago we tried getting our specifications right down to the nth degree and it failed miserably. It's just too much detail. When the vendor came in and said, "We can build this," it turned out they couldn't.

Denis Kelliher

*/ ?>

We had a similar experience. We wanted to externalize our rules, and the call was going to be made as to whether we would go outside or do it inhouse. As it happened because we were the ones that understood our own rules we didn’t need to document -- we made the call to keep that element in-house. So we knew the rules that we wanted to implement and then chose something that we could implement them in.

Mark Madigan

*/ ?>

I’ve had an experience in the past where a COTS product has ‘choked’ on complex rules. A lot of the easy ('lite') rules were done in the beginning and then down the road the project choked.

So, my recommendation would be not to try to document a lot of rules but, instead, to get a handful of your most complex rules -- basically those where, if you can’t do these rules, your business can’t operate. Then, have the COTS vendor prove to you that they can do that small subset of complex rules. Until you see that, you don’t know for sure that they can support your business.

.

Is there a kind of problem where a business rules approach is not the right approach?

[from the audience]:  My question is:  did one of you ever reach a point where you thought it would have been better not to go for business rules? In other words, are there kinds of problem where a business rules approach is not the right approach?

Gladys S.W. Lam

*/ ?>

This is a business rules forum!

Mark Madigan

*/ ?>

Everything can be done with business rules.

<laughter>

Bonnie O'Neil

*/ ?>

Since I make a living doing business rules, I refuse to answer that question!

Mark Meyers

*/ ?>

I think the only question that we’ve had involved large batch processing -- if there’s time enough to do all the batch processing. But I think that’s more of an architectural question, and it is something that is still being worked out.

Frank Cunningham

*/ ?>

There are always other ways to go at issues. You can have IT come back to the business and present a solution that may get you to the same end. In the case of my group, because (in the past) we were focused on the data, we could have come up with a data-driven type solution. But as I’ve gotten more into rules, it has become clear to me that I’ve always somewhat thought that way and perhaps I just didn’t call it 'rules.'

So my experience is that the rules process (thinking about things from a rules perspective) just improves the capability of communications between all the parties involved in a given work effort. It sets a common language, and it gives the business foundation for why you are doing what you are doing. That’s something that’s missing in a lot of the other approaches.

Bonnie O'Neil

*/ ?>

I was going to say a very similar thing. Regardless of whether the project is explicitly a business rules project, 'business rules' is an analysis approach; 'business rules' is a way of thinking.

No matter what the project is -- no matter what will happen down the road in the execution of that project ... whether it's going to be a data warehouse project, whether it's a data migration project, whether it's an application, a re-host, a re-engineering, no matter what it is -- I would say that 'business rules' as an approach is a sound approach:

• It's a communication vehicle; it improves communication between IT and the business.
• It is an articulation method; it's a way to be able to specify things using more precise verbiage.
• It's a way of being able to get the business to quantify and qualify what they mean when they use ambiguous terms.

All of these are reasons why I think business rules are useful, regardless of what happens to the project down the road.

.

Is there a checklist that can be used when selecting a rules tool?

[from the audience]:  We have already established the fact that we are going to incorporate a business rules approach into our software development methodology. Given that, if we have not selected a tool is there such a thing as a checklist? For example, when we purchase software there are documented system requirements that you need. How do we know which tool is the best tool to meet our needs? What should we be looking for? How do we evaluate tools and vendors, other than by giving them our most complex rules to see if they will work on their system?

Mark Madigan

*/ ?>

I think Terry Moriarty has a checklist that she has gone through in some of her presentations.

Frank Cunningham

*/ ?>

One thing I would recommend is that you clearly list what you want to do because that is what is going to drive your assessment of what tool is going to work best for you. For example, if you are looking at rules management, governance, working with the business ... that's going to drive you down a different path than if you are talking about a rules engine.

So you really want to, from your own standpoint, make sure that you are clear about what you want to accomplish.

Bonnie O'Neil

*/ ?>

It also depends upon the architecture that you have already within your organization. For instance, If you have a standard that you are using for application development (an already-existing ap-tool), do you want a rules engine as a 'plug-in' piece to that existing environment? Or do you want a whole application environment (or workbench) that includes a rules capability?

Dave Carl

*/ ?>

One other thing that should be on your list:  make sure the tool you choose is supported, especially if this is your first foray into this kind of development. Make sure that you have both training and support spelled out, both at the start of the project and throughout the length of the project. You want to be supported in case you run into trouble, either getting up to speed in the tool, helping authorize rules, anything like that. I think that's critical when you are doing this the first time.

Gladys S.W. Lam

*/ ?>

Mark Meyers, I know you have a specific tool. Did you go through any selection process to choose that tool?

Mark Meyers

*/ ?>

Yes, we went through a selection process. We did a due-diligence report. We have an existing OO framework that our IT department works within, so the tool had to fit within the parameters of that framework. That was a big part of our selection process.

We also had a certain amount of rules that we had to process, so we looked at that aspect. Finally, we had some complex rules that we actually gave to the vendor -- our most difficult rule sets -- to see if they could implement them.

As you go down the path, you will also be making 'tool' decisions. Some rules can be implemented as very changeable type rules, while some things -- the very, very complex rules -- need to be implemented in Java classes. We did find out that not all things can be implemented right up front. But those are usually things that are not so visible and you don't need to worry about them early-on.

.

If there is no communications problem, do I still need a business rules approach?

[from the audience]:  It was stated earlier that the business rules approach helps people to communicate. I like this very much because I can see people having problems communicating. But could that mean that if I have people who do already communicate well -- have a perfect understanding of their business -- then they don't need the business rules approach and there would be no benefit?

Bonnie O'Neil

*/ ?>

I think the problem is the IT community vs. the business community. You may have people in your business community who communicate very, very well between each other, but - boy - when you get them in front of a developer, the developer doesn't understand squat about what the business person is saying. So I think that the communication gap between the business person and the technologist is one of the key aspects that business rules address. It gives you the ability to state things clearly and succinctly, in a form that both parties can understand.

Mark Meyers

*/ ?>

The communication is, I think, both vertical and horizontal. We have found a huge benefit in the much clearer requirements. When we started doing fact models and then sharing those fact models with our other business units, they would look at them and say, "I now see my business in a completely different way. I didn't understand that as well as I do now!" So, I think that some of the tools that the business rules process brings clarify both horizontally and vertically.

Dave Carl

*/ ?>

I would add that if you are building a new system, some day it is going to be a legacy system. Perhaps the person who built it isn't going to be around any more. The business is still going to want to know, "What is the system exactly doing?" When a developer has to go into the code, even if they know the language (say, it's COBOL), interpreting somebody else's COBOL code that can be a ripe opportunity for mis-interpreting what's really happening. On the other hand, if you have the rules spelled out -- either in a tool that's designed to do it or just in the documentation process -- you can pretty clearly communicate what's actually going on to both the developer and the business person.

Frank Cunningham

*/ ?>

I would add one thing from the business perspective. Where people have different responsibilities they tend to think about the running of the business from their perspective and don't always have the same view of rules as the person who is doing something else. For example, in our organization, the organization gets sliced up by product and by business function (like 'marketing' or 'ordering' or 'billing'). Those groups look at things from their perspective and develop, over time, their own terminologies and their own rules that manage those terms.

I don't know how realistic it is to think that there's not going to be some sense of this kind of communication difference to be worked though. This happens even in smaller organizations. This even applies just to establishing the right policies and rules that you want to run your business from.

.

Have any of you been successful in integrating an event management or workflow management system with your business rules solution?

[from the audience]:  I'm wondering if any of your companies or clients is actively using an event management or workflow management system. And, if so, have you been successful in integrating that with your business rules solution?

Mark Meyers

*/ ?>

Our company uses Remedy and we have not been successful in an integration at all.

Bonnie O'Neil

*/ ?>

My last client recently started using workflow. What's cool about this particular client is that I sold them years ago on business rules so they're excited about business rules. But in terms of the integration with this new piece -- this workflow thing that they just recently did -- they don't have a clue. The good news is that they are moving in both directions simultaneously .... it's just that they are separate directions!

Mark Madigan

*/ ?>

We've done some limited work with workflow but it was with an outside vendor.

.

At what point should the business rules process begin? Is it part of the business case or does it come later?

[from the audience]:  Since you have implemented business rules projects, I have a question about placement. When coming from a business case as the starting point, at what point should the business rules process begin? Is it something that comes after the business case and some rules are developed but before IT gets the project so that it is part of the scope and plan? Or is it something that becomes a project and then IT goes back and asks, "Okay, we know what your business case is; now what are your rules?" Where do you see the 'rules' aspect best fitting in the process?

Mark Madigan

*/ ?>

It obviously goes all the way to the end of the process. But even when the business is coming up with ideas, there is a lot of value in defining rules and analyzing those rules when you have the ability to define things in business terms. Before you do anything, you can have users define the logic and see whether or not there are flaws in that logic. That's really the whole initiation of the project. So, yes, at the very beginning I think there is value.

Mark Meyers

*/ ?>

We typically don't start coding until all the rules are fairly well fleshed out -- at least at the 90% level or better. We can build the whole application ... just leave the logic out because it is separate from the rules. We try to get a fact model ... get the data identified and then make sure all the mappings are there before we pass on the requirements.

Frank Cunningham

*/ ?>

I wish I could get my organization to do that.

Bonnie O'Neil

*/ ?>

Regarding the business case, I think that there are a lot of rules that are present when you make a business case. So I think that specifying those rules up front is important to do because they are actually critical to the business case.

Gladys S.W. Lam

*/ ?>

There is someone in the audience who wants to respond. So I'll jump out of queue let that happen.

<audience>

*/ ?>

I'm a consultant in business rules analysis. I think business rule management should be decoupled from projects. Business rule management should be a continuous process. Often you see that it stops when the project is over and the system is implemented. That's not good at all. Of course, it starts with some project (maybe), but it should be a continuous process.

.

What alternatives are out there for a business rules repository?

[from the audience]:  Several of the Forum presentations mentioned this notion of a business rules repository. And again at the beginning of the panel, several people were nodding when the importance of a rules repository was mentioned. Yet I don't really see any vendors out there, touting business rules repository and the value of that, unless it's tightly-coupled with some form of development product that they've already got. What do you suggest for companies getting into business rules that want to 'do it right' in terms of solving that problem of the business rules repository?

Bonnie O'Neil

*/ ?>

BRS RuleTrack, which is represented by our moderator [Gladys Lam], is a wonderful product, and it is relatively inexpensive. While it is not 'one size fits all' (in other words, it is not a panacea), it is a wonderful product to get you started. It has enough 'buckets' for most of the things that you're going to experience and the things that you need to know when you start to capture business rules.

It is sold as a relatively inexpensive, stand-alone rules repository, which makes it a really nice tool. And while it is not coupled to any rules engine or rules-executable product, there are alliances with many of the other vendors. So you can take your 'stuff' stored in BRS RuleTrack and export it into (for instance) Blaze or whatever your favorite tool (if they have an alliance with them).

Frank Cunningham

*/ ?>

We've had a lot of success with an extendible version of System Architect. As you may know, System Architect is not a rules application, but the value that it leads you to is the flexibility that affords. This is particularly valuable in being able to manipulate the underlying metadata that drives what you want to maintain about the rules. So far, this has been pretty successful for us.

Mark Meyers

*/ ?>

We also use RuleTrack. But no matter what you decide on a repository, you will quickly come to the realization that business rules are metadata and there is so much that you need to capture about them:  where they came from originally, how you implemented them, the start date, etc. There is just a ton of metadata that you need to manage the rules. You will realize you do need a repository, no matter what else you decide.

.

What aspect of business rules yielded the most surprising results? ... the most unanticipated difficulty?

[from the audience]:  In whatever context it would make sense for any (or all) of the panel members, be it methodology, software development, or implementing a rules engine, what aspect of business rules yielded the most value where you didn't expect to find it initially? And, conversely, where did you find the most difficulty in an aspect where you thought things would be rather simple?

Mark Madigan

*/ ?>

I think the most value is the tight coupling that you can have between the business community and IT when you have a common language. This is not only from the mechanics of changing systems but also from eliminating steps. So just that tight coupling and the speed with which you can react and stay ahead of the business needs is something I see.

Denis Kelliher

*/ ?>

From an IT perspective what we discovered was:  once we had implemented a decision rule system, the business no longer felt the need to come to IT -- they were completely empowered to build, create, and modify on their own. This was once we got over the first step of making sure that all the data was there day-one. That's the hardest -- making sure that they had enough to play with.

Dave Carl

*/ ?>

We've been live over a year now and the biggest revelation I've had is actually one we were expecting but still it surprised us -- that is:  how quickly we can go from the business wanting to make a change in how the system is processing the rule to actually implementing it. The business can easily pinpoint "this rule has got to change this amount to get the desired result," the developer changes it within a matter of hours, the testers test it, and we're out live. This is the kind of benefit we were hoping to get, but it still is even better than the expectations.

Mark Meyers

*/ ?>

Yes, I'd echo that as well. The first time I heard, "Yes, rule-296 needs to be fixed," I thought, "Now that's a nice easy way to find it in the code." That was really good.

.

Have any of you done business rules work that deals with issues of enterprise integration?

[from the audience]:  I hear a lot of discussion about business rules at a project level, and I'm assuming that 'project level' means for a particular line of business or a particular business process (or something like that). I tend to work at the enterprise level where they are trying to integrate their concepts and their terms and their business rules -- and identify redundancy, conflicts, and things like that across huge enterprises. I'm not sure, when you talk about a 'project' do you mean a horizontal slice across the enterprise or vertical slice? And, if it's horizontal, do you do anything differently with your business rules approach when are trying to address the enterprise integration issues than when you're trying to handle a "let's drive down and build an application"?

Bonnie O'Neil

*/ ?>

I want that question! I'm the Integration Queen -- I do a lot of integration work.

One of the things I see, in addressing that kind of concern, is that the thing that works best is to get a team of cross-project, cross-discipline, cross-organization, cross-everything SMEs [Subject Matter Experts].

What I've done is formulate a team like that, nationwide. We had people from all over the U.S. on the team; we even had people from Alaska. In essence, it was a 'virtual' team. They would came together a couple of times a the year, physically, but over the Internet we set up a closed 'chat' area where I would post things on the business rules and then the team would go back and forth, discussing them. I integrated this into their workflow as a methodology, telling them, "Every day when you get your email, go onto the chat room (called 'Team-Room') and check to see the latest 'stuff' that is posted there. Integrate what you find there into the way you do business." This way we had a lot of flow back and forth. Largely, the success of this was due to the fact that we had cross-discipline people; we had surveyors and users and data input people and everyone in-between -- managers .... the whole nine yards -- and they would argue back and forth because they had totally different perspectives.

Oh, we did get some very interesting arguments because the surveyors would group together and say, "We don't like the way those users are talking." But it was wonderful because we got all that 'stuff' out into the open, and they were not afraid to interchange with each other. The nice thing about the web was that they weren't looking at each other so they had the freedom to be able to just 'blast' somebody. As a result, we sometimes had some rather 'interesting,' critical exchanges going on. I say this was wonderful because we percolated a lot of things to the surface. The final result was that they actually agreed on things.

So the enterprise-wide integration was there. We got them to agree on definitions and business rules. It was a huge win. Yeah! It was great!

.

Are there guidelines and tools to help business people do (and confirm) their direct maintenance of the business rules?

[from the audience]:  If one of our goals is to have the business maintain its own rules and the business people want maintain their own rules, (1) are there any guidelines for how much maintenance they can do, in terms of complexity of rules you allow them to do, and (2) is there any particular product that creates an excellent interface and provides impact tools to allow both the end user and a QA group to determine whether there has been any negative impact from the rules that have been entered?

Mark Madigan

*/ ?>

It's very dependent upon the skill level of the users. The experience I've had with Logist is that the mechanics of it lends itself nicely to having people without a programming background maintaining the rules.

In essence, I think there's the same change management control that you would have whether it was an IT group or a user. The nice thing is that if you have somebody on the business side who has a strong analytical mind and also understands the business then that's probably the best person to do it.

Frank Cunningham

*/ ?>

We are finding pretty much the same thing. Our group was seeded with people both from IT and from the business. Actually, my boss is from the business. That collection -- where we are actually sitting down and working out the rules and then pulling the right subject matter experts in from (and across) the operational teams -- gets us to the right level. What I think works well is having that separation from IT but still having the knowledge and capability to understand it.

.

What are your most important critical success factors to have in place before launching a business rules project or initiative?

[from the audience]:  As a way to wrap-up, I would like each of you to mention the two (or three or four) most important critical success factors to have in place before you launch a business rules project or initiative.

Mark Madigan

*/ ?>

I think that the first thing is to have a very clear objective that you are going after in the project. You need to have a focus and some success criteria so that you can know that your efforts have been successful, based on predefined measures.

Mark Meyers

*/ ?>

If I had to do it all over again, I would say we needed to have a good methodology. We started off and floundered a lot as we tried to discover a good way to store rules, to implement rules with RUP, to find out how rules fit into an 'object' world. We went through lots of gyrations until we got that sorted out. So the first thing I would say is to have a good methodology.

The second thing is:  you need to have a really smart business analyst. In rules projects, your business analysts will need to completely change the way they do work, and you need to get them trained so that they have that understanding.

The third thing is:  you need to have support from your upper management (on down) in order to complete the project and see it through.

And, last of all, understand things are going to go wrong, and you just need the tenacity to work through the problems.

Dave Carl

*/ ?>

I would echo a couple of things just said:  strong leadership and sponsorship, from as high a level as possible. In our case, we had the added benefit of a business sponsor who was someone who was willing to break ties on disagreements over how a business rule should be phrased or set. If two parts of the business differed over how the business rule should be worded, our sponsor decided, one way or the other, which way to go. That helped us a lot.

The other is:  a very competent leader in terms of eliciting business rules from the business. A lot of our projects are dealing with licensed therapists in our company and their training isn't necessarily geared towards providing business rules to an IT organization. So if you have a person who is very good at getting the rules out of the business people, that can really make (or break) your project.

Bonnie O'Neil

*/ ?>

I would also say that getting people on the team from all different levels of the business is absolutely critical. Because, if you don't -- if there is somebody you are missing -- that's an area where you're going to miss the business rules that that person works with. The success that I was alluding to earlier was due to the fact that we had a cross-pollination from all these different groups and all these different job titles. Especially, don't ignore the peons because the peons are usually the closest people to the data; they are the ones who can really tell you where the rubber meets the road, so don't ignore them.

Frank Cunningham

*/ ?>

I would add:  you want to make sure that you prioritize and stay focused. Prioritization means that you have to understand the relative value to the business of the alternatives that you have in front of you. Decide what you want to go after. And once you have made that decision, stay focused on it. As with most rules discussions, there are numerous tangents you can go off on, if you let it happen. You want to stay focused on the issue at hand so that the end result you come up with is addressing what you started with.

Denis Kelliher

*/ ?>

Buy-in from the project group is essential as well. Normally, our project groups are pulled together from all different backgrounds. And if they don't believe in the approach that they're taking, it's detrimental to the project.

---

Gladys S.W. Lam

*/ ?>

Okay -- that's great! I think that's valuable information that we've gotten tonight. So, on that note -- I would like to thank our panel members very much. You all did a wonderful job!

# # #