The DOs and DON'Ts of Business Rules

Panelists

Mukundan Agaram	Enterprise Architect, Delta Dental
Hani Rachidi	Senior Manager, Licensing Platforms Solutions, Microsoft
Warren Williams	Lead Public Health Analyst, Centers for Disease Control and Prevention (CDC)
Kevin Gauley	Manager, Practice Centre, Insurance Corporation of British Columbia
Nathan Bell	Software Architect, Pharmacy OneSource
Emily Allis-Springer	Business Architect, Unum

Moderator

Gladys S.W. Lam

Principal & Co-Founder, Business Rule Solutions, LLC        Executive Director, Building Business Capability (BBC)

Topics

1. How do you measure ROI or determine the size of a business rules project?
2. Where do you find people with the special mindset for business rules?
3. Did your business rules project yield any surprises?
4. Do you have any DOs or DON'Ts for business rules tools?
5. Do you have any tips for capturing business rules from reluctant SMEs?
6. How much time do you let pass before you go back and refresh/revisit your rules?
7. How do you change the mindset that insists on running all business rule changes through a full change management deployment scenario?
8. How do you get IT to hand control over to the business side?
9. What is your advice for business rule governance?
10. Did you include the CUSTOMER's view of the terminology when you built your vocabulary?
11. What "maturity level" would you say your organization has achieved in the area of business rules?

.

Welcome & Introductions

Gladys:   Good afternoon, everybody.  Thank you for joining me on the Practitioners' Panel.  This is actually my favorite part of the conference.  It's one of the best parts because you don't have to listen to me talk the whole time.  <laughter>  In fact, I have put together a panel that is exceptional this year.  You'll see why as you hear them talk.      How I run this panel is very simple.  First, I'm going to ask the panelists to introduce themselves and to give us a little background on their project on business rules — what they've done in the past — and then I'm going to ask them to give us some tips on DOs and DON'Ts — what you should do and what you shouldn't do.      After that, it's an open forum discussion.  I have a few questions I've prepared, and I can kick things off with one or two questions.  But any time you think of a question jot it down.  Some of you have come up to me in the hallway with a question and I've said, "You know what — that is a great question for the panelists."  So, as you hear them introduce themselves, if you have questions jot them down and then raise your hand when we open up for questions.      For a little incentive I brought four bags of chocolate, all the way from Canada.  These are maple syrup chocolates and they're really good.  There are four different flavors so whoever raises their hand first gets their pick of flavor.  So, get your brain juices going and we can have some fun.      Okay, shall we start?  Are you ready?

Mukundan

I'm Mukundan Agaram, and I'm the Enterprise Architect at Delta Dental.  I've been around the block for quite a few years now.  I've been in the software industry for over twenty years and have had some international experience.  More recently — for the last six to eight years — I've been working in the area of business rules.  At Delta Dental we built the BRIDE System, which has been a significant source of innovation and has provided a lot of positive energy and caused a positive shift in Delta Dental's way of doing business.

I have a couple of DOs and DON'Ts.  My first DO is for people who are just getting into business rules:  Select the right pilot project.  What I mean by that is (typically) if you look at your business and the way you're doing business, there are certain key indicators that very readily let you know that a project lends itself well to business rules. 

The first indicator is whether the project has a strong business need for business rules.  By that I mean that it involves strong regulations or strong contractual requirements.  Usually a combination of these two yields a lot of business rules.

The second indicator you want to look for is the specific area where you're going to target your pilot project — does it have a well-knit subject matter community?  If you have a subject matter community that is small and well knit and if they're really excited about taking over the controls, then you know you'll be providing a positive shift with this new methodology and technology.  That's going to be a big win so that's a battle you won't need to fight.  You're going to be fighting a lot of new things just getting into the arena of business rules so for a first pilot project you want to avoid all the battles that you can.

My second DO is this:  Always look for constant business improvement opportunities.  As Ron talked about today in his keynote, Building Business Capabilities, business rules, business capabilities, and business innovation share a kind of symbiotic relationship.  The better the quality of your business rules, the better will be your business innovation and capabilities.  Always looking for constant business improvement is good for the enterprise.

Now for my DON'Ts.  After so many years of doing business rules one thing I still see is this:  There's a tendency in other parts of the organization to black box rules.  In other words, people see rules as a big black box with a lot of magic and fluff happening behind it.  This happens even though business rules are externalized — they're put into a language that is very English-like and available to everybody.  So, you don't want to let rules be seen as some black box — make sure there's a conscious effort to publish them to all your user-facing interfaces ... all your front-end interfaces.  And make sure you do that quite frequently.  Build lots of traceability into your vocabulary and into your rules.  Make them very visible because this black box effect can be bad.

For my second DON'T:  Don't stop looking for new areas of opportunity.  You may have done a pilot project in one area, but there are so many other areas within your organization that can benefit from business rules — for example, fraud detection.  There are areas just waiting to be exploited ... opportunities waiting to be harnessed.  So, don't ever stop looking for new areas of opportunity.  Constantly evangelize about the merits of getting the business rules approach applied where you see an area of opportunity.  Go talk to the business owners and the stakeholders in that area — talk to them about the business rules approach; talk to them about what merits this approach has for them.

