Panelists

• Chris Collard   Dell / Dell Financial Services
• Dale Owens   IRS
• Andrei Mitran   Connection Technologies
• Kelly Karlen   Blue Cross/Blue Shield of Minnesota
• Denni Harp   AT&T
• Glenn McIntosh   EverBank
• Mike Freiling   Washington Mutual

Moderator

• Gladys S.W. Lam   Co-founder/Principal, Business Rule Solutions, LLC

Topics

1. What are the primary drivers for a business rules project?
2. What is the process for getting support for a business rules project?
3. How do you find business ownership?
4. How do you break up the silos?
5. What kinds of metrics do you use?
6. Do you have a governance process?
7. What should be in place before starting a business rules project?
8. Top-down or bottom-up — which works better?
9. What tools do you use to document your rules?
10. What kinds of things do you want to trace your rules back to?
11. Do your business users now have a higher stake in managing and manipulating their rules?
12. Do you have any hints for bringing the culture of business rules into a company?

.

Introductions

Gladys S.W. Lam   Welcome, and thank you for being here and participating in our Practitioner's Panel.  This year we really put together a nice panel — the actual practitioners in organizations that have been doing business rule type work.  This is your opportunity to participate and to get your questions answered — to get some real life advice. My business rule for this session is:  If your cell phone rings the owner of that cell phone gets to go out and buy me a new outfit; that's how I build my wardrobe.  So please turn off your cell phone.  I have my staff out there, calling each one of your cell phones to see how many outfits I can get out of this session.  <laughter> This is my favorite part of the program, and we get a lot of good feedback on this panel because it is as interesting as you make it.  So if you have questions, this is the time to raise them!  This panel is recorded, transcribed, and posted on our web sites.  We've had this panel recorded for the last five or six years.  It's my understanding that there have been a lot of download requests for this Practitioners' Panel. How I like to run this panel is very simple.  I start by asking our panelists to introduce themselves.  They will tell you their name, their company, and also the projects they have worked on as well as what tools, if they are using any tools or methods.  And then I ask them to please provide us with a couple of DOs and a couple of DON'Ts, from their experiences. Then I will start off the question-and-answer period by asking a couple of questions.  After that, I will open up the floor to anyone who has questions — just raise your hand and I will come over.  I will be the Oprah of the Oprah Winfrey Show; I will come over with the mic and you can ask your questions.  There's always a lot of interaction in this panel, and it's a lot of fun. Okay?  So shall we get started ... with Chris.

Chris Collard 

Thanks, Gladys.  

I'm Chris Collard.  I work with Dell ... Dell Financial Services.  I say it both ways because we are about to be 100% owned by Dell in the next few months. 

I have worked, over the last three years, on bringing a business rule implementation to Dell Financial Services, primarily for our originations and also into our account management business.  We've partnered with Fair Isaac; two and a half years ago brought in Blaze Advisor and a tool called IDM, which is a bureau routing management tool, and Falcon, an implementation that is inside an SOA, primarily web methods.

Dale Owens

I'm Dale Owens, and I'm with the IRS.  I've worked in the business rules area in the IRS for about six years, in a couple of different capacities.  I was a subject matter expert on the business side, and now I'm on the other side of that table — I manage a group that is responsible for developing rules and requirements for the large modernization projects. 

As far as DOs and DON'Ts, what comes to mind is that stakeholder engagement is a critical thing, just to get your key stakeholders to understand the need for this disciplined rules and requirements management process.  Getting their buy-in from the beginning just makes your life a lot easier.

Andrei Mitran

I'm Andrei Mitran with Connection Technologies, as the VP of Systems and IT.  I've been using rules and rules-like engines for about thirty years now, and in those thirty years I've worked on six or seven significant projects.  And all but one of them I consider to be significantly more successful than they would have been if we hadn't used rules.

So the first thing I would say is a DO is that there is a place for rules — they DO work.  I remember thirty years ago going to some conferences (the old AI conferences) where people were saying, "Is this really useful for business?  Is it all hype?"  The answer is:  Yes, it is useful; it is not hype.  Having done it for thirty years, I can attest to that.  So that's a quick DO.

For a DON'T, I had an interesting experience just recently.  I had a very good Java programmer who went to rules training and decided he was now going to write some rules.  Nobody paid much attention to this particular person.  He wrote some rules and what he did was he used the rules engine to write Java code.  <laughter>  It was rule syntax!  In this case, we were using Corticon, and this particular person was used to writing the rules, IF this THEN this THEN this ... maintaining the flow of control.  That's how you write code.  So he did that the same way in the rules engine.  So just because someone's a good developer/good IT person doesn't necessarily make them a good rules person.

So that's a quick DO and a quick DON'T.

Kelly Karlen

I'm Kelly Karlen.  I'm with Blue Cross/Blue Shield of Minnesota.  I'm one of four managers on our business infrastructure services department.  I have accountability for the rule management office that we have there.  I have a team of nine analysts that are specific to our rule knowledge management — understanding our business knowledge.  I also have a team of five analysts that are responsible for the development of some of our rule engine events.

