A few years ago I was hired by a WA state agency to lead their HIPAA^[1] project.  When I arrived at my new job one of the hot topics was "Succession Planning."  The agency had realized that a large number of their managers would be eligible to retire within the next five years.  Numerous meetings were held to discuss how to deal with this situation, but all that came out of them was a list of the eligible employees.

Thinking as I usually do about the functional outcome of these retirements, I began to think about how this would affect Information Systems.  As I became more familiar with the environment, I began to see that the documentation of the business rules ranged from scanty to non-existent.  The only place most of the rules existed was in the heads of those very same employees that were on the retiring-soon-list.  And many of the rules existed only in code, code that had been written and re-written over the last 25 years.  Just to make life more interesting, a number of new legislatively-mandated requirements were in the works, as was the possibility of a re-write or replacement of the system.  

Things truly were chaotic and many of my co-workers had panicked, deer-in-the-headlights looks, except those who were retiring; they looked smug and who could blame them.

I sat down and had a talk with my boss, a director with a good grasp of the problems that we faced.  I talked about what a business rule is and how our business was very rule-bound.  I explained what a rules engine was and suggested that we could use one to help us reach a number of short and long term goals.

Short term goals included preparing for the new requirements by examining the rules we would be required to implement, beginning to gather rules already in the system from people who would be leaving soon, and storing them.  Long term goals included being ready to re-write our system or provide our business rules to a project that might be subsuming our system.

Finding a tool to help us accomplish all of our goals was aided by the fact that I had been to the International Business Rules Forum the previous year and had seen a number of tools demonstrated.  I hauled out all of the information that I had collected at the conference and made a list of possible software vendors.  My staff did a web search for other possible products and then we made a short list of software that we wanted to 'audition'.  We also used the Gartner Group's Magic Quadrant to research products that we were considering.

Buying a rules engine is similar to buying any software, you need to create a list of desirable features and decide which are the most important to you, find products that seem to match your list, and then try out the software before buying.  Our criteria included:

• Flexibility because of the myriad of uses we wanted to put our tool to.

• Ease of use because we wanted the learning curve for the programmers to be short and to have the business users maintain the rules once they were in place.

• Company stability because we wanted a vendor that would be around for a long time.

• Good customer support because a rules engine was a first for all of us and we knew we'd need a bit of hand holding.

• Price because government is always a short on funds.

After a month of trying out products, we choose Corticon for its ease of use and great support while we worked through installing and beginning to use their product.  Once we had picked our vendor, we wrote an explanation of our selection process and conclusion for our manager.  After the rather complex process required when buying things in state government, we had our rules engine and installed it.  Training was next on our agenda.

The business users were social workers -- not people who most of you think of when you hear 'business people' -- so when we did training, we trained half IT people and half social workers.  The people who took to it were ... half IT people and half social workers.  

The social workers who took to it were really amazed at themselves.  One of them kept saying, "I keep getting the right answer.  I don't know why!  I keep getting the right answer!"  So, you can't necessarily predict who it is that will do best with learning how to use a rules engine ... although, if you have someone who has never had a logical thought in their mind, they may not be your best candidate.

Once training was over we began to gather rules and put them into our engine.  Here is what we did:

• Gather rules for parts of the old system
  
  
• Write rules for new processes being added to the old system
  
  
• Argue a lot about using the rules engine to serve up rules
  
  
• Begin a project to collect federal income tax using the rules engine
  
  

These are some of the lessons learned from this project:

Don't ignore the people side of the project.  

When you are going to ask people to give you their time and their information, prepare ahead of time.  Look at the things that are already available before you start.  Don't ask someone a question that you could have picked up from the documentation that is sitting around.  Look at your process models, your use cases, your data dictionaries -- also, the user manuals, desk manuals, forms, records, test cases.  (And, if worst comes to worst, you could even look at code.)  Be as prepared as you can when you to talk to your users, and they will be much more cooperative and open-minded.

This applies to the technical staff, too.  Don't assume that they're just going to jump in on this idea of rules and say, "Oh, yeah.  That's great!"  You need to spend time getting them on your side.  Your reward will be having some good people to work with you.

Manage your rules project as a project.  

This is a project, not magic because it involves 'rules'.  It must have a timeline, just as you would for any project.  You need to be able to show your progress -- to be able to say, "I'm this far through it."  That way, when people come to you and ask, "How come I haven't seen anything yet?" you can answer, "This is our plan.  Here is where we are.  Here is where we're going.  This is when you will see things.  Here is the next thing that you will see."

If this is your first rules project -- a pilot' project -- the 'Keep It Simple' principle applies, just like any other IT project pilot.  You need balance:   you need to have some richness to your project; you want to keep it very contained; you must show value.

Being non-profit we have to measure value differently.  When the tax project started up, I looked at what it would take to do the project with all-IT staff,  I estimated that I would have needed 30 new COBOL programmers, which I didn't think I could find even had that alternative been funded.  I presented that against the alternative, using a rules approach:  do the project with 5 CPAs and one C# programmer.  This was an equation management could certainly relate to:  "Thirty people?  Or six people?"  I was able to say, "Here's the money we save."

Don't skip steps.  

You need to define your terms.  You really do.  And you need to use those terms in facts.  Only then can you write your rules.  If you skip steps you're just going to have to go back to the start, and you'll annoy everyone around you.

In this effort, your 'data' people can be a real asset.  If I can, I always do a project with a data analyst.  Yes, it may turn out that the vocabulary, when it ends up in the database, will have some differences.  But the differences will be reduced.  Think about what it would be like if you were in an insurance  company and your business people called something a 'policy' in the rules they wrote and the database called it 'customer service'.  That makes for a disconnect in your business that you really don't need.  Working with a 'data' person on a rules project is really helpful.

I've since moved on to another company where the first thing I did was start lobbying for a rules engine.  This experience was different from my last because the programmers and business analyst were enthusiastically behind the idea of a rules engine.  But that's a story for another day.

If you have any questions or want to chat about using a rules engine, you can contact me at bonniemoonchild@gmail.com.

References

[1]  To improve the efficiency and effectiveness of the health care system, the Health Insurance Portability and Accountability Act (HIPAA) of 1996, Public Law 104-191, included "Administrative Simplification" provisions that required Health and Human Services (HHS) to adopt national standards for electronic health care transactions.  At the same time, Congress recognized that advances in electronic technology could erode the privacy of health information. 

# # #