And when you evangelize make sure your message clearly communicates measuring ROI and monetization in terms of business value because that's what they understand ... that's what executive management generally listens to.  If you just say "Hey, it's going to be more productive!" they won't hear you.  But if you build them a monetization value (an ROI value) then you are saying "Hey, this is how much money you will save!"  If you give them clear metrics, their ears will perk up and you'll find them willing to listen to you.

Gladys

Thank you.  Hani?

Hani

My name is Hani Rachidi, and I'm from Microsoft Corporation in Redmond, Washington.  I'm in the area of Solution Management, which is a cross between project management, the business analyst role, and technical product management.  Within Microsoft, we are separated into a few different divisions.  One of our biggest business divisions is called Licensing; it's about a 35 billion dollar business.  That's the business I support, in different areas of enterprise commerce such as the order-to-cash process and the way we go to market with offers.  This is both for cloud-based offers and for the regular (traditional) offerings.

Within Microsoft, business rules is still very much in the growing stage.  The case for business rules and the documentation of business rules is still a somewhat new practice.  My recent experience with business rules has been around optimizing how we go to market with new offers.  As business models evolve, especially with cloud computing, the agility of our IT systems, and even of our business processes, is being questioned ... to keep up with market demands.

Now, more than ever, being able to pivot quickly, in terms of what the market is requiring, is very important from both an enterprise and IT perspective.  So, a lot of experience that I've gained over the past eight years at Microsoft has come from sitting down with the business stakeholders and with operations, and facilitating workshops and documentation of business rules and requirements.  A lot of that time has been around enterprise commerce where we leverage some standard applications like SAP to run our business.  What rules has done for us is enable us to quickly and rapidly deploy solutions in a configurable manner.

With that background, here are some of the DOs and DON'Ts that I have with respect to business rules:  The first has to do with sequence — how do you sequence the work to get to this improved business value?  The sequence that has proven successful for us has been to start with the business process and the user scenarios.  In other words, this comes before you ever use the word 'business rule' or 'requirement' — first, we work to understand what the current process is and where the business wants to pivot to.

For another DO:  I think it's important to be iterative.  As all of you know, harvesting rules — documenting the rules in a way that is agreeable across disciplines or across the organization — takes a lot of time.  If you use a phased implementation you buy yourself time by demonstrating incremental business value.  And don't think you have to get every single rule harvested to start.  You don't have to get it all nailed down in the first go.  As long as you can start somewhere — whether it's halving the time to market for a certain thing or proving out smaller, incremental gains — starting small and having a phased implementation has been successful for us.

Finally, you need to understand the "why?"  Actually you should start with the why — the motivation behind the rule:  "What is the business strategy?"  And, more importantly, what we discovered was the need to ask, "What's the business policy?"  Before you even get into a rule, you need to know what you are trying to constrain or to abide by.  For example, for a legal requirement, what are your business policies around that legal requirement?  Once those are defined you can then break down the business rules that tie to those (or adhere to them).

One DON'T I'd like to mention is this:  A lot of folks try to postpone the conversation about rules and policy because it can be contentious.  Don't do that; don't delay.  Delaying the harvesting of the rules delays the realization of some of the business value because — even if it's an incremental, phased approach — not having the rules defined up front can come back to bite you later on in the project.  So, define them up front — be sure that you get a good slice for the user scenario or business scenario you're trying to fulfill. 

Gladys

Thank you, Hani.  Warren?

Warren

Hello, everybody.  My name is Warren Williams.  I'm from the Centers for Disease Control and Prevention, in Atlanta, Georgia.  This is my first Business Rules Forum so thank you, Gladys, for inviting me.

I work in the Immunization Services Division, and my specific focus is in the area that supports immunization registries or immunization information systems.  We've had a project going on for six or seven years; we are trying to analyze and develop best practices in business rules in our community.  We're bringing people together to build a unified community around certain technical and operational challenges.  In the time this has been going, we've had a couple of successes where we've demonstrated some practice guidelines and have harvested some business rules.  We've been able to publish them and get them used.

My short list of DOs and DON'Ts would be similar to those of my other colleagues.  DO start small and be practical about it.  Start with areas where you can have some early successes with and build on those.

I think it's key to get executive sponsorship for the project.  That's very important.  Also, getting the right subject matter experts to the table is very valuable in pulling off this kind of project. 

In line with what Hani said, DON'T let the naysayers get in your way because they don't want to talk about business rules or because that feels uncomfortable or because they don't see the value.  Being able to document ROI (and other metrics of success) and having evaluation strategies that you can deploy throughout the process are very useful and very valuable.  Start with a mindset that says, "How many can we do?" and "What do we think that impact will have on our operations or business?"  I think those strategies and evaluation measures are very important, at least in my industry, for getting buy-in and support.  That comes from a demonstrated understanding of why this type of project is valuable and important.

Gladys

Good.  Thank you.  Kevin?

Kevin

Hi, everyone.  My name is Kevin Gauley.  I am the Manager of the Business Analysis Practice Center at the Insurance Corporation of British Columbia, which is based out of Vancouver, BC, Canada.

My most-recent experience with business rules projects has been in a mentoring capacity, as the manager of the practice.  I get involved early on in the projects and help the business analysts determine which approach is appropriate for their project.  Then I act as a consultant to them and am there to support them throughout the entire delivery lifecycle.  I often get involved in performing informal quality reviews of business rules documentation.