I have a couple of DOs:  As I said in our presentation earlier, if you're from the IT side, find your business counterpart; if you're from the business side, find your IT counterpart.  You're going to achieve your goals faster and more effectively if you're working together, rather than against each other.

Another DO is:  If you're looking just at your knowledge management, validate your business rules beyond your project's scope.  You don't want to invite everybody in the organization, but you're going to get better results and better reusability if you're looking at cross-functional representation in your validation sessions.  So try to get people from the organization in there, beyond your project scope, to say, "Yes, we agree and we can use that in our organization as well."

DON'Ts:  I would agree with you <to Dale> that not everybody can be a good rules analyst — not even good business analysts ... they don't necessarily equate to a good rules analyst.  You really need to make sure that you're finding people with the right skill set; it's a different mindset, to sit down and think through how your business is using its knowledge. 

And, also, for the people on the IT side, don't discount your business folks as your rule developers.  We've had a lot of success in taking the people who really, really knew the business and then making sure that they had the aptitude to understand how the rule engines were working so that they could use those events and get results.

Denni Harp

I'm Denni Harp and I work for AT&T in Credit and Collections.  I'm responsible for enterprise project management and the collections systems initiatives.  I have about eleven years of experience with the enterprise decision management (EDM) tools — the first six in IT and the last five on the business side ... so I've jumped the fence to the dark side, some say.  <laughter>

Primarily the rules systems projects that I've been involved in are for systems implementation, not for knowledge management business rules.  So my purview is basically slanted toward that.

A DO in the enterprise decision management tool space would be to establish knowledge sharing in a collaborative relationship with your business and IT partners, because both teams have a heavy stake in the process.  Both need to be able to employ a good change management process to really get effective use of the decision management tools.  It's definitely not siloed.

And for a DON'T:  Don't give up on your Data Warehouse initiatives for collecting information about all the events that occur during your business rule decisions.  It's very important.  On our first implementation we caved on that because it was too expensive, and we ended up paying for it for several years later.  So it's a very integral part.

Glenn McIntosh

My name's Glenn McIntosh.  I work for EverBank.  Two years ago we brought in Fair Isaac's Blaze Advisor for a product and pricing mortgage application system.  Since then we've had another rules-based project or two.  So I've been in this for about two years. 

As far as practical DOs that we've discovered, number one is:  It's important to follow the same methodology as far as having rule authoring in non-production environments, before you actually move into production.  You need to have the same discipline in rule authoring that you do in developing code.  We've been burnt a number of times based on having rules just right out there in production.

Another DO would be:  We like to have translation layers between our web service interface and our business rule entry points.  This way we can have a layer of abstraction there, to be able to do some interesting things if we need to.

As far as the DON'Ts:  We found tightly coupling the rules engine with external systems — particularly relational data bases — can become problematic in a number of ways.  So if it's not necessary to do that we try to maintain our business rule engine as purely as possible.

Mike Freiling

I go to somewhat the opposite extreme.  I've been involved with business rules since practically forever.  I got a PhD from the MIT Artificial Intelligence Lab, back in the mid-seventies.  I taught for awhile, and since about 1990 I've been focusing on business rules and business rule engines for the financial services industry.

For many years I was designing and building special-purpose business rule engines, including engines in languages like SQL Stored Procedures, which I guess was pretty tightly-coupled to the database.  I guess I didn't know I wasn't supposed to.  <laughter>

A couple of DOs:  One is absolutely, absolutely use a rule specification document and think through what your standards are:  How you're going to write the rules; how you're going to handle 'ands' versus 'ors'; how the default condition gets folded in....  Uniformity of that kind — having a good, solid rule specification — is one of your best tools for cross-validating with your user organization.

A second DO is:  Seek clarity when looking for the people that you're going to work with on the business side, when eliciting the rules.  Some people are more articulate than others; some people know the business better than others.  Neither of those are necessarily the right person to help you figure out what the rules are.  It's the person with the combination ... the best middle-ground between knowing the business and being able to articulate.  That is the kind of person you're looking for.

Chris Collard

Gladys, I guess I didn't follow the rules.  I thought we were doing introductions first, and then DOs and DON'Ts.

Gladys S.W. Lam

Well, I'm going to give you a second chance.

Chris Collard

Okay, I'm not sure if I owe you an outfit, or not.  <laughter> 

In terms of DOs I would say that it's key to find that architectural visionary who can push things forward and break ties.  It's easy enough for these implementations to die on the vine — they start as enterprise decision management and can end as niche implementations of rules.  So, you need to have somebody pushing and breaking ties — helping to enforce certain definitions.  I think that echoes some of the things that have been said on the panel.

