Panelists

Mark Myers	NCPA (Northern California Power Agency)
Emily Springer	Unum
Ian Cole	Starwood Vacation Ownership
Mukundan Agaram	Delta Dental of Michigan
Kathy Gorman	ICBC (Insurance Corporation of British Columbia)
Kevin Chase	ING
Miranda Shumaker	NCPA

Moderator

Gladys S.W. Lam

Co-founder/Principal, Business Rule Solutions, LLC

Topics

1. What kind of skill set does your business analyst need, to gather rules and to do actual rule changes?
2. In your organization, when you say "business analyst," is this someone who belongs to IT or to the business?
3. How is the stewardship organization structured?
4. Regardless of where those analysts or architects reside departmentally, what is the knowledge or background needed?
5. What strategy do you apply when you have too many rules?
6. What's your feeling on the viability of actually having knowledge captured by your business analysts, who are not in the IT department?
7. What gates do you have in place to make sure that your business community hasn't created new rules (or changed a rule) and you're unaware of it?
8. Have you had a rules project whose primary purpose was to describe what the business was supposed to be doing (rather than to automate some business function)?
9. Do any of your organizations have standardized methods for expressing rules that are not natural English?

.

Welcome & Introductions

[Gladys S.W. Lam]    I'm going to get started because, as I said in my introduction, this is one of my favorite parts of the program.  We really get a lot of interaction, and I don't want to waste any time.

Welcome to the Practitioners' Panel.  Those of you who have been to one of my sessions already know about my business rule, but for those of you who have not, I have to tell you about my business rule.  My business rule is that an attendee who has a cell phone that rings during my session will have to buy me a new outfit.  So, for those of you who haven't heard it before, please turn off your cell phone because this is how I get new outfits.

All right.  First of all, welcome.  There are three parts to the panel this afternoon.  The first is:  I'm going to ask our panelists to introduce themselves, their company, and what they've done in rules projects.  Then, I also want them to give us a couple of DOs and DON'Ts.  After that, I have a couple of questions I like lead off with — to ask our panelists to share some of their experiences.  Then, I will open up the floor to all of you to ask the questions that you have in your mind and in your organization ... things you want to find out from these panelists, who are very experienced in what they've done in rules.

I'm from Vancouver, B.C.  We are hosting the 2010 Winter Olympics, and these are our little mascots.  And, as an incentive this time, for the first three questions, you get one of these.  So, start thinking about your questions, and raise your hand quickly. So, without further delay, I'll ask the panelists to introduce themselves and their companies, and to give a couple of DOs and DON'Ts.  Mark?

Mark Myers

Thank you, Gladys.

My name is Mark Myers.  I'm the manager of Information Services at Northern California Power Agency. 

Here are a couple of DOs when starting a rules project.  The first DO is to hire and train the best business analyst you can possibly find and afford.  The second is:  Make sure you spend enough time up front defining your terms, so your rule-writing goes very, very smoothly.

For my DON'Ts, I would say:  Don't let the business get too involved in the solution.  And don't be discouraged — because it is a lot of work.

Gladys S.W. Lam

Okay.  Emily?

Emily Springer

I'm Emily Springer with Unum.  I'm a business architect, with responsibilities for bringing rules to our enterprise and also for data stewardship and customer rationalization. 

Some DOs:  Adapt the rule methodology to your organization.  Another DO:  Have a rule repository.  And utilize a proof-of-concept when you're selecting your rule repository; that way you know what you're getting.

I only have one DON'T:  When you start with a pilot, don't let it get too big.  Start small.

Gladys S.W. Lam

Okay, thank you, Emily.  Ian.

Ian Cole

Ian Cole, Strategic Technology for Starwood Vacation Ownership.  We're a division of Starwood Hotels and Resorts Worldwide — Sheraton, Westin, St. Regis, and other hotel brands.  My background and education is in both computer science and business.  So, business rules is a fun crossover area for me.  I've worked in the past on things such as HR systems, all the way to the web.  And so, I've seen what can happen when you don't implement a rules system and you end up with fragmented rules everywhere.

From a DOs perspective I would say:  Understand very clearly the resource pool available for the tool that you're selecting.  I would consider many of these still to be niche tools, so you cannot simply pick up the phone, call your local agency, and get someone on staff immediately.  It's a lot better than it was a few years ago, when we started, but you still need to consider that resource pool carefully.

Another DO:  I would talk about 'decisions' with your customers and your internal business sponsors, not necessarily 'rules'.  Rules can have a very specific connotation to people, but when you talk about making a good decision, that's pretty universal.  People get that.

On the DON'T side:  Don't let your techies silo the tools.  What I mean by that is:  Within your technology group, you likely have centers of excellence — you have your database center of excellence, or your Java center of excellence, or your rules center of excellence.  And what will happen is — it's the old phrase, "If all you have is a hammer, everything looks like a nail."  If you're not careful, the tool that gets selected ends up being based on which technologist was assigned to the project.  Have someone that looks across at the different tools so that you're selecting the rule engine for the right type of project.

Gladys S.W. Lam

Thank you.

Mukundan Agaram

I'm Mukundan Agaram, and I'm the Enterprise Architect at Delta Dental of Michigan.  I have over eighteen years of experience in India and in the U.S., with various clients.  I've worked for Microsoft, for Digital, and now I'm the Rules Architect at Delta Dental.