In our organization we're using a business rules methodology that we adopted about three years ago.  We adopted the Proteus methodology (from Business Rules Solutions) and we've "ICBC-ized" it to our own business rules methodology — we've customized it to suit the needs of our business.  And just recently we've started to use a rule management tool named RuleXpress — you may have heard of it here at the conference this week.

I have a couple of DOs:  DO use a common language to construct your business rules — that is critical.  We use a technique known as RuleSpeak.  It helps enforce some consistency in the delivery of the rules.  It focuses on simple things like ensuring that you use a "must" or an "only" in your rule statements.  This helps to eliminate ambiguity.

Also, I would say that you should use a plain language.  DON'T use jargon when you're writing your business rules.  Try to avoid acronyms as much as possible.  And DO write your rules in a way that's user friendly — something that's understandable to a business person.  These are business rules and they should be owned by the business.  So, hopefully they're in terms that a business person can understand.  And on the subject of terms, it's important to use terms that have been defined and agreed to by the business.  That's key to writing an effective business rule.

For another DON'T:  DON'T overcomplicate things.  The more complicated the rule becomes the more difficult it is for people to understand it and ultimately to own it. 

The last DON'T I have is this:  DON'T write the rules in your own style.  Use a methodology when you write your rules.  You'll have a long-term gain by using a methodology and having a consistently-written rules approach across your enterprise.

Gladys

Thank you.  Nathan?

Nathan

My name's Nathan Bell; I'm the principal Software Architect at Pharmacy OneSource, a Wolters Kluwer Health Company.  My background is (as Joel Spolsky famously said) turning business capital into working software.  So, I'm a computer scientist by trade.  I've worked in a number of industries:  Department of Defense, telecommunications, financial industry, and (the last couple of years) in the medical field.

Within our platform the use of business rules is for a variety of things, but our main use is within our patient surveillance platform.  We apply a rule-based approach to line clinicians to perform surveillance over their patients, in real time, in their hospitals.

In terms of DOs and DON'Ts, I have a pretty long list, but I'll just do two of each.  And I'm going to come at this more from a technical side than some other folks on the panel because that's my background.

In my first point I'll be talking to the person who's looking into doing a business rules project.  You've got some business need that you're going to solve through software and you think a business rules approach is the way to go.  For it to be a successful project, on the business side you're going to convince management to do that, and on the technical side you're going to build and execute some software.  As a software architect my #1 recommendation to you is — regardless of what anyone on the engineering team tells you — DON'T let them build their own rules engine.  Absolutely, positively, without question, don't let them do that.  Buy something, or use something open source.  To someone who's never done it, it can seem, "How hard can it be?  It's only 'If this then do that'."  But it's horribly difficult once you get into the weeds.

My next point is this:  You're particularly excited about the rules-based approach; you've read a couple of books; you went to a really cool conference; you're all fired up; you come back; you want to tell the executives all the reasons why they should use a rules engine.  But when you make the business case to the executives just keep in mind that they don't see what you see.

This is a particular failing of people on the technology side.  I deal with engineers all the time, managing and mentoring engineers.  They get all fired up and frustrated because they've gone to the executive and said, "We should use rules!"  And the executive says, "No."  So, they're mad because they didn't take the time to build the case.  You really do need to build a case and to show the executives the vision of why using rules is going to save them money and reduce time-to-market and be agile.  You can't just say, "I'm a smart tech guy and you should believe me when I say to use rules."  I've learned this from experience.

Here's a point on the DO side:  Related to the theme of convincing the executives, DO find some tiny little way to start small and prove the concept.  Give them something to look at.  It's much easier to tell the tale when you can show them something and say, "Look!  I can change the way it behaves by just adding a new rule.  Isn't that impressive?!?"

Finally, one of the keys to a successful business rules implementation (again, from a technology perspective) — particularly if your organization does not have competency in this area and has never done something of this kind — is to partner with somebody.  Bring in outside consultants; partner and train.  Don't spend your first six months figuring out all the rookie mistakes.

Gladys

Thank you.  Emily?

Emily

I'm Emily Springer, with a hoarse voice now.  This is my third round and there's not a lot left in my voice.  So, you'll have to bear with me, and I probably won't talk as much as I usually do.

I'm the business architect for Unum; it's an insurance company, based out of Portland, Maine.  Over the last three years we've implemented a business rules approach from a business perspective.  Previous to that we had implemented Corticon and a rules-based approach, but we had really gone at it from an IT perspective.  So, over the last three years we've developed a rule repository; we've implemented a syntax, following RuleSpeak.  We've really started managing our rules as a business asset.

To keep this quick, I have a couple of DON'Ts:  DON'T start without a vocabulary; don't skip over that step.  Make sure you have an established vocabulary before you start writing rules. 

DON'T start without governance.  You need to govern your rules if you're planning to manage them as a business asset.

DO start small.  Everybody's already said this.  If you start too big it's overwhelming — especially if you're new to it.

DO look for a business analyst who has that special je ne sais quoi about rules.  The people who are your best rules analysts have something very special in the way their brain works.  You can find that out in your organization.  It's usually people who LOVE to write rules.

Finally, DO have a repository to house your rules.  It will enable you to manage them as an asset (which they are) for your business.

Gladys

Thank you, Emily.