And one of the DON'Ts would be:  DON'T necessarily just roll into an existing project method or project discipline infrastructure — try to resist the pressure to do that.  I know that's a sacred cow, but those methods and disciplines don't always apply to the flexibility of business rules.  So, try looking externally, to benchmark yourself in the industry or even to build your approach from scratch around best practices.

What are the primary drivers for a business rules project?

Gladys:  Okay, thank you very much.  Now I'm going to start off with a couple of questions.  But feel free to raise your hand if you have something you've heard you'd like to follow up on, or if you have questions on your own. Let me start with one on the objectives of business rules projects.  What are the primary drivers for these business rules projects that you are involved in?  What do you see as the benefits, and what are some of the results?

Kelly Karlen

When we initially started out it was, from a claims adjudication perspective, to achieve an increase in our pass rate.  We were looking for a hard return on "how do we do more with less?"  But as we continued down that path, we realized that we were losing out on making sure that our rules were staying external and available to our business so that they could make sure they had that information available to them to make decisions going forward.

The rule engines are great, especially when you've got the business side actually creating the events and doing the development piece.  But unless you've really got something that's showing you, holistically, all of the rules — regardless of whether you are automating them or not — to make your decisions by, you're going to lose out.  So we have continued along the path of automation ... but we have also taken a step back to say, "How do we need to manage our knowledge better, too, for the business?"  Now we have both objectives.

Gladys S.W. Lam

Okay.  Anyone else?  I know some of you have practiced rules for a long time.  We talk about that a lot of times — What are the drivers?  What are some of the returns?  Has anybody, in any of the projects, developed any ROI figures or similar measurements?

Mike Freiling

I don't actually have numbers but I have a few qualitative things to say about that.  I wouldn't expect a superior ROI on your first project or two.  There's a certain amount of a learning curve that you have to get over.  So if you sell your first project or two on ROI you may be asking for some trouble.

The other thing I'd say is that there's an intangible ROI that has to do with the improved communication between the business side and the IT side when you use a rule approach.  I was suggesting earlier that you absolutely use a rule spec ... those rule specs, I've found, are readable by people on the business side, whereas I've never seen programming architecture documents that were readable by humans of any sort.  So having that rule spec — that communication — means you get better validation and, ultimately, better satisfaction.  And that's a kind of intangible I think is very important.

Glenn McIntosh

We built a business case for our first project, with ROI.  Our business framework has nine different channels, with nine different product and pricing engines.  So there was a desire, at the top of the house, to bring down the time that it takes to roll out a new product and to get the pricing into all these different engines, along with lowering the maintenance of how much it takes to maintain all of those systems.  So we looked at that really hard.  We found that there was a definite case there, and we met it.

Having said that, as Mike has pointed out there are intangible things ... things that you can't quantify — things that you just know your organization's going to benefit from.  There are gong to be certain risks that you're going to mitigate, and sometimes those are a little bit hard to quantify.  We tried to quantify, where we could, and it ended up really working out well for us.

What is the process for getting support for a business rules project?

Gladys:  That's good. A number of you have talked about support — stakeholder support, sponsorship support — and how to go about getting that support.  What is the process for getting support, and are these types of ROI recognized by stakeholders and sponsors?  What's your experience on the best approach for getting support?

Kelly Karlen

I can say for us, at Blue Cross, we were very lucky in that the breadth of our team had different accountabilities.  Some of the other areas within our team were able to provide value and assist with some of our standard processes, such as our SDLC (and so forth).  That way we were able to step to have that luxury to be able to step aside and build the framework that we needed to put in place for our business rule management. 

We took probably the first sixty percent of our first year putting those processes in place ... learning the methodology and applying it — revising, getting everything in place.  So, once we actually did start rolling it out — when we really started applying it to projects — we had a really good foundation.

Having said that, the very first project had some surprises.  We believe in scoping our projects really, really well because, through scoping, you actually achieve things.  Otherwise it's just continue and continue and continue and never get to the end.  We had sixty-six rules, and with those sixty-six rules we found we had twenty-four gaps or conflicts that we had identified simply by documenting it ... by getting it on paper.  We had our Legal and Compliance area in there; we had our COO in there.  And they were amazed at some of the things we were out of compliance on.  We just had never sat down and looked at everything together, cohesively around that scope.  And our COO immediately asked, "What's your next project?" 

So we were lucky because we were able to step out of the limelight a little bit, to get our foundation in place.  We were able to really think though how we were going to make this work.  And when we did start making it work, we were able to show the value.

Chris Collard

Also, I think a key piece is understanding the different utility curves of the constituents at the table.  They're different for (say) an IT organization around security or stability versus a marketing part of the organization that wants flexibility and time-to-market. 

However, they're not necessarily mutually exclusive.  We have a case where we have a credit group, a marketing group, that wants to lower the FICO ... extend more offers.  And we have a fraud group that wants to clamp down and raise the floor.  Ultimately it's about getting to the table and translating those utility curves into a decision.

How do you find business ownership?