For my set of DOs:  I would say that business rules is about collaboration.  When you're putting a team together, make sure that there's a good mix of business and technical people.  It's very much like putting together a team of highly-skilled doctors and surgeons to do brain surgery, so have your team well-balanced.  That way, you have representation both from the business side and from the technology side ... perhaps even more from the business side than technology because business is where the problems are.

My other DO is:  Get executive buy-in early on.  Educate them about what business rules can do for them; explain the value-add.  You've got to do a lot of evangelism to get their buy-in because business rules, once you've put it in place, is a two-headed monster — business and technology.  As such, in the organization, you need the clout to bring both sides together and to lead it as one effort for the whole enterprise.

As my DON'T:  Don't compromise.  When you're doing your rules projects, make sure that you do the due diligence, build the fact model, because if you do a half-baked job there, guess what's going to happen.  Half your rules are going to be externalized; half your rules are going to be buried.  You'll end up having a lot of open questions, and you won't realize the full value-add.

The second thing, from a technology standpoint, is:  Make sure you are realizing all the important features that are necessary to fully realize the value-add of business rules as a business proposition.  For example, at Delta Dental, we put the business rules entirely in the hands of business people, which meant that they author the rules, they test the rules, they regression test the rules, they analyze the rules, they deploy the rules ... so we get to have a vacation.  <laughter>

Gladys S.W. Lam

That's wonderful.  Thank you.  Kathy?

Kathy Gorman

Hi, I'm Kathy Gorman, and I'm the Manager of Business Transformation at the Insurance Corporation of British Columbia.  We're located in Vancouver, British Columbia, and we provide auto insurance to the residents of B.C.  We have a monopoly on the basic coverage, and we compete on the optional market.

We're relatively new in the rules-approach world.  We're rolling out the methodology with my BA team right now.  I have about forty business analysts that work for me.

Some DOs I have:  Utilize external expertise.  Moving to a rule-based approach was new for us, and having someone come on board to help us with that has been key.

Another DO is:  Have a strong support structure in place to help the analysts learn the new techniques.  We're really focusing on writing the rules and harvesting the rules.  We haven't really gotten into the tooling yet.  We are piloting RuleXpress, but we do not have a rule engine.

For a DON'T:  Don't expect instantaneous success.  My experience is that it takes a long time for people to learn new techniques.

Gladys S.W. Lam

Thank you, Kathy.  Kevin?

Kevin Chase

Hi, my name's Kevin Chase.  I'm with ING.  We've been using rules for almost ten years now ... so, I've made every mistake that can be made.  I've had almost as many successes as there can be. 

Currently my title is Project Director in our Customer Information Technology Services Group, meaning that I'm on the IT side.  When I submitted my abstract, and when I started talking to folks about doing a presentation here, I was a Sr. Vice President in Group Implementation Services, which is on the business side.  However, our business rules writing staff is together, which is one of my DOs:  Keep your rule-writing staff together, in a center of excellence.

One of my other DOs is:  Set guiding principles, to keep people focused.  We call these our mantras; in our group, we say them all the time; we repeat them; we focus them in for new people.

One of my other DOs has already been said here, but I think it bears repeating:  You need strong executive sponsorship, and evangelism is a good word for this.  You really need strong evangelism, both at the grass roots level, which I provided early-on, but also at the executive level, which my boss provided.

On the DON'T side:  I would say don't try to bite off more than you can chew in the first project.  That's hard to do; it's hard to keep things small on that first project.  But it's important to not try to do too much in that first project.

Another thing is:  Don't be afraid to make periodic assessments of where you stand, and don't be afraid to say, "You know what!  We want to make a mid-course correction here.  We're not showing the ROI."  This was the case for us, early-on.  You then have to ask, "Why aren't we?"  Don't be afraid to challenge the assumptions you made in the beginning because, as you learn, you're going to do things differently.  Don't be afraid to do that ... constant improvement.

Gladys S.W. Lam

Thank you.  Miranda?

Miranda Shumaker

Hi, my name's Miranda Shumaker.  I'm at Northern California Power Agency, with Mark.  I'm the only business analyst at our company. 

One of my DOs is:  Define your business language up front.  Once you have a good base of terms, there can be some concurrent work — to start doing some rules and facts, and then go back to your terms.  But you need to define that language early-on so that IT and business can be talking the same language.

You also want to have transparency throughout your organization.  It serves no purpose if I'm the only one who understands the rules.  So, I make it a point to make sure as many people as possible know where the glossary is, at all times.

My one big DON'T, which I've learned from my husband recently, is:  Don't be afraid of the word No.  Shoot for the stars; you'll at least land on the moon.  So, as Mark can attest to, I'm not afraid to ask the developers for anything.  They actually surprise me when they don't tell me "no."  You never know what technology or advancements your technology team can come up with when you give them a challenge.

Gladys S.W. Lam

Thank you, Miranda.

You know, I've facilitated this panel for each of its twelve years.  And I have to say that every time I ask for DOs and DON'Ts, there is always something new.  I always learn something new from the panel, and this is a good example.

I'm going to start the questions.  After this starter question, I will open up the floor for anyone who has questions.

What kind of skill set does your business analyst need, to gather rules and to do actual rule changes??