Now, as you can see, we really have a vast amount of knowledge on the panel.  So, take advantage of that, if you have questions. 

How do you measure ROI or determine the size of a business rules project?

Gladys:    I'm going to start off with a question, and this is probably in everybody's mind.  We refer to "ROI" a lot and also "starting small" — so, in your experience with your projects, how do you measure ROI or determine the size of the project?

Mukundan

Can I go? 

Gladys

Sure!

Mukundan

At Delta Dental we started our business rules approach in a very non-traditional area:  claims processing.  We were converting from a legacy system to a modern-day, n-tier Service Oriented Architecture, using business rules and all the latest technology bells and whistles.

One of the areas of claims processing that was very sticky and painful was the area of fillings.  You can imagine:  it's 32 teeth and the filling of teeth — how difficult can that get, right?  Well, in the old system we had this really complex and hairy program with 50,000 lines of COBOL code that had a bunch of different rules in it.  Initially, when we started the mining effort for that so that we could go to a rules-based system, we mined out about 1,200 rules.  But soon we realized that between those 1,200 rules there were a lot of holes.  So, following the iterative approach, we took a step back and we looked at the rules again.  And when we went through them iteratively we were able to reduce them to about 32 rules.

Gladys

32?!

Mukundan

Yes, 32 rules.  50,000 lines of COBOL code down to 32 rules. 

We were able to do that through separation of concerns and a proper orchestration of rules with the process.  Aligning the rules with the decisions — breaking out rules by the decisions and orchestrating the process with the rules — helped us reduce the number of rules.

Needless to say, the savings on that was phenomenal.  What would have taken a few months to get a change in place in the old legacy system can now happen in the matter of a day or even a few hours.  And with everything being so declarative, troubleshooting — looking for performance gains, cost gains, and cost advantages — is also tremendous in the new system.

So, that's one very significant ROI that we were able to see.

Gladys

Great!  Anyone else?

Hani

Microsoft has a presentation on this tomorrow morning but I can summarize here.  At Microsoft, we looked at the whole aspect of pricing and offering products to the market — how we get through that process.  The way that we quickly assessed it in terms of the business value we could achieve was to do Lean value-stream mapping:  we mapped out the processes, and we figured out that most of the activities taking place were waste activities that we could eliminate; only some of them needed automation. 

Very quickly (within the first month-and-a-half), we determined that if we could get to a rules-based approach in launching products at Microsoft — instead of an exception-based approach — we could dramatically reduce the time-to-market.  And it didn't take long for us to actually prove that point.

What did take a long time was harvesting all the rules and constructing them — finding the patterns of data.  It took super-SME knowledge to understand how the business logic was enforced through the data and how to extract rules and systemize those rules.  (By the way, our super SME is in the audience here; her name is Mary and she is presenting with me tomorrow.)  So, that part did take quite a long time.

But we were able to get ourselves a runway with our sponsors by saying, "We took a process approach.  We have the right people to harvest the rules.  And we've got a really good engineering team that can codify those rules in a systematic way." 

You have to have all three; you can't just go at it with one.  And we had enough runway — about nine months to implement.  Now that it's live in production, we're trying to concretely prove that we are getting the value.

Gladys

Excellent.

Warren

We started out fairly small, with a status-type problem that was common in some of the systems we support.  There were a lot of different transition states between different statuses that were either unknown or not unified across the different systems.  So, we began by trying to solve just that problem.  We brought a number of subject matter experts together and went through a facilitated session to create business rule tables and then to use them to identify when to move from one status to another for a particular situation.

This had never been done before in our community so it was very important to be able to do it and still work with the technologies and systems that exist in the state health department networks.  This was a first approach of trying to solve a problem with a business rules mentality while not changing or dictating the software that everybody had to use in order to make that happen. 

One of our big successes early on was in showing that when you take the time to bring the subject matter experts in and to analyze the problem first from a business perspective, instead of a software perspective, it really does have a lot of value that people track.  It was good to be able to solve problems that way.  Our success there helped to keep the initiatives going for other topics.

Gladys

Thank you.  Now, Kevin, do you have something?

Kevin

Even though we haven't quantified the ROI on our approach at this time, there's a general recognition in our organization that by taking all the rules out of people's heads, out of systems, out of policies and procedures — and slowly building up that repository of business rules and managing them as an asset (as Emily said) — that there is going to be a great deal of ROI in future projects and future impact analysis.

Where do you find people with the special mindset for business rules?

Gladys:    Emily and Nathan mentioned that you need a mindset ... you need people to do this work.  Where do you get these people, and what do these people look like?

Emily

Was it last year that Microsoft talked about their test where they ask the analyst to do a Sudoku puzzle?  I joke about that now when I look for a rule analyst. 

I really look for someone who is very analytical — somebody who likes to write rules ... somebody who's good with the English language and who likes to have things precise and complete.

Kevin

From my perspective, I would summarize the skills required into two categories.  There's a technical side of writing rules, and then there's the soft side as well. 

I don't think we put enough emphasis on the soft skills.  There's a lot of interaction with the business so obviously we look for someone who's got strong analytical skills ... someone who has good facilitation skills, elicitation skills (you're listing requirements from the business), strong documentation (a strong understanding of the business language), and good research capabilities.

These are some of the core capability skillsets that we look for in our business analysts who are writing rules.  Until we get to that single source of truth for the rules, rules exist everywhere so we need analysts who can do a lot of research and literature study in order to mine those rules.