[from the audience]:  My question has to do with how you find business ownership in some areas.  We just had a business rules project that involved different areas of functionality.  For some areas of functionality we had good business ownership, but for others there was a vacuum.  All we had was a legacy system to work with, which was considered a 'black box' by the people using it.  We had a business rules team from other areas, helping us mine the rules, so we did a good job of that.  But eventually we needed to find and anoint business groups within the organization to take ownership of the sets of rules for each particular functionality.  And we were struggling with this because of the vacuum. Have you folks had any experience dealing with that kind of situation?  And, if so, how did you make a difference?

Gladys S.W. Lam

That's an interesting problem.  You have a set of rules.  Who will come up and own it?  Who will stand up and say, "I want this set of rules!"?  Do any of you have experience with that ... trying to find owners for rules, or are they all fighting for them?

Denni Harp

In our experience it's not so much finding the owner as having many owners.  You will have certain rule sets that affect many departments; an example for us is in our interactive voice response system.  Each department has its own team members with some ownership and accountability and with an operational impact as a result of how those rules are managed. 

So exactly the opposite has been our problem:  How do you share one rule set across many organizations?  I know I didn't really answer your question.  I just threw another one out there for you.

Gladys S.W. Lam

Can you try breaking those rules and see who screams?

Denni Harp

There you go.  That will get them!  <laughter>

Kelly Karlen

Recall one of the DOs that I said in the beginning:  if you're on the IT side, try to identify who your business counterpart is going to be, right off the bat.  If you can bring them along with you, they're invested right from the very beginning. 

Now, having said that, I have a team of nine people.  We don't 'own' our business rules.  The business — our business customers, on the business side — owns the business rules.  They have accountability for approving them; they know what those rules are.  In the end, they need to be able to manage them and to tell us when something is going to change in their environment so that we can make sure things get updated.

We have five areas (divisions) within our organization that have stepped up to the plate and have actually given departmental resources dedicated to their business rule management.  In other areas, however, they don't have the resources and they're not ready to do that.  So for that case I have project stewards within my team that can help bridge that gap until they are there ... until they can see the value and say, "Wow!  Look at what we've invested in this.  We need to be able to manage it going forward." 

It's not enough to say it's done and to set it aside until the next project.

[from the audience]

I'm responding to this fellow over here in terms of the approaches to address the issue of how do we get people to buy into some of this and make some decisions.  The approach we've used is to identify, say, the CEO within the organization and then identify the ones who report to him.  These are  usually the ones who own the divisions — they're the ones who are actually affected (or 'inflicted') by bad decisions as a result of poor rules.  So we've identified those particular people and set up a governance structure where they are the initial ones to make the call on their particular rules.  We do an impact analysis that goes to them to help them make the particular call.  Eventually we think they'll gradually delegate that down.  So that's another approach to getting ownership.

How do you break up the silos?

[from the audience]:  I work for a very large enterprise.  At the enterprise where I worked before this one, I remember I was in a meeting once and I got completely exasperated with all the silos and I stood up and said, "Doesn't anyone here care about the enterprise?!"  And a guy way in the back, in a very small voice, said, "I think the CEO does ... but I'm not sure." So I'd like some advice on how you break up these silos.  Does it take a Mussolini to get the trains to run on time?  Or is there some other way?  Do you use a stick or a carrot, or both?

Chris Collard

I think this is very pertinent because those silos that business rules address are also in the way of successful rule implementations of EDM.  So, yes, I think you do need a benevolent dictator.  I think you do need somebody going in there, breaking ties.  But this also needs to be a well-informed person.

What we've done is invite in third parties who say, "We just want you to listen to this presentation for awhile."  And some of that third-party sales can have a positive influence. 

It very much helps if you have, at the head of your organization, somebody who's been there and done that specifically talking up rules — someone who has seen the power of rules ... who understands some of the hurdles and roadblocks.  Those can be the key leaders. 

If you're coming at this from scratch and haven't seen these implementations before, I think somebody's got to get into the ear of the organization's leaders.  Sell!

Mike Freiling

I've got a story about silo-breaking that I think will illustrate some critical points. 

A number of years ago I was working on a project where we were installing a system in Baltimore.  We were running on top of an old Ingress database.  And our system, which normally worked pretty well, was just bogging down.  It was very slow.  We couldn't for the life of us figure out what was going on.  We suspected it was the database, but the database guy (who was from the client organization) kept assuring us that everything was completely cool with the database. 

We were about two days from the time we had to leave, and we were getting desperate.  I finally told my counterpart, "Okay, we're going to split the labor tonight.  I'm going to stay here all night and see if I can get the thing to run fast.  I want you to take the database guy out and show him a great time in Baltimore."

The next morning the database guy remembered some things he could try that he hadn't tried yet.  And we got the thing running on time ... before the end of the next day.

The lesson I took from that is that silo-breaking is a root-level, person-to-person activity.  If you ever have to get the executives involved you already have a problem that the executives probably won't be able to take you over.  It's that person-to-person relationship across the boundaries that helps break down the silos.