[Gladys]    I'd like to start with this — something there is a lot of talk about in the Exhibit area and something you guys said here:  The business plays a big role in the rules approach.  In fact, a lot of you are sitting on the business side.  What kind of skill set does your business analyst need, to gather rules and to do actual rule changes?  How difficult is that to ramp up?  How far do you push that?  What's your timeframe?

Kevin Chase

We've had a lot of experience with business people writing the rules.  Our niche — what we use rules for — is for pension calculations.

So, what I look for and what I actually test people on when I'm interviewing is:  I look for strong Excel skills ... I look for people who can write an Excel spreadsheet that I can read.  If somebody comes in and I give them a problem to solve in Excel that's a five-step problem, if they do it in one cell with fifteen different nested-if statements then I tell them to go back ... that's not going to work.  But if they do it in five steps that are easy to read then they're the kind of person I want.

We've actually been very successful in bringing people on board.  We haven't found this to be a hard technology to learn.  What we're more concerned about is:  Will they know the domain?  We're very specialized, in pension calculations, and it's more important for us to have somebody who understands the business problem.  I can make them a rule-writer.  If they know Excel and they have that basic logic — where they know they need to do things in repeatable ways that are easy to read — then that's a good person.

That leads to one of our mantras, which is:  Write those rules as if you own them ... because you do.  I have a slightly less politically-correct way of saying it (which I won't repeat here), but the crux of it is:  Write your rules for readability because you (or somebody else) will need to change them later.

Gladys S.W. Lam

Great.

Mukundan Agaram

There are two aspects to business rules from an analyst's position.  (And Kevin touched on this.)  One is subject matter expertise and how much the person knows about the domain.  The other aspect is the logical thinking part. 

What we noticed is that within our organization we had some pretty strong subject matter experts who knew their subject matter very deeply.  But a lot of the time they got stuck trying to articulate the problems in a very logical manner.  So, I agree with Kevin that once you find your sources of knowledge you can corral them and then it's a question of rubbing skills onto them. 

This is something I mentioned in the panel last time.  Once you put together a team there's a certain rubbing off of knowledge.  With your subject matter expert you can rub off logical thinking capabilities, logical modeling capabilities, onto them.  And you also get to learn a little bit more about the subject matter domain, to be able to push and contribute in that area.

Gladys S.W. Lam

Good.  Mark?

Mark Myers

Typically, rule authoring is thought of as being something of an individual effort.  We've used RuleXpress, and we got, finally, the rules being written as a real team effort.

Then, I saw something on our last project that surprised me.  After writing the rules, the team would have a meeting.  IT would be in the meeting, along with the business and the managers and other analysts.  They would all go through the rules, and there would be lots of discussion because they were interpreting policy — exactly how that rule should be written (worded).  Then, when it went through the test cycle, they would all meet again to see if it really did work.

So, we had an iterative approach ... it really was.  All along the way, there were additions to those sets of rules, to really refine them.  And the end product was far superior to anything we could have hoped for.

Gladys S.W. Lam

Okay.  Does anyone have a question?  Oh, I see we've got three.  I'll go one at a time, and since he's the first one, he gets to pick the first mascot.

In your organization, when you say "business analyst," is this someone who belongs to IT or to the business?

[from the audience]    My question is:  In your organization, when you say "business analyst," is this someone who belongs to IT or to the business?

Miranda Shumaker

Several years ago, when the business analyst was in IT, there was one gentleman (who has since retired) that everything needed to go through — he was the only one who wrote things down.  He was an IT person, but he dictated to the business (Settlements) how they should do their business.

In the past few years, there has been a shift.  That's when I was hired.  I'm actually on the business side — in the Settlements Department.  As such, I represent the other Settlements analysts as 'the business', and they own the rules.  I interpret the rules for them, and I work closely with IT.

Ideally, in a big company, I feel you should have a business analyst, who represents the business, and a systems analyst, who knows how to write system rules based on the business rules, because they are slightly different.  The two of them would work together.  But our company is small, so I am in the Settlements Department and I work closely with the developers.

Kathy Gorman

In our organization, the business analysts are in our own Division.  Over the years, we've either been aligned with the business or in our own grouping.  But we have always been a distinct group from the IT group.

Emily Springer

And in our organization our business analysts are separate as well, under a central program office.  But, again, they have a good relationship with our IT partners.

How is the stewardship organization structured?

[from the audience]    Actually, that was going to be part of my question, but I do have a second half to my question.  Emily, you mentioned stewardship, and that's one thing we're struggling with as we go forward with our new CDI initiative — our new business rules initiative.        How is the stewardship organization structured?  I understand that it probably varies from business to business, so maybe in some cases, it's an IT function.  But for you all, is it primarily a business function?

Emily Springer

I can certainly share how we are set up.

We do a lot of work with customer rationalization in our hub, which is a centralized warehouse for customer information.  We have a data governance council that is at an executive level.  Beyond that, we have a partnership between IT and the business.  Data stewardship is under me; there are four data stewards.  They work very closely with a set of five data analysts, who do all of the real querying and the heavy SQL work.  The data stewards are the ones that interact with the business.

Also, in each area of our business, we have a 'domain' data steward.  When something is wrong, my data stewards reach out and contact that domain data steward, who is the one who fixes the problem in the source system.

Does that help?

[audience]

Yes, it does.

Mukundan Agaram

At Delta Dental, being a dental insurance company, a lot of our business analysts come with deep knowledge of dentistry.  For example, at the last Forum conference, Dr. Rogers (my business counterpart) was with me.  He's a dentist by profession; he became the director of professional services, and then he worked with me on the business rules effort. 

Initially, we're trying to mine out all the adjudication rules around dental procedures:  cleanings, tooth, and other dentistry-oriented rules.  The people we need for that effort are few and far apart, so we try to identify people with logical abilities and learning capabilities and expose them to dentists slowly, pairing them up and bringing them up to a level of expertise.  So, it's a question of harvesting analysts, in addition to having in-house resources.

Ian Cole

I can give you a suggestion on getting started. 

Our governance came predominantly from compliance and security efforts.  With PCI, Gramm-Leach-Bliley, HIPAA — all the different regulations that are out there — it's pretty easy to make the case that you have to be looking at things from a data perspective.  Then, once you start that process of thinking about compliance and security, you can bring in standardization.  It's easy to bring 'rules' in at the same time. 

So, compliance and security can be a driver to help you create that call for change.  Traditionally, a lot of those things are relegated to IT, with somebody hoping that the CIO is actually thinking about it.

Gladys S.W. Lam

Okay.  Great.

Regardless of where those analysts or architects reside departmentally, what is the knowledge or background needed?

[from the audience]    My question is a twist on the first one.  Rather than the place where the business analyst resides — in terms of business or IT — my question is more from a skill set, role, and experience perspective.  Emily, you're a business architect.  Kathy mentioned having business analysts.       Regardless of where those analysts or architects reside departmentally, what is the knowledge or background needed?  In other words, when you're an architect, are you targeting a skill set that's different from business knowledge?  And likewise for business analysts.  Can any of you address that?

Mukundan Agaram

That's an excellent question.  Let me try to throw a slight twist into it.  I've noticed this quite a few times in the past:  If you're not a technical person, you are a business analyst.  In our organization, we have a lot of people who are "business analysts" ... but not quite.

In an organization, this is a typical tier-type thing that tends to happen.  And that's where the challenge is.  You start off your team with true business domain expertise, right?  A lot of time, business rules projects are trying to solve a complex problem in two dimensions.  There's a domain complexity (knowing the domain) and then there's a technology complexity.  You try to reduce the technology complexity by bringing it down to one dimension.  Build a vocabulary, and then you stack the dimension so you have a problem of one dimensional complexity.

Once you have achieved that, a lot of the business analysts you try to select are the people with the logical thinking capabilities and some amount of domain expertise.  You work to try to improve them.

Does that answer your question?

[audience]

I appreciate your response.  What I'd like to differentiate is more between Emily and Kathy, in terms of your teams and how you might differentiate a business architect from a business analyst.

Emily Springer

I can help you with that.

As a business architect, my responsibility is to architect our rules solution and the methodology that's coming into our organization.  We still have business analysts who are doing all of the rule-writing.  I am guiding them and helping them architect the solution. 

I think our organizational structure actually sounds a lot like Kathy's.  We have a program office, and within that program office, we have domains for each area of our business.  Each of those domains has a series of business analysts who have been trained to write rules.  (Actually, we are in the process of doing this because we're really just now rolling things out this year.)