Warren

Keeping with the game theme that Emily mentioned, I think that having a very logically-oriented mind is very important.  I would ask them if they play chess in their spare time.  <heard in the background:  Oops! I'm in trouble!>  They need to be able to analyze situations and be able to break down a complex problem into very discrete moves that can be taken.  I think chess players have a lot of that skillset.

Hani

I don't think you have to have one person.  It's a team effort.  What we've found to be successful is that if you have a person who can look at an Excel spreadsheet (or whatever the technology of choice is, say, an SQL database) and really understand 'data' — they like data ... like being in the weeds of data — that is at least one component of it.  We had over half a million rules (or patterns) that we looked at.  We brought that down to about a thousand.  Something like that only takes place if you can gyrate pivot data pretty well.  That calls for someone who likes that kind of stuff.  They have to have a thirst for data.

Complementing that is having a person who has a thirst for documenting ad nauseam, with proper RuleSpeak-type conventions, in Word or Excel.  You have to document what a rule really means so it can be socialized. 

It's hard to find both the data intensive person and the person who can write eloquent rules in one individual.  If you do have that combination in one person, let me know who that is because we will hire them tomorrow!  Being able to build a partnership or a small team that can do this role is more realistic.

Mukundan

I'd like to add a couple of points.  First of all, building a business rules team is like building a surgical team.  On a team we have a heart surgeon, an anesthesiologist, a couple of nurses; we have the person who's taking care of the equipment, and so on. 

When you get into a business rules project, you first need to identify the strong subject matter experts.  Make this team strong and cohesive, and you'll find that some of the skills start to rub off on each other so even if your subject matter experts are not tuned to think logically, when they start interacting with those who are, you'll find that they start to break down problems more logically.  That's what happened in our case and that was really good.  I even started to learn about real dental procedures.  (You wouldn't want to hear what some of them are!)  It really helps to build that team that is a diverse population and have them work together.  Over a period of time you will see talent emerging.

Once that happens then the second part is to build that culture — to start identifying other people in the organization who might be potential talent.  Pair them up with these people.  That's how we build the momentum — that's how we build the mass.

Gladys

Good.  Now, we have our first audience question.

Did your business rules project yield any surprises?

[from the audience]   Did you meet any problems that really surprised you because up front you had thought that you had tackled that area completely?

Mukundan

Absolutely!  For one simple example, we thought that we had the areas of fillings all covered.  We had our analysis done, life was good, and then we said, "Oh, my, there are so many holes!!"  And we had to mine out 2,400 more rules.

So, yes, you will have those moments.  But realize that all those breakdown moments can be turned into Eureka moments because when it happens it's pointing out that there's something fundamentally wrong.  If you can identify the real problem — put a finger on it — you could be coming up with something that's totally revolutionary and changing the very face of the problem.  So, yes, you're going to be running into this because it's an iterative process.

Do you have any DOs or DON'Ts for business rules tools?

[from the audience]   What do you think are the DOs and DON'Ts of documenting business requirements as it relates to tools?  For example, you can use RuleXpress or DOORS or Excel or Access, etc., etc.  What have you found that has worked well?  What has not worked well?

Mukundan

So, the question is what tools do you use to capture your business rules and requirements?  Is that the question?

Gladys

Is it tools or method or ....

[Audience]

More tools.

Mukundan

Initially, we started with a white board and a lot of markers.  I believe it's easier to get people to go to the white board without any shyness.  But, that said, there are a plethora of tools you will use for different purposes.  For example, a business analyst uses Excel quite a lot; they use Visio quite frequently.  They use quite a few other requirements-capturing tools, as well.

But we don't get too hung up with the tools per se, as long as there is a good methodology for communicating those requirements between the teams.  It's more important to have cohesive teams and to have daily communication about what they're doing. 

Then, as your organization matures in the use of business rules, that's when you have to start seriously thinking about tools — because at that point you will have this mass of rules, and now you need to give some attention to the organization of those rules.  You will need some help to distill it all upwards.  Business rules is a very broad band.  Operational business rules can be very detailed and therefore hard for upper management to understand.  Yet the high-level business rules (the detailed rules distilled upward) are something that the organization — the executive management — needs to understand.  That's where strong traceability tools, like RuleXpress and such, can help.

Kevin

One of our experiences, agnostic of the tool usage, has been that when communicating business rules it's pretty hard to communicate them and to look for validation on their own.  We've found that to set the context properly for the business users we need to articulate what the process is, where in the process the rules exist, and then what the functional and non-functional requirements are.  Those things need to be communicated together as an entire package.  We've tried to just get validation of business rules on their own, and that doesn't provide enough context for the business user.  We've found we need to do those three things in an interactive communication style.

Hani

I'll state my bias from Microsoft in my comments.  I think the first thing to consider is this:  Do you even have a critical mass of people who are going to write or document or retrieve these rules?  That needs to be part of the tool decision.  If there are five people dealing with rules and you've got the Office suite in your organization you could use Excel or Word.  I think we do have a license for RuleXpress, but we didn't choose to leverage it this time for the domain that we're in.  We ended up using an Excel workbook.