Andrei Mitran

I have one approach that's a little bit unorthodox and not highly recommended but, in one of the meetings, I couldn't get the end users to make a decision so I said, "Well, if I don't get a decision out of you, I'm going to make up the rules and you're going to live with whatever I make up."  Lo' and behold, they couldn't decide.  I implemented the rules and eventually it did force the issue because they decided some of the rules were right and some were wrong.  So it did force the issue by "if you can't decide, I'll decide for you" ... but you need to have some marketable skills just in case it goes badly.  <laughter>

Chris Collard

I would just add to that that I think one of the real dangers of silos is the fact that things get locked in there ... execution gets locked inside of the silo so that you don't get a clear view of the execution path.  Even the subject matter experts who really understand the business don't have a voice.  To break down silos they come up with these large banner projects — these FY10 initiatives — that are larger and larger, with the small pieces buried inside.

The challenge of those big banner projects is that they run against the silos as well and suffer the same execution lock.  It's better if you can get your organization to start knocking off the smaller things ... to really avoid efforts to bannerize these initiatives, but to say instead, "What are some areas we can take off the table?" 

Someway do half a dozen or so of these small initiatives.  Whether you put them in a maintenance bucket or as a fast track project, the world then starts to look a lot clearer.  The silos naturally dissolve.  But they certainly don't dissolve with large banner initiatives, in my experience.

Glenn McIntosh

One of the things you have to do also is, from the business perspective, to figure out a way that business rules can make operations more efficient, either by generating revenue or by reducing costs or whatever.  Once the business people see a business case for it, few of them are willing to just pass that by. 

But once again, it takes a lot of work on your part — some due diligence and some hustle to get out there, to get in front of some of these things and say, "This is a perfect opportunity for a business rules engine to come in ... to save you a lot of money, to grow the enterprise." 

Once you do that I think a lot of the silos begin to go away because there's a real reason to use the engine.

What kinds of metrics do you use?

[from the audience]:  What sort of in-process measures have you seen that indicated that your capture and implementation was working ... or, conversely, that it might not have been working?

Glenn McIntosh

Metrics are key when you want to measure success.  You have to look and say, "What is going to constitute success?"  With our first application it was a champion/challenger kind of situation, where we knew what success was, in terms of the pricing engines that we had.  We essentially took this application and set it up beside the 'champion'.  And we found that our application outperformed it, not just from throughput and efficiency but also accuracy.  At that point, you have your metrics.

Mike Freiling

I'd like to add this:  It's always important to keep in mind, when you're doing a business rule project, that you don't know what you don't know.  In other words, there might be conditions or business issues that you will want to cover that are lurking outside of your sphere of visibility, and no metric will capture that ignorance of what's beyond that horizon.

Usually what that means, in the early scoping stages, is that you have to put in an extra effort to try to extend that horizon as far as possible ... to try to figure out what things you might not have been told but that you'd really like to know now, rather than later.

Chris Collard

That's a good point.  We had our business really wound tight around the 'seventeen fields' that they had seen in the legacy system.  They weren't focused on the thousand that we're delivering them around the new rules engine.  So if you're just focusing on, in this case, the seventeen you're going to miss a lot.

Kelly Karlen

I would have to agree with that. 

When we were looking at putting in some of our rule engines (and, specifically, the Claims rule engine that we started off with) the executive directors originally wanted us to get this done in three months.  That's what the vendor said we could do ... that we could hook it into our legacy system; we could get rules built; we could get results, all in three months.  It took us six. 

Still, that's not a terribly large amount of time, but we really, really did due diligence.  We didn't just focus on the fields that we knew about already.  We said, "Boy!  What are all the opportunities that are out there for us now?"  We wanted to make sure that we built the framework so that, in another two or three months, we would not be going back to IT and saying, "Well, now I really need this."

We put the effort into thinking things through up front.  And in the end, we ended up with a product, in production, where we only go back to our IT shop once a year when the vendor releases their new version.  We have taken our time to say, "Here are the new things that we've come up with since last year that we now need access to."  We're not coming to them constantly. 

So it's not just that we've had the pass rate — we've surpassed the pass rate that we were looking for.  The quality?  Millions and millions of claims — no production errors, period, out of our system.  So the quality, the pass rate, great ... but it's also being really self-sufficient; I don't have to go to the IT department, ask for system requests, and wait for three months to get through their SDLC.  We can make the changes and make it happen.

Gladys S.W. Lam

Great!

Do you have a governance process?

Gladys:  I know the topic of governance will come up.  Do any of you have a governance process?  Can you share how that works for you?

Chris Collard

I know there were some moans when I mentioned challenging existing project methods that are in place.  And what we've implemented around governance and controls is probably even stronger than anything that's been in place before.  We're challenging the notion of "we're just going to leverage an existing infrastructure" versus "we're going to evolve this for business rules inside the existing infrastructure."  So we have controlled self-assessments.  And we do also leverage our IT project methods for rolling out these changes.