Skill set-wise, we're looking for analytical ability.  We have pinpointed people in each domain who show particular aptitude for writing rules.  Those we are calling the "domain rule analyst" (similar to the data stewardship model).  They're there as mentors and coaches for all the other BAs, to help them as they're learning this new methodology.

Gladys S.W. Lam

Great.  Emily, can I ask one more question?  Do those business analysts actually change rules, in the rule engine?  Or do they write the rule and there are still developers who make the change?  And if that's the case, do you have a vision of moving that toward the business side?

Emily Springer

They write the rules.  Right now, this is in spreadsheets (I'll just tell you all that).  But we've just purchased RuleXpress, and we're piloting it, with great success.  Today, though, the analyst writes the rule, puts it in a spreadsheet, and then it's lobbed over the wall to our IT partners to be put into Corticon, or one of our other rule engines.

Our vision — what we're moving toward — is the analyst being able to enter the rule into RuleXpress.  The domain rule expert (rule analyst) will then review it — get it into a consistent syntax.  Then it will go to our governance body, which is me at this point.  (Eventually, we're hoping that it'll be me and someone else.)  This ensures that the syntax remains consistent.  Finally, it's passed off to our IT partners for implementation in the rule engine.

Kathy Gorman

We're in transition with our structure.  We're trying to move our business analyst to a "professional" business analyst.  In the past, most of our BAs have come from the business areas — they are from an insurance operating environment or a claims operating environment.  That's been great; we obviously honed in on folks who have strong analytical skills. 

But over the years they've evolved into subject matter experts, and now that's where they see their value-add.  We're really trying to change that whole mindset.  While having the business knowledge is advantageous, we're going to be doing some significant changes, moving forward.  That business knowledge will become redundant as we move to new systems and new processes.

So, we're really trying to position our BAs as true domain experts of the business analysis profession, with the subject matter expertise that they have right now helping us through that transition.  Moving into the new world, the exposure they get to the projects they work on will help them develop new subject matter expertise.

But that also means that we're trying to bring our business partners much more into our process — get them much more involved, through interviews and our facilitated sessions and having them validate the output from those sessions.

Mark Myers

I'd like to add one comment.  The focus has been a lot on analytical skills, which is absolutely important.  But I think there's a soft side of skills in the business analyst that absolutely is necessary for success.

Since the business rules approach calls for bridging that gap between IT and the business, it has the ability to literally tear down the walls between business and IT.  And so you don't talk "sides" anymore; you're really one team.  That's because you are communicating well.

So, those soft skills of patience and long-suffering — things you learn from being a mom or a dad — those are just absolutely key in these people.  I would rate those right up there with the analytical skills.

Kathy Gorman

And I totally agree with that.

Mukundan Agaram

What we found at Delta Dental was that, being a dental insurance company, we had good representation of business analysts in areas such as dentistry.  They were actually making the rule changes.  They owned the rules.

But there were other areas, where the early system was a black box.  So, even though the same capabilities existed in terms of tooling, we didn't have any expertise.  We hadn't widened in terms of business analysts.  In those areas, we are now trying to harvest that kind of expertise from those business analysts.

Kevin Chase

I have a couple of comments.  One of the things that we've been successful at — and it's one of our mantras — is:  "Get IT out of the process."  I say that with apologies to my IT counterparts here, now that I'm in IT again.  Now, this doesn't mean "Exclude IT."  What we really mean is:  Leverage developers into what they do well, which is to write code and build tools.  So, our focus is on developers writing tools.  Keep your IT staff focused on building tools because that's fun for them, and it's where they can add value in a rules project ... improving the tool set.

As for the subject matter experts, two of the seven people who work for me are actuaries.  This requires an expertise in terms of understanding that, in order to compute a lump sum, you have to know the mortality (and a bunch of other things).  Our environment may be a little bit unique because it's so specialized, but I do think that's an important point.  You want to really make sure that the business people are adding value where they can add the most value.

The other important point is mentorship.  Something we do, in terms of mentorship, is inspections.  Again, it's one of our mantras:  "We need to bring everybody up, not tear them down."  When you're inspecting somebody else's rules, you really want to do that.  We have had tremendous success in using business experts — people who understand the domain.  Apparently, I haven't had as much trouble as other people on the panel in terms of needing another skill set.  It might be because if someone has the domain expertise in 'pension' they already have the logical thinking skills.  So, I probably am lucky in that regard. 

What strategy do you apply when you have too many rules?

[from the audience]    I have a question on the business rule management.  I think that, at some point in time, you get to a stage where you have too many rules.  My question is:  What strategy do you apply to get rid of rules?

Mukundan Agaram

That's an excellent question.  I'd like to take a shot at it.

Let me share something that we did at Delta.  There was an area of rules that was originally 50,000 lines of code — a big program.  We had a subject matter expert who knew that domain well.  Collaboratively, what we did initially was mine out about 800 rules, and soon we were harvesting more.  It was getting up to about 1600 to 2400 rules, in that one area alone.

But then we took a step back and analyzed it.  Almost always, if you structure your rules project correctly — partition it in terms of the decisions — you will end up reducing your rules.  And that's what happened. 

When we separated out the consults (the decisions) to be made, we ended up with about 40 rules, with orchestration changes that the rules could drive with the workflow.  Basically, these give guidance to the workflow, saying, "Now execute this set of rules."  So, orchestrating and separating out your decisions helps you reduce the number of rules.

And you're absolutely right.  You always strive to reduce the number of rules.  But you won't get it right the first time around.

Mark Myers

I guess I would answer that just a little bit differently. 

When you look at your business, the rules that you have there provide a constraint in the business.  It might be that you need every one of those rules in the business to make the business work. 

Now, if you're talking about having too many rules because you designed it wrong and you have duplicating rules, that's a different problem.  I would want some clarification on that.  Is it that you have too many rules (from a policy standpoint) or that when you designed it there was a poor design?

[audience]

What I had in mind is that each rule has to be executed in the enterprise, and executing a rule costs effort.  This effort is also an enterprise effort.  So, I'm wondering if you have a strategy to say, "Okay, this rule is in fact an enterprise rule, but we don't want to spend the effort to execute it."

Mark Myers

Okay, so that's a really different question. 

We've challenged that lately.  That's how you make money.  Every time you put a constraint in, that's going to cost the business something.  So, if you want to make loans but you're only going to make loans to people who have credit ratings above 800, you may not make many loans, right?  It's all about where your tactics go in those rules. 

I think that's a different question — one that's about policy and setting policy.  I know Ron Ross has articulated many times that fewer rules are better than a lot of rules.  Rules do cost money.  You're absolutely right.  As they creep into the business you might be doing things in your business that you don't necessarily want and that are costing you money.

I think one of the real ROIs in the rules approach is:  Once you have these rules externalized, you can analyze them.  And you can start asking these really good questions:  "Why are we doing that?  Maybe it's just time to stop."  You'll make money by doing that.

Kevin Chase

One other point I might make, perhaps because I've been around in the rules environment for a long time:  The technology has improved so much from when we first started.  There were no decision tables when we started.  For some of our older clients — whose pension plans we have administered for many, many years — we're not using decision tables at all.

What we find is that it's not so much an issue of changing (or reducing) policy — we have policy forced on us.  The law is the law.  But we do periodically go through the rules, and try to analyze and say, "Well, we've written eight rules to do this but that was in the old days.  Maybe we can do that today with a decision table."  Yes, under the covers it might still be eight rules.  But, from a transparency standpoint — an understandability standpoint for the business — for the business operations units to see that rule as a decision table is probably a better way to go.

So, that might be an approach for you.  It might not reduce things from an execution standpoint, but it would increase your efficiency and increase your transparency of rules, which is a very big topic for us right now.

Mukundan Agaram

A point I would like to add is:  In spite of all our efforts to keep rules optimal — to reduce the number of rules — there are going to be areas where you'll have a flood of rules.  That's purely due to combinatorial reasons.  So, the one thing you can do to mitigate that is through good validation functionality (testing) and good reporting functionality.  Provide analysis reports and spreadsheets because that's what the business analysts need to be able to manage a vast number of rules.

What's your feeling on the viability of actually having knowledge captured by your business analysts, who are not in the IT department?

[from the audience]    First off, I'd like to say that it's been a fantastic conversation.  I'm really impressed by the way you've covered the material and have mutually reinforced each other.  There are quite a few things I'd like to ask questions about.  A transcript of this would be quite valuable for those of us who might be interested in exploring further the things you're saying.       One of the things at least four of you were explicit about was the intuitive capture of business logic in English.  But then I was a little concerned when I heard Emily talk about the fence that that has to go over to get it expressed in a vendor tool.  Not only is that inconvenient, but it actually introduces some risk, and certainly a cost.       When we look at so many vendors saying that they offer products that make it easy for business people to author rules and we look at standards like SBVR — and tools that support this, some of which you're using — what's your feeling on the viability of actually having knowledge captured by your business analysts, who are not in the IT department?  Can we get to a point where we can put that logic more directly into production, without going through any IT involvement, other than the architecture that supports the execution and reliable testing of the rules?

Emily Springer

Since you said my name, that means I get to respond first, right?  <laughter> 

The lobbing over the fence is not an ideal situation, but it's where we are right now.  Where I hope we'll be — and where I have great belief and great vision that we will go — is a place where our business analysts can write a natural language rule, something that all of our business understands.  And then that natural language rule, written with consistent syntax, will be able to flow from our rule repository into our rule engine.  So, we will be putting it into the hands of the business ... not without some constraint; not without governance; and not without partnership from our rule developers.

My belief is that we will get there.  When I was researching which rule repository to purchase this year, I looked for that.  I looked and looked and looked.  I looked at many of the vendors that are here; they came to visit Unum.  And it doesn't exist, today, in a way that allows our business analysts to write in true natural language. 

So, there are some compromises.  You could potentially make it work with some products out there, but it isn't exact.  We decided to stick with RuleXpress and use it in a way that we could have our analysts write in natural language.

Mukundan Agaram

Let me add to that.  Yesterday, there was a very good session by Rik Gerrits and the ILOG people, trying to put a buzz on this same problem that you have raised. 

First of all, you can author natural language rules that are production rules — IF-THEN-ELSE statements.  Those are what I call 'operational rules' that you put inside your BRMS and rule engines.

But there are also those high-level business rules, which are sentence forms done with a more formal English.  These are the rules that the high-level business analysts or high-level stakeholders write.  They write business policies and high-level business rules.  Once these are written, they get translated — you author those rules inside your BRMS. 

The problem with having a corporate set of rules and an operational set of rules is that it's not an easy problem to automate.  Your high-level business rules don't always tell you what action to take, whereas a production rule can say, "These conditions exist and this is the action to take," which is more computer-palatable.  To contrast, your high-level business rules get straight to the point:  "A person can have at most three discounts for a given sale."  (Things of that nature.)  However, a high-level business rule does not tell you what is to be done.  So, the problem may be such that you can't have 100 percent round-tripping between your high-level business rules and your operational rules. 

What you can provide is good traceability.  Say your business analysts or high-level stakeholders write high-level business rules.  From those, you can write operational rules within the BRMS and provide traceability back to the high-level business rules.  You can also provide analytical reports that tell you which operational rules correspond to which high-level business rules and high-level policies.  Then, any time those high-level rules and policies are chanced, you can run a report and immediately find out which operational rules are impacted.  Reinforce that with a lot of automated regression testing and you've can mitigate a lot of the risk.

[audience]

Does anyone else have further comments?

Mark Myers

There are a lot of comments that could be made on this subject.  I support what's been said.

I think one of the things that we're hearing, though, is that the big bang for the buck of the business rules approach is definitely on the business side.  We know that not all the rules you have are going to be automated.  There will be rules that you define, as part of your business, that aren't going to go into systems.  And it's also unreasonable to think that all the rules that go into your system are going to go into a rule engine.

So, in your architecture, you're going to have rules in various places, just because that's how architecture works.  The important thing that's been talked about is the traceability.  One of the important parts of that traceability is:  When a rule does fire in an application and it produces an error, the application needs to report the rule, in English form, back to the user.  That completes the round trip, and it takes all the 'mystery' out of the implementation.

[audience]

The real issue underlying the topic is:  How closely aligned is IT with the business?  And how smoothly can the business realize the ROI?  In the answers I've heard, there's actually a conflict.

On the one hand, there is interest in the vision and a hope that that alignment can be tight and the ROI can have no intermediate costs.  And, on the other hand, there is the reality that a tedious, analytic skill set is required to translate a statement that doesn't have an "IF" into potentially multiple IF-THEN statements for execution in a rule engine.

What I don't understand is this:  Are you — practitioners with great experience (and who have made a great presentation) — interested in that vision?  Do you have hope for that vision?  And do you see that as a reality in the current market?

Mukundan Agaram

Absolutely!  That's a great thing to drive for.

Let me make just one comment.  Natural language rules that are operational rules can be authored by the business community — that is what we do.  But here's the rub.  Some of our rules, even though they are production rules and they are in a natural language, are authored by our business users, and that business community itself has different levels of abstraction, different levels of granularity.

Within Delta Dental, there are different levels of abstraction.  If you talk to the highest level — the VPs, the Division heads — they will look at those business rules as very high-level statements.  But if you talk to the business analysts who report to these VPs and Division heads, they get more granular.

So, you'll find that there's a level of abstraction you have to deal with, even though the rules are being written by the business community.

Miranda Shumaker

I talked earlier about defining your language, so I have two parts. 

No, the technology is not here yet.  But in talking to some vendors, I do have hope that business rule repositories will be able to talk to system rule repositories in the future, as long as vendors start listening to their customers.  Some vendors — even some who are here — don't quite 'get it' yet.  Hopefully, they will in a few years.  There are a couple of vendors out on the floor who are getting it.

Stepping back to where we are today, you can define your language.  Granted, we are a very small company — there are sixty people in the office, and I have a very close relationship with IT.  But the important part is that we talk the same language.  Very rarely does the developer that I work with come back to me with questions, because he understands the terms that I'm using.  That's because we have set up our language.  We do use RuleXpress.  We've set up our definitions, and, because IT is so closely related, they have been involved in the definition and development. 

I want to emphasize that, if you have that common communication throughout your company, you will have transparency.  There isn't going to be that abstraction from management to analyst to IT to wherever you are in the company.

What gates do you have in place to make sure that your business community hasn't created new rules (or changed a rule) and you're unaware of it?

[from the audience]    I manage the team of BAs that Emily has been speaking about.  We've started our harvesting by looking at the application code, at any policies that we have out there, and existing project artifacts — just as Gladys talks about — to glean those rules.  After this initial work is done, as IT projects come through, we (the business analysts) will have the opportunity to identify new rules or changed rules.       My question is for the panelists that have a more mature rules discovery methodology.  Outside of that new project work, what gates (or checkpoints) do you have in place to make sure that your business community hasn't created new rules (or changed a rule) and you're unaware of it?

Mukundan Agaram

At Delta Dental, what we did that helped was to provide good search capabilities and analysis capabilities.  By that I mean, for all our rule implementations, we do a lot of rule re-use.  We pick from a pool of existing rules, and we consider adding new rules only when necessary. 

What we do is:  Before they set up new rules, they have the ability to search for rules, by vocabulary, by usage.  Those kinds of reports help them make sure that they don't end up adding redundant rules into the system.

Kevin Chase

Let me take a stab at that. 

I'm going to say something controversial.  If the business makes changes to the rules, then the business makes changes to the rules.  That's their responsibility and their accountability.  If the IT people don't know about those rule changes, it's really none of their business because it's a business rule. 

Is that controversial?  Let me follow that up with what our governance process does, and maybe that will make it a little less controversial.  We're moving into more confidence with our rule changes, so I'll explain our basic process and then our fast-track process.

Our basic process is:  Rule changes are made by our operations teams that support our various clients, based on authorization from the business units.  They'll say, "One of our clients is making a change to their pension plan — they're freezing it.  So we have to freeze the pension plan as of 12/31/2009."  (We're actually doing this right now for one of our clients.  They just told us a month ago, and we have to have the plan frozen by four weeks from now.)

My group makes the rule changes.  Our IT developers then give us a rule change report, which (as part of the release process) authorizes those rule changes — says, "Yes, those were the rule changes we intended to make."  Then we run a regression suite that makes sure we won't be breaking anything we didn't intend to break.  We add unit test cases to that. 

Even when there is no programming involved in a particular change, just rule changes, it goes through the same SDLC in terms of:  inspections of the rules, our regression reports, and a testing cycle.  That rule change report is crucial for us because it is my audit artifact.  It says that I, as a manager, have authorized that, yes, these are the changes we intended to make and no others.  Our regression reports show the changes that happened, and they should be just the changes expected.

We've developed enough confidence in our rule changes that when we have a small rule change — for example, if a client changes their limit for lump sums from $1,000 to $5,000 — we're now doing that with what we call a "service request."  For example, this impacts only one rule, which says, "If the present value of your benefit is less than $1,000 then you only get a lump sum."  That rule would be changed from "less than $1,000" to "less than $5,000."  For this kind of 'service request' change, we get an authorization from the business on a form, and we do a before-and-after picture of the rule for the business.  The business signs off that this is, in fact, what they want to do.  We do a regression to make sure that nothing bad will happen.  (Maybe someday we'll even get away from that, but I don't think so.)  That skips testing entirely, and it goes right to production.

I think we have a much more aggressive approach, perhaps, because we believe the business owns the rules.  Now, when I say "business" and "IT" I'm talking out of both sides of my mouth because I am IT, but I'm also a business person.  So, here, when I say "IT" I mean developers, SDLC ... things like that.  As long as we're following SDLC, the business rules that are changed are the responsibility of the business, which drives the rule changes via requests.

Gladys S.W. Lam

Mark can comment, and then I see there are a couple more questions.  I only have four minutes, so I'll have to cut that short.  Mark?

Mark Myers

I'll make this very, very quick.

In the electrical industry, there are about 640 rules to submit a bid into the market.  Whenever a change happens in that instance, they have to again go through a formal market simulation, to make sure that the changed rule didn't affect any other rules.  It has to be simulated by the market.  This instance has a very formal change process.  So, I think how the change process works really depends on the impact to the business.

Have you had a rules project whose primary purpose was to describe what the business was supposed to be doing (rather than to automate some business function)?

[from the audience]    Has anyone on the panel had a rules project whose primary purpose was to describe what the business was supposed to be doing and, only secondarily (if at all), to automate some business functions?

Emily Springer

We do both.  This summer, when we did our harvesting project, we harvested rules that were primarily about the business and not necessarily to be automated.

Miranda Shumaker

I've also ended up doing both at the same time. 

Ian Cole

Our original use of a rules product was to go back and codify twenty-five years of contractual ownership rights that really were not documented anywhere.  And today, we still haven't automated the majority of them, but we at least now have a fair set of knowledge of them.

[audience]

Do you need a different tool to maintain what you have collected as descriptions, as opposed to a tool that would come on later for execution?

Miranda Shumaker

I used the same tool — I can capture both in RuleXpress. 

Emily Springer

We use the same tool as well — RuleXpress.

Mukundan Agaram

We have a policy capture system, which users use to keep an inventory of rules.  Because some rules are not entirely automatable (or even partially automatable), we need to keep an inventory of our business rules and also a trace with our operational rules.

Gladys S.W. Lam

And, Ian, do you keep all of those rules?

Ian Cole

I would say that, in that sense, we went more for a standard documentation process, without using a rule repository.  On other projects, we've chosen to do the documentation straight in the rule engine, as we were going.

Gladys S.W. Lam

Okay, good.  Now, this is the last question I can entertain — I'm sorry, but time's running out.

Do any of your organizations have standardized methods for expressing rules that are not natural English?

[from the audience]    Thank you.  Let me ask this question as an abstract, general statement first, and then I'll give a couple of examples.       Do any of your organizations have standardized methods for expressing rules that are not natural English?  Often, in the general conversation, we talk about expressing in natural language, which means English.  But there are many rules that are not really suited to that.       Two specific examples:  One would be math.  We're dealing with that in our organization.  For another:  Perhaps in the pension business, you might have special terms or ways of expressing a notion that becomes cumbersome in English.  How do the panel members work on that?

Kevin Chase

On the pension side, you're exactly right.  We have a number of things that you really can't state in a natural language rule.  You can't compute the lump sum value of a life annuity using the government's 2009 mortality tables, 6% interest, and [age] 51 for me and 56 for my spouse.  You don't do that in a rule statement. 

So what we do is this.  We have the IF condition that decides which mortality table to use and which ages to use.  The rule would be written to say:  If you are in the labor union plan and you are over 55 and your lump sum value is greater than 5,000, then set the single life annuity equal to the actuarial equivalent using the (drop-down list) mortality table, for a percent interest of 'x' (drop-down list), with an age for the participant of 'y' and an age for the beneficiary of 'z'.

However, we do write this out in an English sentence because we found that when we did it in a way that looked like a function call (which is what we used to do), that was just unreadable to our operational partners.  So, now we write it out in a very, very long sentence.  (However, this gives us some problems with the tool because the sentence is so long it sometimes scrolls off the edge of the screen.  I'll be talking to my vendor about that!)

That's how we handle it.  It's not really natural English because it's a function that we're calling out to our library of functions to perform.

Miranda Shumaker

Being in Settlements, we have specific charges, which are calculations, that are business rules.  So, we have a hybrid.  I do state them in English, but I'm not going to spell out 'plus' or 'minus' — I do end up with some math.

However, if we have an element that is a data element (a calculation) that is used in various rules, I'll define that as a term.  Then I'll create a new rule and I'll just use it with the other terms.  In that case, that looks more like natural language.

Ian Cole

We built a rule engine that did tax computation.  This was our iteration cycle:  We asked our tax department to express the rules as best they could.  Next, we asked them to build a spreadsheet that did the rules.  We then had the technology team work with the tax department to take the spreadsheet and to build those rules directly in the rule engine.  When this was done, we used the documentation output of the rule engine and asked the tax department, "Is this what you intended?"

Wrap-up

[Gladys]    Now, it's always sad when I have to end this session.  You can see why I say this is always my favorite time.  And to answer Paul's question earlier, yes, this is recorded, and it's being transcribed.  The transcription will be up on our website, so you can follow it.       I'd like to say a special thank you to the panel.  Aren't they wonderful!  <applause>  I am always very grateful to and very proud of the panelists, so again, thank you very much.  And, to the audience, thank you for the great questions.

# # #