The second thing to consider is this:  It's already hard enough to get people thinking in the rules approach.  If you compound that with some new tool you put in front of them, it might slow down the initial acceptance.  So, I would say that at the beginning just get people thinking in that rules approach, versus open-ended requirements that don't flow into rules.

With the Excel workbook we developed, we found that the most important part was how it was presented back, to get validation.  If your tool helps you accelerate the process of documenting and presenting back, that's fine.  For our project we felt the Office toolset was good for that.

Nathan

Again, approaching the question from the technology side, I'd like to add that it does very much depend on your case.  If you need an automated system to reason over those rules and the facts you're trying to decision on, I recommend not building your own engine.  Use some product that allows you to go from your Word documents to your automated system without the BA needing to hand the Word document over to a developer and then have the developer turn that into an executable, functioning rule.  Ideally, that's one of the things these tools provide — the human component of that knowledge transfer between analyst and system is removed, and your rule goes automatically into the operating software. 

If you know ahead of time that that's what you need — you need your rules executing in working software — then I would recommend using a tool to do that.  Otherwise, you'll end up building one.  And that will cost you more than you think and will take longer than you'd hoped.

Gladys

Then do you recommend going directly to the rules engine with that?

Nathan

Yes, that's one of the benefits of using a software package to do that.  Hopefully, you have one that's standards-based so that you're not locked into a particular vendor.  Technology these days around BRMS and rules engines has come a long way — there are lots of interesting ways to interchange data, whether you use web services or some other way.  There are many ways to do it.

Do you have any tips for capturing business rules from reluctant SMEs?

[from the audience]   I have a question regarding capturing business rules from business SMEs who may not be excited or willing to give you business rules.  I'm talking about people who have thirty years' experience, and any time you mention using business rules in a BRMS system they get very nervous and say, "Well, you know there's no way that capturing these rules can replace what I do on a daily basis."

Gladys

So, your question is, "What tricks do you use?"  How do you get the rules out of these people when they're not willing?

Mukundan

At Delta Dental we're trying to patent technology where we can scan the brains....  <laughter> 

But, yes, that's a very tough question.  Typically, when we've had the situation where there's one person who has all the rules, what's worked well has been trying to partner with that person and make them own part of the rules — involve them right from the start so they take ownership of the system.  That way it's theirs rather than somebody else's.  Ownership is a big part of it.  If you give them a lot of ownership, they don't feel threatened any more.  It becomes a different way of doing things.

Warren

I agree.  That's exactly what we had to do in a lot of circumstances.  The initial attitude was, "Why do we need to even come together and talk about things in the context of a rule?  I know what needs to be done; let me just go off and build my system to make it happen."  So, we've tried to explain, from a data quality perspective, that we need to get these rules out; we need to get them understood.  Yes, you may be the subject matter expert in that particular area, but let's share that knowledge so that everybody else has it. 

At least in my business, we want those business rules known and agreed to across a large network.  We have to convince people to tell us what the rules are and we need them to be willing to share them at the technology-neutral level that we're wrestling with.  Convincing people that it improves quality and overall operations of the industry that you're looking at is something we've had to do a lot of work on.  It's not easy, so be persistent.

How much time do you let pass before you go back and refresh/revisit your rules?

[from the audience]   How much time do you let pass before you go back and refresh/revisit your rules?

Mukundan

That's a very good question.  Once you have your rules in place there are always areas of innovation and continuous improvement you can look for.  The rules team strives to do that.  But is there a fixed answer?  Do you revisit every month? ... every six months? 

There's no clear answer.  If they see a significant improvement they will make it, but it's all based on ROI.  We don't write rules just for the heck of writing rules.  With us, it has been very strongly driven by ROI.  If there's significant ROI — if we can prove that by changing this rule we can save $200,000 in a month — we'll go ahead and do it. 

After all, at the end of the day — even when you're changing rules — there's a significant regressional impact; they have to go back and make sure that they don't break anything in the processes by making the change.  There is a cost associated.  Even though we have externalized rules into a rules engine and have the business users changing the business rules, there's still a cost associated.  So, there has to be a good ROI for us to change rules.

Hani

I'd like to build on that.  Rules, like requirements, depreciate over time — something you capture today, in six months or a year from now, may not be as valid.  So, the first thing to consider is this:  What's the dexterity of the rules and policies you're capturing?  There are some things that are more fixed and solid than others ... for example, something that  requires a regulation change or some kind of act of god to change it.  It depends on the dexterity of the rule you're talking about and the impacts.  Some rules impact many subsequent rules; some policies have trickle effects.

What we found was this:  Don't let IT control the change management, where you have to go through a quarterly or semi-annual process (or whatever the process cycle is at your company).  Control that process; enable the business rules analyst.  (We call them policy analysts at Microsoft.)  Empower the analysts to configure their rules and to execute and exercise those rules on demand so that they have the responsibility for updating the rules. 

How long it takes to update depends on the rule ... on the impacts of the rule.  The analyst has to ask if they really want to go there.  Sometimes they'll decide that it's not worth it and they will just keep the rule the way it is.

Mukundan

What Hani has touched on is a very important point.  Typically, what we have found in our experience is that rules lie in the intersection of contractual concerns, regulatory concerns, and business policy concerns.  Rules change if any one of these factors changes, and some change more often than others.  Based on that, just which segment of rules gets hit more depends on the intersect points.