Mike Freiling

About four or five years ago I was working with the Oregon Public Employees Retirement System, and we put together a governance structure where we were treating the rules as assets, independent of any implementation.  The rules were on paper, and we trained a group of people to write the rules up.  That group was across all the different functions of the retirement system.

The governance was that we would have meetings to approve these rules.  Delegates were assigned from each of the business functions, and each delegate could vote 'up', 'down', or 'sideways' (which was:  I don't know/care enough).  We had definite approval rules, which were:  You had to have either all ups or sideways; you had to have at least two ups; if there was an ownership organization they had to be up (they couldn't be sideways).  The rules were explicitly approved by a committee that was representative of the entire organization.

Now this happened before there was any effort to install a business rules engine.  But what was really interesting about this effort was:  After we got it up and running, and we were working on the pension plan and slowly capturing all the rules of the pension plan, the legislature came in and changed the pension plan.  And the vendor that was selected to come in and build the system for the new pension plan said, "How in the world are we going to capture these new requirements?!"  After all, the legislature decided this in August with a January delivery date, if you can believe that. 

What we did is that we took this team and said, "Take the legislative documents and start capturing the rules from those, just like we've been doing for the last plan."  We were able to do that; we were able to help the vendor meet their date because we had this team that was managing rules as an asset and an approval structure that was getting approval across the organization.

Gladys S.W. Lam

So it's because of the infrastructure that's already there...

Mike Freiling

Yes, the infrastructure for the rules themselves as assets was already there.

What should be in place before starting a business rules project?

[from the audience]:  For organizations that are looking to implement a business rules project, are there any precursors to the project that you would recommend? ... both on the infrastructure side and on the business process side.  What things should already be in place before moving forward with a business rules project, to make it more successful?

Kelly Karlen

And when you say 'business rules project' I assume you are meaning the automation part of it.  Is that what you mean — the automation of the business rules?  Yes?  <agreement>

It's actually been a culture change in our organization to get our project management office to stop and think about what it is that the business needs to have in place.  What is their 'homework' before bringing a project idea over to IT?  Typically, what happens is that the business says, "I have a problem.  Here's my idea.  IT, fix it for me."  And then IT spends a lot of time trying to figure out what it is that the business is looking for — what their processes in place are — so that they can understand what that solution should look like.

What we have been promoting ... what we're getting our project management office to adopt is — from a business perspective — you have to have your processes documented and your business rules captured before you get to bring it to our capital funding board.

Those two pieces have to be in place.  They take time; they take effort.  You cannot just sit down in a Joint Application Development session, have everybody dump their thoughts out on the table, and hope that you capture everything.  You need to figure out what the processes are — what the activities and the tasks are — to get toward that automated effort.  Without those pieces documented, something's going to get forgotten.  We jokingly say, "It's warranty if you live on the business side; it's missed requirements if you live on the IT side."  <laughter>

Dale Owens

That's probably how you keep your scope in check.  You said you were good at documenting scope up front.

Kelly Karlen

Yes, definitely!  That's one of the things we look at when we're looking at process guidance rules:  Give me the process that we're trying to work within the parameters because that's what you're going to focus on. 

If your scope is too big ... for one thing it's really hard to achieve anything.  But for another thing — from a rule analyst perspective — they don't feel like they're ever getting to the end of their project.  You need to have small slices that you can build upon and reuse on the next piece. 

This even applies to our product/service rules.  We talk about our benefit categories, which are the kinds of products and services that we offer.  For example, durable medical equipment (DME) is huge — it's massive.  Well, wigs (and believe it or not there are lots of rules around wigs!) ... if you can take that small slice and develop the rules around that, you're going to have reusable rules — what we call 'umbrella rules' — that apply to all DME.  So for the next slice that you take, those rules will be reusable going forward and you continue to build upon those. 

It's small slices at a time, so that you aren't biting off so much that you never get to the end of the project.

Chris Collard

I would just add to that — doing it again — look at data availability, data standards, going in ... not as part of the project but as a precursor to the project.  Also the environments:  the robust testing environments, the development environment, the performance environment.  You need to understand how you're going to move through those, what those look like, are they prepared for a rules environment? 

Another big piece is a change management office.  This change can be disruptive ... for the positive.  A lot of the burden of change management often falls on the project management office.  I would set up a separate change management office, especially for organizations without rules environments.

Top-down or bottom-up — which works better?

[from the audience]:  My question is related to the implementation of a business rules strategy on an enterprise scale.  I know the most prescribed approach is "think big — start small."  But there are some practical challenges — for example, if you start with a top-down approach, you have opportunities to have common standards and governance up front, and then implement the projects for particular applications.  But the reality is that all those silos within the business have different business priorities.  So in reality, not all the applications are ready to implement the business rules strategy at the same time.  And that might disrupt things like getting common taxonomies / common vocabulary across the organization. On the other hand, starting with the bottom-up approach lets you deal with those applications or areas within the business that are ripe now for the implementation of business rules strategies; those can start immediately.  However, the opportunity of having a common vocabulary or governance or standards is missed in that approach. In your experience, what you have seen work better?  Or is there some middle ground that is suitable for most situations?