How do you change the mindset that insists on running all business rule changes through a full change management deployment scenario?

[from the audience]   My team and I just implemented an SOA-compliant application that runs off rules that are in decision tables.  One of the challenges that we're having is convincing our change management folks that a change to a rule doesn't necessitate an entire production deployment cycle.  This is really defeating a lot of what the purpose of the architecture of the system is.  Do you have any suggestions for how to shift that mindset?

Mukundan

At Delta Dental, the true empowerment of business rules comes when the business is able to take charge of the full lifecycle of rules, that is, (a) they author the rules; (b) they are able to test them in a sandbox, separate from the production system; (c) they are able to do all sorts of analysis and report on them; and (d) they are able to deploy them.  If all four of those features are fulfilled in a BRMS then the business users have control and they can deal with the specific cases where they need that kind of agility.

But, that said, there still are certain other complexities you need to think about.  In any enterprise there are typically multiple environments:  you have a production environment; you have a user-acceptance test; you have test; you have development.  You have to make sure that the rules are consistent between all those environments, correct?

So, typically, you'll notice that in a really mature environment there's a lot of chaos too.  In our case, we migrate rules from production downward; we migrate rules from development upward (for example, when there is some new project area).  For those circumstances, you have to provide the complete set of tools.  Getting those verification and validation tools in place is really important for empowering your business users.

Nathan

I'd like to add to that from the perspective of someone who's been building software for years.  There's a big change that's happened in the industry — people talk about "agile development methodologies" and all the different flavors of that.  If you're in that branch of the business, you've heard terms like continuous integration and automated testing. 

Fears about deployments are well founded because practices in the software development industry, in the past, have caused very high defect rates to be found in the field because they weren't being caught up front.  It's a very expensive process to catch 80% of your bugs in the field; it's a horrible way to build working software.  Because of that, businesses (rightly so) reacted by putting in all those gates, to prevent (as much as possible) this buggy, non-working, very expensive-to-fix software from making it out into the field. 

In my opinion, what you have to do is start to build confidence in the business that they can trust you to release something into the wild that's not going to blow things up and cost them lots of money and customers.  One of the primary ways to do that is test automation.  If you can show the business a working set of automated tests that prove that the change you've just made didn't break anything, they're going to be much more likely to say, "Yes, go ahead.  Deploy that."  But to do that you really have to restore the business' confidence, which was damaged (unfortunately) from these old practices.

How do you get IT to hand control over to the business side?

[from the audience]   I've come from the field, and for twenty/twenty-five years I was in the IT field.  About seven years ago I moved over to the business side, and we started employing business rules, with the theme of empowering the business.  At the time we began we were just a project — just a trial (proof-of-concept) — and that worked very well.  Now that we've moved to more of an enterprise solution I find that the IT architects have a fear of letting things go to the business — "This is my control.  This is what I need to do.  You cannot have it."  I think of it almost like the twenty-years-ago mainframe fear of going from green screen to GUI.      I don't know of any way to address this other than by buying products that have the correct rule governance.  With that, we try to steer the IT folks into seeing that this is taking mundane maintenance out of their hands so that they can concentrate on better and more profitable things for the company — better applications, improved user experience from an application standpoint.  What has your experience been?

Mukundan

Actually, we did face that quite a bit, in spite of all of our successes.  The answer comes in several parts.

For one, I believe in 360-degree evangelization.  You need to evangelize constantly about the merits of doing business rules.  When I say "evangelize" you evangelize through case studies:  "This is what we did with rules."  "This is what we externalized."  "This was the ROI."  When you pitch to the business folks, emphasize the amount of dollars saved or the amount of dollars made.  What you emphasize to the IT side is for them to look at the reduced number of bugs generated with this approach.

The second thing you want to emphasize is the success of timely completion of projects.  You'll see a night-and-day change when you take on legislative changes using the business rules approach.  You can get a change done within days, which is simply not possible with the IT approach. 

Initially you are going to get push-back.  It's the nature of the game.  Something that has worked well for us has been to find the proper leverage points.  You build up conversations with the SMEs who have a lot of say in what they're doing.  That way you're not preaching to just one person; you preach to a whole, diverse audience.  Someone out there will effect the change.  There are people out there who'll be your ambassadors of change.  That's what worked well for us.

What is your advice for business rule governance?

[from the audience]   Does the panel have any particular advice in terms of governance of business rules?  Obviously, each business is different ... is at a different maturity stage.  But is there any general advice that you'd give?  For example, can it be a distributed skill, or do you have to have a Center of Excellence?  How do you recommend business rules be governed?

Mukundan

That's an excellent question.  You won't have all the governance initially.  Initially you'll be starting with your proof-of-concept projects and some pilot projects.  As you gain success, you'll take on more projects.  And, slowly, as you start accumulating rules then people will start to gain interest in what you're doing.  That's when you go and pitch to the higher management, "Hey, we need to have some structure around this!"

Typically, if your organization is not very big, you need to look at business rules together with business processes, architecture, etc. — all these concerns intermingle.  It would be hard to sell the idea that you need governance just for business rules.  In our case, we do have a semblance of governance on the business side — a group that meets regularly and looks at business changes from a business perspective.  And from the IT side, we have to look at things more from the architecture and overall IT development standpoint.