Andrei Mitran

I'll take a quick stab at that.  One of the things that I've found important is to have a common vocabulary.  And that common vocabulary has to be global in scope — it can't be departmental.  One department calls something 'A' and another department calls it 'B'.  Until you can standardize a vocabulary that spans the organizational boundaries, you're not going to get very far.

You have to have both a global approach and a local approach.  You have to have your global vocabulary; you have to have an understanding of the processes in the business at a very global scale, so that you know where you're going and you know what your target is. 

But you don't sit there and start writing rules using some sort of stepwise refinement approach on a global scale.  You get your vocabulary — your business objects — understood and agreed.  Then you can move ahead and tackle a particular project that has some defined scope ... that has some business ownership.  Done that way you will get some successes.

So, I'm advocating that you have to do both — you can't just start small and you can't just start big.  You actually have to attack the problem from both ends.

Chris Collard

I agree one-hundred percent.  The focus on definition and that benevolent dictator to enforce some of those definitions or break ties — absolutely critical!  Without that, you can't move forward with the knowledge transfer that needs to take place.

Kelly Karlen

We take a hybrid approach.  We take a project that's been assigned to us with a defined project scope and within that scope we've got our SMEs.  We work with them to figure out what the terms are, what the definitions are.  We use the fact model approach, with the Proteus methodology, so that they can actually have that visual representation of their terms.  With that we get them to agree at the project level.

Then we get them to do a validation in a cross-functional group that's been put in place.  This is a group of twenty-three, representing just about every division in the organization from the business side.  We work through making sure that what was defined at the project level is going to work enterprise-wide as well.  This way the work we've put in from that project is now reusable on the next project. 

So this is our approach ... the process we take in order to get agreement at the enterprise level:  Get the agreement in the project.  Then, bring it to the workgroup that's in place for the validation sessions; make sure everybody is in agreement.  If we have problems with agreement there, we get everybody's input; we bring it up to a steering-level committee that's at the director level.  Typically, we can get resolution there.  If we have to escalate further we've got three Executive VPs who have been assigned to help ... to be that tie-breaker.  But typically the things that go up there are not "Does this term mean this or that?"

It's when we get into our rules that we start getting into "What do we want our rules to be here?" ... because maybe we have some conflicting values in our organization.

What tools do you use to document your rules?

Gladys:  I have a couple of questions back here.  We're coming down to the last five minutes.  So here is one question that was slipped to me on a piece of paper.  Somebody from the audience asks:  What tools do you actually use to document your rules?  How do you document your rules?  Do any of you want to comment on that?

Dale Owens

We recently purchased RuleBurst as a tool to author, test, and validate the rules.  But we really capture them in a spreadsheet.  That's proven to be also the most effective way to communicate it to our business customers, in particular. 

Kelly Karlen

We have been using the RuleXpress application, from the business knowledge side, for almost two years.  That's proven very effective for us.  It does some of the analysis that we're looking for, as far as which terms are used in which rules; it helps us to be able to do some of that traceability. 

Our properties do some of the management around who owns which rules, and which areas are using which rules, which applications are they being used in ... which processes.  So there's a lot that we can do within the application.

We use RuleSpeak; the tool is built to help support that a little bit.  So the semantic quality for us is being supported that way.  It also helps us to be able to integrate our methodology with the tool functionality.  As it grows bigger across our organization we get more people saying, "We're going to do rules too!"  With us being able to manage at the enterprise level, we can make sure that everybody's being consistent in the work that they're doing and what they're bringing into the application.

What kinds of things do you want to trace your rules back to?

[from the audience]:  I was hoping to see if we could get a list of potential options for things you may want to trace your rules to.  By this I mean:  If you update a rule do you know what else needs to be updated?

Kelly Karlen

I can tell you that we trace our source documents.  I want to know where my rules came from:  Was it from somebody's head?  Who was that person?  When did they make that decision?  What authority did they have?  Was it out of an actual piece of documentation?

A big thing for us is the government.  Medicare recently opened up Medicare products to commercial types of insurances ... to be able to process those kinds of claims on behalf of Medicare.  They have a lot of rules!  I want to know where, specifically, out on the CMS website that came from so I know, when it changes, that I need to make changes as well.  And if it came from an application — from an in-house system — I just need to know where it was.

Glenn McIntosh

We've adopted a process where any new rules have to come in through business requirements.  And those requirements are then fed to the rule-writers and to the testing teams simultaneously.  So the rule authors are formulating the rule while the testers are figuring out how to test it.  Once it's rolled into a non-production environment to be tested then the requirements are validated by the testing team to see, based on the requirements, did it meet the objectives?