So, yes, governance is an evolving thing.  Initially, you won't have much, but as you gain maturity you'll grow into governance.  If you try to enforce a governance process right from the get-go it's not going to be very successful because you don't know in which direction you'll be going.

Gladys

Okay, we only have a couple of minutes, and I have two more questions to go.  Let's see if we can get these in, in the time left.

Did you include the CUSTOMER's view of the terminology when you built your vocabulary?

[from the audience]   When you were building your vocabulary, did any of you do research on what the customer's view of a word was?  By that I mean what the customer used as their term, in spite of what the company used as its word.  Did any of you do research on that?

Warren

We did a lot of that kind of work.  Many of our customers are external providers (immunization offices, for example).  So, yes, we go through an extensive process of trying to create the domain model and the vocabulary model ... trying to use terms that relate field-level people who administer vaccines as well as the systems people who have to make sure these things work in conjunction with each other.  And this varies from geographic region, state to state. 

There's a lot of work that we put into going through an extensive domain-model process before we got into building the business rules.  This is very important to do.  It unifies a community.  Everybody moans about doing it in the beginning because we think we're all talking the same language, but when you start writing things down you find, "No, that's not what I mean!"  So, it's very important to do.

Mukundan

Those are very good points — it is a tough question; it is a tough problem.  Initially, one thing to do when you're building a vocabulary is to scope out the project and try to stay within the scope of the project when you define your terms.  You're not going to be universal with your terms. 

For example, in a particular domain, "product" might mean something; that's what you want to capture.  And you want to provide proper documentation of your vocabularies.  In our tool, we provide a lot of documentation.  When I define "product" I define exactly what a product is in a given context. 

Now, when you take it to the enterprise level that's where tools like RuleXpress help you develop those universal/enterprise terms and facts.  If there are conflicts that's when you delineate them and come up with new terms, if you can, to make them unique.

Kevin

In our organization we're trying to create a terms governance council.  As projects kick off they will interact with this governance council on a regularly-scheduled basis.  A project would take a set of terms to this council; the council would meet; they would validate those terms; those terms would then end up being passed back to the BA community to help manage the terms as a corporate asset.  In essence, we've got a cross-functional group of people who are ultimately accountable for making sure those terms are agreed to in the different lines of business.

What "maturity level" would you say your organization has achieved in the area of business rules?

[from the audience]   With business rules projects you obviously need to start small and work your way up in the organization because it's simply too much to handle all at once.  On a maturity basis, however, would any of you consider your organization to be at a CMMI Level-5 of business rules maturity.  Or is everyone still working their way up?

Kevin

From my perspective, we're still working on it — we're still a ways away from being a Level-5.  I'm not sure exactly where I'd place us on a scale but probably closer to a 3.

Gladys

This is a good way to end.  Let's go through the panel and have each of you let us know where you think you are.

Mukundan

I would defer this to my business users because business rules are all about the business, right? ... No?  Okay.  We have achieved significant successes.  But there are a lot more areas we need to tackle.  Business rules are ubiquitous; they're going to be all over.

Gladys

So would you say you're a 4?

Mukundan

Probably.

Gladys

Okay. Hani?

Hani

We're a technology company at Microsoft so almost everyone in the company can write code and develop their own system.  You can basically get SQL-Server and Biztalk and any number of applications — just download the software and the line of business can write its own system.  So, across Microsoft I would say that we're pretty low maturity — probably a 2. 

However, for things that are actually governed by IT, especially in certain domains like product or pricing or licensing, in those domains I would say we're closer to a 4 because we actually have a central repository of rules that get executed and are co-located with the execution of those rules.  Violations of those rules now are flagged and understood more than before.  We've done a good job of harvesting and documenting those rules and getting them out of paper documents and out of people's heads.

Microsoft is a big company with many different business units.  It's hard to assign a value universally. 

Gladys

Warren?

Warren

CDC is also a big company, but in the area where I am involved we started out from "What is a business rule and why do we need to think like this?"  I couldn't even begin to tell you where we are on that scale.  Whatever the lowest number is that is probably where we are.  But when you're dealing with people and systems that have huge legacies you have to start somewhere. 

Getting people to think like this is a huge challenge.  Even after several projects, we still hear, "Business rule?  We're not a business!"  Well, yeah, you are.  You just have to think about it that way.  I don't know what zero would be on your scale but that's likely where we are.

Kevin

So, I did say 3, but upon further reflection and listening to some of the other panelists I might have shot a little high.  I'm thinking we're in the 2-1/2 to 3 range. 

Nathan

For Pharmacy OneSource and Wolters Kluwer Health we're pretty early in the curve.  From the technology side we're doing some really interesting things.  For example, at Pharmacy OneSource we've based our entire patient surveillance platform on rules, and we're using rules for real-time patient surveillance in hospitals today.  But in terms of business-wide adoption of a business rules approach we are at a very early stage.

Gladys

So, on the technology side you'd say you're high, and on the business side lower?

Nathan

Yes, very low.

Gladys

I know Emily is losing her voice so, Emily, can you say "3"?  Did I see three fingers?  Yes — there you go!

Wrap-up

[Gladys]    Okay.  Time always flies when we have this panel, and believe it or not, the hour's gone already.  You can see our panelists are just great.  Can you all help me thank them!    I also thank you for all the excellent questions.  Enjoy the rest of the conference.  Take care and have a good evening.

# # #