It's not an automated process as far as what we're talking about here with requirements being traced automatically to the rule.  But it is through spreadsheets and through our change management process.  It is all documented.

Denni Harp

Basically, for us it's up to the rule author.  In some tools you have the ability to capture comments, but that's exactly all they are ... comments.  It's freeform text.  There's very little standardization or rules around keeping track of how you authored those rules or why you authored those rules.  We rely on spreadsheets a lot, and it's less than ideal.  It sounds like some kind of niche product market to me!

Gladys S.W. Lam

I think the question is no so much on what tool you're using but if you had any tool, what would you like to trace?  So I've heard three so far — any others want to jump in?

Mike Freiling

In that Oregon First project that I was talking about, we would trace the rules back to both the legislative documents and to an intermediate document called "The Oregon Administrative Rules."  We would provide the citations in the paper rule description. 

Then we got into the business of publishing our rules on the intranet so that other people around First could see them.  We did hypertext links so that when you are at a particular rule and you want to see what the legislation said you can go right back to the legislation.

It's a little bit time-consuming to develop a system like that but very effective for your users.  They can simply click from one to the other.

Gladys S.W. Lam

I have two more questions here and then we probably have to call time.

Do your business users now have a higher stake in managing and manipulating their rules?

[from the audience]:  Most of the tool vendors talk about the business rule engines being able to provide a means by which the business users or the subject matter experts have a higher stake in the management of the rules, in the sense that they do not necessarily have to depend on IT as much as before and are able to manipulate and manage the rules on an ongoing basis.  What's the level of your success, and what's your experience in that context?

Andrei Mitran

One of the more interesting ones is the second most important person in the company — an Executive Vice President — actually goes in and changes rules on his own.  So, yes, that person is able to read the rules — it's very spreadsheet-like; it's the Corticon rules engine.  He attended some of the training so he'll go in and look at the rules; if he doesn't like some of the rules he'll just change them ... because he has the ability to make that executive decision on the spot and change the rule.

Of course, we go through a test cycle after he has been muddling with the rules.  But for the most part this has been, actually, significantly successful ... to have someone at that level — a business user, not a programmer— be able to go in and make those changes.  He clearly knows the business better than anyone else and he clearly has the ability to change them and has been successful at doing it.

Glenn McIntosh

We've had a lot of success with that objective.  We use the Rules Maintenance Application functionality in Blaze Advisor, and it works really well.  The users are empowered to make the changes they need to make. 

We do have a change management process around that change control process — testing and validation to make sure they haven't messed anything up.  But they do feel ownership, and I think it's a good partnership ... business and IT.  It's a natural.

Kelly Karlen

We have the same thing with our rule automation.  We have five analysts who are managing thirty to seventy changes that come through our claims environment each week.  They're able to do the analysis to figure out if their event needs to change and, if so, to actually make the change.

We take it a step further.  Earlier you talked about not being boxed in by what your standard software development life cycle is ... to think outside that box and be willing to change to accommodate what rules bring to you.  We spent almost a good year looking at this.  The vendor had told us, "Oh, you can make changes in production."  But we knew we didn't want to make changes in production; business doesn't want to shoot themselves in the foot.  We know we have to live and breathe with the results at the end.  So we spent a good year figuring out what that testing cycle looks like.  We have a two-and-a-half week implementation cycle that includes the unit testing, the integration testing, the quality testing, and then we move into production. 

On top of that we have an additional type of testing we call 'test in production' — we move the rule actually into production but it doesn't execute ... it doesn't change anything in production.  It just gives us the reports that state what would have happened.  We do that review before we actually turn it on.

The people doing the events are the people doing the testing.  Some say, "Oh, you can't have that!"  But these people know the results that they're looking for, and they're not going to put anything into production that's going to come back to them and say, "You made an error."  They're not going to do that.

In two-and-a-half weeks we can get things to move through and be able to make those changes.  Before this it would take us about three months for a system request to our IT department to make things happen.  So it's been incredible. 

Chris Collard

I think an important point was underlined at the "Smart Enough" presentation session, which is:  We're changing these things, not because they are broken or not coded right, but because our business changes and it's going to continue to change.  So the business had better get used to being in the business of managing business rules as assets.  And that's a complex undertaking.  So to look for, or be sold, an "Easy Button" ... I don't think that's where you want to be in this space.

Do you have any hints for bringing the culture of business rules into a company?

Gladys:  We have one more question.  I know that there are a few more but, unfortunately, we're running out of time.  Can we make this last question a really quick one? [from the audience]:  Do you have some hints to bring the culture of business rules into a company?

Gladys S.W. Lam

Quick hint, anyone?

Kelly Karlen

Dedicate resources!

Gladys S.W. Lam

Well, I'd like to say "Thank you so much!" to the panel.  Don't you think they are great?  <applause>  And thank you everybody for being here.  The questions were excellent.

# # #