Panelists

• Sam Paper   Bank of America
• Paul Avilez   Liberty Mutual Insurance Group
• Craig Bechtle   Mortgage Flex Systems
• Darren Koch   Hotwire.com
• Joe Garrity   The Hartford
• Jeff Wegner   West Bend Mutual Insurance
• Frank Habraken   CSC Australia

Moderator

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

Topics

1. Measuring ROI
2. The implementation effort:  timeline, staffing, skill sets
3. Semantics and communities and the cultural change aspect of doing business rules
4. Did you find cases where a rules engine was not a good fit?

.

Introductions

Gladys:  Welcome to the audience participation portion of the Conference.  This Practitioners Panel is really one of my favorite events.  Our aim for the Panel is to allow an opportunity for you to ask questions of our panelists, who have been there, done this ... they have vast experience and many lessons learned. I want this to be as interactive as possible, so how I run this session is to begin by asking each panelist to introduce himself — please give your name, company, projects involved in, and what tools you have used.  And I would also like you to give a couple of DOs and DON'Ts for a business rule project — what have you learned from your experiences?  Then I will kick things off with a couple of questions.  These are questions that I know I get asked a lot, and I would like to hear what the panelists have to say ... what their experiences have been.  Any time you have questions just raise your hand and I will come around with a mic.  This is really your opportunity to ask all those questions you might have collected throughout the Conference and to hear some answers from the practitioners who have been through it all. I'm going to get started with Frank.  Please introduce yourself and give us some background and then your DOs and DON'Ts.

Frank Habraken

My name is Frank Habraken, and I'm the Consulting Program Manager for CSC's Business Rule Management and Process Management areas.  I've been involved in business transformation/IT transformation for about the last fourteen years and I've had a number of other hats before that.

I've been working in areas within government and in the private sector — in Federal Government and the mining sector, and also the environmental sector.  For the last three and a half years I've been working for a large Federal Government department in Australia, implementing their business rule management environment.  That was not just about rules engine technology; it was actually about addressing decision making.  From the start three years ago, the goal has been about decision making.  The program of work was sponsored by the chief legal officer for the organization, who wanted to address a number of areas of litigation and to get better decision making going.

In terms of tools, which probably make up only about ten or fifteen percent of the work, we used two tools:  For our business rules engine we used Haley, which was a natural language engine, and from a repository perspective we used a metadata repository, Rochade, from ASG.  We used other, smaller tools — Visio for the semantic modeling and System Architect to model the information model for the repository.

In terms of DOs and DON'Ts, do make sure that the effort is driven from within the business.  If it is driven from within IT you'll just have a project-by-project approach.  You won't actually get enterprise decision making and enterprise business rule management.  Identify the key areas of the business that are hurting the most and get those stakeholders on board.

For my DON'T:  Number one — don't make it an IT-driven project.  It should not be IT driven.

And for another DO:  You've got to keep on communicating.  As Kathy Long said in her presentation, you need to "Communicate, communicate, communicate" ... because people are moving around a lot; they are changing roles.  Every six to twelve months they are in a different role.  So it's never ending — you need to keep communicating, communicating, communicating with those areas, again and again.

Gladys S.W. Lam

Okay, thank you Frank.  Jeff?

Jeff Wegner

My name is Jeff Wegner, and I am a business architect at West Bend Mutual Insurance Company.  My background is that I have had quite a few roles in IT over the past fifteen years — I've been a developer, a team leader, a project manager, a business analyst, and I'm now doing business architecture work.  The project that our company is working on is a new product development, and the portion that we're focusing on for our business rules initiative is the underwriting of that product.

The tools that we're using are:  InRule as our rules engine and RuleXpress for our rules repository.  For our business process modeling we are using Lombardi.  So we've invested in a lot of new tools within this past year.  These are all things that are new in the organization so we've got quite a bit going on.

As far as the DOs and DON'Ts:  For a DO, you are starting at a good place by coming here and listening, trying to find out what works for people and what doesn't.  I think it's really important that you ask for help — there are a lot of experts out there that have done this before.  Last year at this time I was out there trying to find out what we should be doing and found there was a wealth of information here.  So definitely ask for help and take advantage of this chance to engage the experts in the industry.

In my presentation earlier we talked about boiling the ocean ... you can't do it.  So for my DON'T I would say, don't try to boil the ocean — don't try to take on too much when you are first starting out.  Definitely start with something that's going to be manageable.

Back to the DOs:  To make things manageable, do control the scope of what you are working on.  It's really key that you allow yourself the opportunity to hone your skills with what you're learning and get the approach down correctly ... to do it right with something that you have some control over.  If the effort gets too large you're going to lose control.  You want to be able to deliver something sooner rather than later — to show that business value — because another of those DOs is to really work closely with your business partners and get their buy-in.  They're going to be able to then help you sell this to the rest of the organization, so that others can see the value as well.

Gladys S.W. Lam

Thank you, Jeff.  Joe?

Joe Garrity

My name's Joe Garrity, and I work for The Hartford.  My role is Rules Domain Architect, within the Office of the Chief Technology Officer in the P&C Company.  What that means is that I help move along the usage of the rules engines that we have at The Hartford, as well as working with the vendors to make sure that they're going to meet the business requirements that we're trying to find solutions for. 

As far as my experience, I've been involved with business rules for the past fifteen to sixteen years.  I've stayed with it long enough that it was called "expert systems" when I started, and it has evolved into rules engines as we know them today.  One of the first projects I worked on was generating legal wording for life insurance contracts, using a rules engine.  I've been involved with underwriting-type systems within the P&C industry, personalization for eCommerce, as well as data validation (something else that we've used business rules for). 

As far as DOs and DON'Ts, some of mine have a bit different slant from what's already been discussed.  One thing I'm a big advocate for is the use of a rule documentation tool — having a consistent way to capture your business rules.  Do have that established before your first rules project.  In our case, we were doing that in Excel, and depending on which part of the company you were working in you might have been doing it differently.  Having a consistent way to capture your rule requirements is one of my big DOs.

Another is something that has already been mentioned:  Make sure you have business sponsorship or a business advocate.  You can't do this as an IT-driven effort.  Make sure you get that business support.  There's a reason why it's called business rules.

As far as DON'Ts:  Don't think you have to do it alone.  There are a lot of people who have implemented business rule solutions in the past.  Try to bring them onto your team — have them as mentors.  You could very easily do something the wrong way, and it would help to have someone to help guide you through that first project — to teach you how to do it.  After that, from that point on, you should be able to do it yourself.

My last DON'T:  I'm an IT guy, but I have to say that if the business wants to have control over maintaining their business rules don't let IT get in the way of making that happen.  There's a lot of value if the business can control their rules.

Gladys S.W. Lam

Thank you, Joe.  Darren?

Darren Koch

Hi, I'm Darren Koch.  I work for Hotwire.com, an internet travel site based in San Francisco.  We have about 200 employees so we're a fair bit smaller than some of the other panelists.  That has some benefits and some drawbacks.  A big benefit is that all of our rule ownership and authoring is on the business side.  That's something I would definitely put in the DOs category. 

We have a team of business analysts — there are three of them who manage all of the rules.  We use the rules engine for pricing and sort optimization, as part of the eCommerce personalization ... how to segment customers and drive value that way.  The better we can display and segment, the better we can drive profit for the business.  We use JRules, the ILOG tool, for that.  We do it on top of WebLogic, our core site operating system.

As far as our other organizational things, I think you really have to have, not just the business buying in (I'm from the business side), but also the software engineering group.  They really need to buy into the idea that it's okay for the business to 'own' this piece of technology and to manage it.  This means that the business is responsible for a piece of infrastructure that can take our site down, and having IT operations and software engineering okay with that is really, really critical for us.  It enables us, on the business side, to change rules very quickly, which is critical for us to drive value out of the project.

On the DON'T side:  I'd say, be careful of the complexity trap.  As you start adding more and more rules you get into a situation where they can interact with each other.  The more rules you have, the more careful you have to be about things like testing.  That can slow things down if you don't scale your testing along with your rules as they get more complex.

My last point has to do with understanding that complexity going in can give you a real advantage in building in the infrastructure associated with it — making provision for future development so that you don't need to keep going back and forth and having expensive and complex projects to add flexibility later.  It's always better to build that in up-front.

Gladys S.W. Lam

Thank you, Darren.  Craig?

Craig Bechtle

I'm Craig Bechtle.  I'm with Mortgage Flex Systems, and I am the Chief Operating Officer.  Originally I was in the mortgage business and I still am somewhat in the mortgage business.  Now I'm responsible for both the business side and the technical side for Mortgage Flex.  We are a developer of origination systems and servicing systems in the mortgage space.  We use a rules engine for fees, product selection, and underwriting.

Because we are an ISV, we don't necessarily get involved in managing end user rules.  We're the developer of a tool, and we chose the InRule engine for that task; we are a .NET product.  We are agnostic between SQLServer and Oracle on our database side; we build in all the decisions on the database within the product, so we're indifferent there as well.

As an ISV we don't have to deal with a lot of the issues that end users have to deal with, but we have a different set of issues that we have to manage.  First of all, we have to build a system that we can sell to a six-seat origination shop, up to a thousand-seat origination shop.  We have to build in the power and the flexibility so that somebody who has a huge training budget or a small training budget can use the product.

In doing that, we looked around at a lot of the vendors, and we went with InRule for several reasons.  First of all, their focus aligned very well with ours.  So this would be a definite DO.  Look for a vendor who has the same approach to the business as you do ... who has the same interests, the same verticals that you're in, and who has some experience in those verticals as well.  You don't want to start out, brand new, with a vendor in a vertical that they have no experience in; you want to look for a vendor who has some track record and who can bring that to your solution, to help your solution take shape.

So that's the path we've gone down, and we've been very successful with it thus far.  Again, because we don't have to deal with end users and we don't write rules ourselves, we spent a lot of time on trying to build good authoring tools.  That is exceptionally important since a lot of time is spent on the authoring; we keep in mind that, at the end of the day, somebody has to actually use the tool and has to use that engine.  If it's difficult to use it won't get much acceptance.

For some more DOs and DON'Ts:  A lot of the people have already said a lot of the things that I'm going to say.  First off, find a good vendor.  I can't stress that enough.  And get training.  Lean on your vendor as much as you can ... as much as they can help you.  If they have experience in your business they can help you get there faster and with better results.

Also, understand what you're trying to do with the engine.  Don't lose focus.  Take things in digestible pieces.  I think everybody has said, "Don't go too big!"  I would say that as well — if you go too big you'll get lost. 

To sum things up, I can't stress enough the selection of a vendor and staying focused on what you're trying to do.  Those are key.

Gladys S.W. Lam

Thank you, Craig.  Paul?

Paul Avilez

My name is Paul Avilez.  I'm a principle software developer at Liberty Mutual / architect / a lot of things....  I don't think I've worked with rules as long as a lot of people here have.  I was going to say "five years" and that's a long time.

But I have done everything from being a developer, to testing, to working with the business to do business analysis.  In the past two to three years I've been a rule architect and team lead, and now I am more into the enterprise architecture.

At Liberty, we use Aion as an inference engine.  We have a home-grown rules repository, which the business uses to manage the use of the rules.  It's real-time — say they like this rule and want to use it for another state.  They can turn the rule on and promote it to production.  It's home-grown, with the Aion inference engine on the back-end. 

We use our system mostly for underwriting purposes.  We've grown it service-by-service.  We started out with just referrals and report ordering and pricing; it has grown into coverage manipulations and enterprise definition rules.  So it's slowly growing.

For my DOs and DON'Ts:  Do invest your time in your rule harvesting and elaboration work.  On average we now find that close to 75-80% of the time it takes to complete a rule is spent in the elaboration.  Coding the rule and testing it takes next to nothing once the elaboration is done.

Don't invest too much.  If you're just starting a big project you've got to prove the worth of the technology you're trying to bring into your organization.  If you invest too much and you get paralyzed by trying to have absolutely everything 100% done before you move into the next phase that's not going to do well for proving its worth.

To IT I would say:  Don't be afraid of coding yourself out of a job ... because, at the end of the day, that is your job — that's what you're there to do.  There will always be other work to do; there are always more important things to do.  So this is both a DON'T and a DO — Don't be afraid, and do code yourself out of a job.

The same thing goes for the business.  If you can give the business a tool that will mean it takes only two people to do what five business people used to do, then you will have three business people who can be out there creating new products for you.  The actual rule maintenance / rule management should be as small as possible.  It's the decisioning process that the business people need to spend their time on.

Gladys S.W. Lam

Thank you, Paul.  Sam?

Sam Paper

I'm Sam Paper, SVP with Bank of America.  I'm in a Strategy and Architecture group.  I've been in the industry for about twenty-five years, mostly IT, and about thirteen years in financial vertical (which I hope is a lucky number).  Mostly this has been in the consumer retail side, and the last two years in the commercial banking side.  The last thirteen to fourteen years have been focused more in data warehousing, information architecture, and the last two years in the BPMN and BRMS space, so I was very excited to hear the whole process intelligence pitch earlier today.

We started with a proof of concept, a pilot, in client management with JRules technology from ILOG.  It was a very successful AML [Anti-Money Laundering] endeavor. 

Going last, it's hard for me to add new DOs or DON'Ts; you guys have really covered the gamut!  But I'll start with this DO that goes along with the "start small" message:  Pick something that's going to be highly visible.  Really show success.  If you start small but you pick something that is not really on the executive's radar it's probably going to get a reaction of "Oh, that's nice."  AML is very high on the executive radar, as you might imagine.  We began there, and now we're moving toward some very exciting things in the global underwriting, fulfillment and monitoring space on the credit technology side.

In that regard we are, of course, using some very highly-scaleable solutions.  As you might imagine with our kind of volumes, we have a lot of IBM tech stack, with the Rational WebSphere suite.

For a DON'T:  Don't do things in a vacuum.  That message has been very clearly stated across the board.  I will add that there may be some opportunities within IT to explore as well.  I probably say this because of my IT roots.  But if you can leverage some decisioning services and process efficiencies to lean things out in IT, not only does the business get better service but now you've got IT's buy-in supporting the software. 

In summary:  Start small; pick something highly visible; focus on a business thing, but don't rule out something from IT that might be on that list.  It all depends on what your vertical is and what you're trying to accomplish.

Gladys S.W. Lam

Okay.  Thank you, Sam.

I'm going to start with one question.  Then, if anyone in the audience has a question, raise your hand and we can get a mic to you.

Measuring ROI

Gladys:  One of the burning questions that I like to start with — because every organization has a different perspective on this — is the question of ROI.  Have you, with your projects, measured ROI?  If you have, how have you measured it?  What feedback have you gotten from your sponsors, business people, and clients?

Darren Koch

I was the business owner and sponsor for our initial deployment.  That was in 2005, and it was for pricing and sort optimization on our website.  We had huge success, in terms of ROI.

We can measure it through testing.  One of the benefits of running a website is that you don't need to show everyone the same thing; everyone can get a different version of the store.  And we do all of that testing inside of the rules engine. 

For the initial deployment our goal was just to keep everything the same.  And then, after that, it was to keep everything the same and enable the ability to test and move forward.  Through that testing after the project we gained a lot of insight into our customers which we could then very quickly turn around into better pricing and sort optimization — showing the right customers the right prices of the right stuff. 

Normally, we try to have a pretty short payback period for projects — somewhere on the order of a year.  I think the rules engine paid off in six weeks.  We probably multiplied the original goal by ten or twenty in our actual payoff, and it keeps going.

So, yes, we've had very, very good results.

Frank Habraken

From our perspective, we've seen benefits particularly from the change perspective.  Ron had a few figures in his presentation that showed going from 'months' to 'days'.  We've had similar experiences in terms of that kind of change, whether it's been changes to legislation or changes to policy.

A 'quick' one (a slight code change) used to be around two to four months.  Now we can do some of those changes in hours because we sit down directly with the legal and the policy people, writing the rule out within the rules engine and then developing test cases based on existing test cases that we have.  We have around ten-thousand test cases that we can modify for both positive and negative testing, and then run the rule through to give us the result in (say) five minutes.

After that, because it's just a service it can go straight in.  And also because it has the time-based reasoning around it we can put it in, not the night before it's meant to be enacted, but we can actually put it in when the rule is ready.

The other benefit — which is not strictly an ROI benefit — is the benefit from the perspective of the legal and the policy areas now feeling they are directly engaged with the business and with IT.  To a large degree, they are starting to write the rules themselves and then handing them across to be executed.  And, if IT does write some of the rules, they can review them within a day, whereas it used to take weeks and they never really understood 'use cases' and 'test cases'.  But now they do understand.

Joe Garrity

I'd like to share something.

With us, when we embarked on using rules engines we were part of a speed-to-market program.  We had to deliver products much more quickly than we had in the past, and part of that was to help eliminate the bottleneck that IT was causing.  It would take IT too long — an excessive amount of time — to deliver changes that the business needed.  That was our initial 'why' for what we were doing.

But with that came some 'surprise' benefits.  One of these was:  Since the control of the rules was now with the business, the business was able to do somewhere in the order of 30% more changes than they had in the past.  That was a nice thing to have happen.

What it also did for us — more from an IT perspective — was that we gained some benefits around rule re-use.  After that initial implementation, when the next project came along, we often found we could reuse rules that were already in place.  By doing that, the project took less time since it was able to leverage some of the existing assets.

Sam Paper

You have covered much of what I would have said, so let me just net it out.  Yes, you definitely want to have some metrics that you can track to, to show value.  Then at some point when you are comfortable you will want to try to incent your organization with what I'll call "raising the bar."

So, time-to-market is certainly a benefit.  Another would be measuring productivity — showing how the decisioning services are enhancing (or decreasing) defects.

The implementation effort:  timeline, staffing, skill sets

[from the audience]:  I have a few questions for the panel related to implementation of your BRMS and the applications that you have described.  Could you describe the implementation effort in terms of timeline, staffing, and skill sets — how long did it take and with how many people?  What was the most difficult aspect of the implementation?  Did you use professional services from your rules vendor to jump-start the development?      And then I also have a question specifically to Mr. Bechtle:  What makes you think you wouldn't have had as good, or better, an experience if you had selected a different vendor?

Craig Bechtle

First let me answer your last question.  We went through untold demos — I can't count the number of demos we went through! — and the technology was a big part of that.  We are a .NET shop; we were looking for a .NET vendor.  So, compatibility of technology was important to us, from a deployment standpoint and from a product marketing standpoint, as well as skill set internally. 

Secondly, we were looking for a vendor who had experience in our space.  The mortgage space is very, very complex; I think we're all seeing that now.  We use the rules engine for product selection; we use the rules engine for fee generation; we use the rules engine for underwriting.  All of these aspects are very dynamic.  They are probably less dynamic today (and will be less dynamic over the next twelve to twenty-four months than they ever were in the past), but during the heyday of the subprime boom there were new products being developed weekly.  The speed at which those products could be developed meant that you either captured share or you did not.  So it was very important to have compatible technologies and also a vendor who understood the business we were in, and could then provide some suggestions when challenges were presented.

With all the vendors we looked at in that space, InRule was the one vendor who seemed to take a bigger interest in what our end objectives were.  That was really the biggest reason why we went in that direction — that and the technology.

Again, as an ISV, we don't have to worry about people writing rules at the end.  But we do have some rather large lenders who use our product.  One of those lenders deploys somewhere in the neighborhood of eight-hundred different mortgage products.  Within those eight-hundred different mortgage products I would hazard to say that there are probably a hundred to two-hundred different rules assigned to each of those products.

When a customer comes in looking for an answer — whether or not he qualifies — you take some modest amounts of information from him, specific to him and his credit, as well as gathering information about the piece of property:  where it is, what state and county it is in, what type of property it is — manufactured home, etc.  And then you have to run it against the product set.  The customer won't stand for a five minute wait time; they need it immediately.  And if you can't give it to him immediately, someone else will.  Whether they are using the engine through a website or using the engine walking into a bank branch, they still expect an answer and expect it quickly.

The impact of all that is that if I originate a bad product the lender is typically required to buy it back, so the rules have to be right and have to be right fast.  By 'right' I mean they have to be correct — to give the right product — subject to an audit that will pass the test that "yes, this is the right product for this situation."  And it's important to do this fast.

We had developed our own rules engine in the product we came from.  It was SQL rules, but we did front-end it so everything was English language.  Intellisense was built in, making it very, very simple.  So from a usability standpoint we couldn't take a step back; we had to be able to take the new engine and apply the same sort of paradigm for an end user's usage of the product.  That was very important to us. 

The number of people that we deploy to build the tool into our product is minor.  We have about four people who work on it:  one full time and another 50% of the time, and a couple more "as needed."  We spend a lot of time on the SDK, on the authoring tools, because it is important for end users to be able to write rules and to understand them.  At the end of the day, we didn't need to use a lot of people.

We did use a lot of our vendor's training and a lot of their professional services.  Because we had used dynamic SQL up to that point in time this was a whole different world for us, as well as for our customers.  From that standpoint we needed to lean on our vendors as much as possible.

I'm not going to tell you that other vendors are not good, qualified vendors.  I'm just telling you that ours is, because that has been our experience. 

Jeff Wegner

I'd like to add something about the professional services part of that question.

We're also a shop that has chosen InRule as our rules engine.  I would say that our implementation has been a little bit different in how we have used InRule's professional services.

I'm not one of the technical implementers, but I do work very closely with the developer and we've been discussing authoring.  The authoring environment has been one of the key things that has been great for us.  That developer absolutely loves the SDK in InRule — he cannot talk about it enough.

So it has been very straightforward for our .NET developers to use the product.  We have not had to engage InRule for a lot of professional services for the development work because it has been pretty clear for our developers, "out of the box."  We have been able to focus our use of professional services on the front-end work — the discovery of the rules — and work on that more with the business.

So that's a little bit different perspective on the professional service usage question.

Sam Paper

I would like to bring up something on the selection part of the question. 

I sat in on John Rymer's pitch on Sunday where he talked about a framework for selection.  If you didn't see that, I strongly encourage you to go back through that material and contact him at Forrester.  His framework is very nice.

Basically, he had about 160 or so criteria.  The bottom line is to go through and rank those — pick out maybe half a dozen to a dozen criteria that are significant to you.  And then go through an iteration, sweeping through the vendors, to get to a point where you can get down to one or two to actually evaluate with a pilot project or proof-of-concept.

Gladys S.W. Lam

And how about your resources? 

Sam Paper

Resources?  I think that's interesting because with any technology there's a learning curve.

We had a contract arrangement where we asked ILOG for on-site training as well as consulting, packaged so we could have a very fast time-to-market, accelerating the learning curve.  It was four-days of on-site training, with two-weeks follow-on for on-the-job, heads-down help to model and deliver on the work.  We found that was a very good way to go.

After that, since we are so big —we have quite a few people — when some of the other tech groups wanted to adopt the capability we just used that same model because it had been so successful for us.

Gladys S.W. Lam

So your internal staff then did the development?

Sam Paper

Oh, absolutely!  There was a very quick ramp-up, and then we let the tech team run with it.

Jeff Wegner

Gladys, now I feel like I should clarify something in my previous statement because I do want to make it clear that, as far as professional services go, we definitely did enlist InRule to come in and do training of our developers.  That was key.  My point was that after that training our developers were off and running.  Our development is being done completely by our internal .NET developers; we do not have any InRule developers doing development for us.

Frank Habraken

From our perspective, we ran two streams.  We ran a strategic stream, which a lot of people say is the longer term focus, and a tactical stream.

The tactical stream was about execution ... execution of rules engines.  The strategic stream was about the business rule management side of things.  This involved setting up a business rules repository, training people on how to write and author rules, setting up the engagement models, and setting up the governance models around it.

On the strategic side we utilized good people like Terry Moriarty, Peter O'Donohue (who we brought in from the U.S. as well), and another fellow from the U.S.  We had people from the customer side as well.  They developed and evolved things as a group.  We probably used about seventy man-months in the whole development.  Of course, if we did it again we'd probably do it in a lot less time, but we had a lot of learning and initial things to do.

On the engine side it was much quicker.  We used only a couple of people.  We had two people from Haley (RuleBurst at the time) and one manager over them.  We did have to have someone focused on a broader, systems integration perspective, rather than just a website-by-website sort of approach.  So they actually took a holistic look.

We got reuse out of the rules.  We did a lot of authoring of the rules beforehand — identified all the duplication and inconsistencies.  And so now, every single time, each project we do takes us much less time.  It was taking probably eight to ten weeks, and now some of these projects are knocking over in about two or three weeks.

Paul Avilez

I'd like to add a slight contrast. 

When we did our conversion project we actually didn't use any vendor resources at all.  Part of this was because we were lucky.  We had a couple of people who were familiar with the tool, and I had used other rules engine tools before.

But we did go out looking for a resource — a general business rule resource — someone who could approach the work from a more objective view because (let's be honest) before you get into a big rule implementation, you have to ask:  Do we have a guiding vision of where we want to be with rules in the future?  ... or are we looking for someone to tell us?

Nine times out of ten you're likely looking for someone to tell you.  Even when you do have that vision, the vision may not be the same as what a lot of the vendors might be suggesting.  So you have to have the courage to say, "No thank you, that's not what we're looking for," and then find a vendor who is a match ... or build it yourself if that's an option.

Joe Garrity

I'd like to say something about our implementation. 

I think it's very difficult to say how long our implementation really was for our first project.  We were also establishing our infrastructure at the same time.  At that point in time, we were primarily a mainframe shop — at least, for the business rule implementation perspective.  We were going to start offloading to our mid-tier, and that in itself took a lot of time to set up.

This gave us some problem areas that people don't necessarily run into.  For example, data mapping — how you're going to map data from your mainframe structures to something that the mid-tier can use.  That took us a lot of time ... much more time than people had anticipated.  Also, through the course of the project we changed our deliverable.  When we started we thought it would be one thing; then it changed to something else.  There was a lot of churning going on until what we were going to do became clear.

From a resource perspective, we had a mix of resources.  We used the vendor's resources at one point.  We also had a split between contractor resources and our own staff.  The thing we learned along the way (and this might go to what Paul was saying) was that it's not so much about bringing someone in who knows the specific tool.  We use Blaze as one of our tools, and even though we might find a Blaze resource, it's more important for the person to know the full suite of development tools they will have to work with.  It was just as important to have someone who knew Java as well as they did Blaze.  Because, in all reality, the amount of time we spent in Blaze was very little — we actually spent more time in Java. 

So we were able to focus in on the type of resources we wanted.  We also were looking at trying to make opportunities available to people internal to The Hartford.  We actually had some career COBOL programmers who made that leap to the mid-tier space.  So you might find you already have good people.  What's more important is having someone who is a solid developer ... someone who can transition to some of these newer technologies.  In our case we were looking for someone who knew Blaze but found that if they had rules experience (whether it was in Aion, ILOG, InRule, or you name it) the important thing was that they had gone through the process.  That's more important than anything else.

Darren Koch

I'll give the quick run-down.  Our project took about nine months, including vendor evaluation and contracting (which was probably three months of that time).  We had two full-time software engineers and a business owner and two business analysts who did all the authoring for the initial launch.  From the point we started actual coding of the production engine to the launch was about six months.

Gladys S.W. Lam

How many rules would you say was in that effort?

Darren Koch

Probably around two hundred total — about fifty for each of our four products.

Semantics and communities and the cultural change aspect of doing business rules

[from the audience]:  I just attended a presentation that Silvie ran that related to semantics and communities.  One of the things that is probably true to say is that we here are all a community using a special language, which is a 'business rule language'.  What we are doing/advocating here is a little bit different than the mainstream.  So my question is:  What were the major challenges, from an organizational change perspective, in doing business rules?  How much has doing business rules become a part of the culture of your organization?  How mature would you say you are, in terms of doing business rules as a matter of doing business?

Sam Paper

I'll start since I'm the one driving the standards, principles, policies, and guidelines.  We are pretty mature in that respect but, as you might imagine, we're going through some challenges with what we're going to fund and not fund, based on some acquisitions and other market trends.  That has put some challenges there.  But, no, we're pretty far along.

One of the things we're really trying to leverage — regardless of the technology (that's the easy part!) — is getting to a common business language.  And I mean this across all of the specialized skills ... your BMP, SOA, BRMS portal.  In my mind there's a real tradeoff between having the agility and flexibility that all this specialization brings and the practicality — cost performance and the like.  I think you just need to be very practical.  What's foundational is to get to a common business language.

I think that gets to the heart of what you are asking in your questions.  In all your organization's technologies, you want to make sure that you have a way to either import or extend them to support that common business language.  And, specifically, the verbalization of your business object model in the BRMS is a key thing to be able to do.

Gladys S.W. Lam

Sam, are there any organizational changes that enabled you to have this business language?  And was the impact from an organizational perspective, or was it mostly from a technology perspective?

Sam Paper

Really, the way we approached it was from a 'community of practice' — as a collaborative, cross-organizational stakeholder activity.  It's highly matrixed.

Gladys S.W. Lam

Any other comments?

Frank Habraken

I'll make a comment from our perspective.  

From an organizational change perspective, yes, there were questions of "how are we going to write these particular rules?"  We've spent quite a lot of time debating that over the last two years and changed the answer a few times.  We've had the lawyers come in and say they want to write things their way; we've had the policy people saying they want to write it their way; we've had the actual business front people say they want to write it their way.

In the end about three years ago we had the RuleSpeak training.  And then we came up with a set of guidelines with those particular groups and gave them three or four different options — priority one if it was a particular type of situation; priority two for another kind of situation (and so on).  We gave them a choice of about three or four so that everyone had the same set to work with.

The key piece, however, was governance and getting the organization to agree to particular terms and particular rules.  Setting up that governance was critical.  It's basically what I call the 'accelerator' or the 'decelerator'.  It doesn't matter how good your engine is ... it doesn't matter how good your people are.  If you don't have your governance approved, you might do okay for one little rules project but once you're up to about five or six that start to run into each other you're in trouble.

So governance is key, and that governance needs to come from the executive of the organization.  It can't come from within the IT area.  In our particular case, the top row — the steering committee — was the chief legal officer and the heads of each of the business divisions.  They did the final signoff.

The level below that were their two ICs; they basically run the business.  They know how the business actually works, and they make the call in terms of "Yes, we agree with what's here."  They also identify any issues.

The next layer down from that has the policy and legal people, who spent time debating particular rules and terms and then feed them up the line.  If they spend too long — if they argue for more than two hours on some particular thing — it goes straight up a level.  And if there is any issue at that level, it goes up to the top level.  Basically, it is a three-level governance process.

Whilst that was going on we had a status that we could identify in the repository:  under development, in governance, approved.  That way we started to have enterprise terms and began to minimize the siloing effect across the organization.

Gladys S.W. Lam

Good.  Any more comments on organizational change?  If not, we probably have time for one more question.

Did you find cases where a rules engine was not a good fit?

[from the audience]:  Have you had any projects where you've attempted to employ a rules engine and then found out it was not a good fit?  If so, why?

Joe Garrity

We didn't get to the point where we implemented something and then backed out.  However, once we got rolling in our rules engine implementation and had some level of success, in some people's eyes the first thought became, "Well, this should be done in Blaze."  We had to take a step back and say, "You know ... maybe not.  Maybe you don't need Blaze to do what you are talking about doing."

But we never got to the point where we implemented something and then said, in hindsight, maybe we should have gone in a different direction.

Craig Bechtle

One of the things we said at the beginning, under the DOs and DON'Ts, is to understand what the problem is that you're trying to solve ... what is your objective?  New technology is cool, and everybody loves to put it in.  Quite often I get people coming to me with something that is "really neat!" — it is cool technology, but there isn't a problem that it solves. 

You could spend a lot of time, money, and effort deploying technology that is overkill ... doesn't necessarily solve a problem, or doesn't create the kind of usability that your end users are looking for.  So you really have to spend a lot of time really digesting the objective — the problem that you are trying to solve — to see whether this is overkill or not.  I agree whole-heartedly.  You can't spend enough time doing that.

Paul Avilez

I have a couple of examples.  First, we thought about doing some transformations within the rules engine but we kicked that one out pretty fast.  A better case of something that might normally belong in a rules engine but doesn't end up there might be (for example) rating. 

When you're an insurance company, odds are you have a different rating engine than you do a rules engine.  There are some things that are associated with ratings, such as form attachment, that sound a lot like rules:  they vary by state, have different conditions that go into generating the form, etc.  However, these things are very specific to coverages, which are mostly out in the rating engine. 

So you can do one of two things:  you can tell your rating experts that they now need to learn two tools, or you can let them do what they do best in the one tool, even though it's not what appears to be the best approach from an IT perspective.  It's the approach that makes the most money.

Sam Paper

I was trying to think of an example and one is:  We have a lot of investment in Solutions Delivery Architects.  For any significant initiatives that are funded there is an architect assigned to help the project team with the applicable technologies, based on our core technologies and strategic direction.  We were pondering whether or not to apply business rules technology to a situation that involved data sourcing, with some complex transformations from an ETL tool.  That's the only case I can think of where there was some overlap and we were struggling because it was in some grey areas.

Frank Habraken

You have to think outside the box as well.  It's not just about executing things in rules engines.  Business rule technology/the business rules approach is also a fantastic way of reviewing policy, reviewing legislation. 

Yes, you can use your tool to help with the authoring, but it's also a fantastic tool for reviewing because it adds structure across the organization.  Your glossaries and terms are actually used and will help to reduce the silos within the organization.  The rules you define and the commonality across the organization will help the organization to become closer, as one. 

Given the movement of people from one area to the next — because these days they are only in their jobs for six to twelve months, maybe eighteen months — when they're using the same terms and rules their start-up in a new area is much faster than it was before.

Jeff Wegner

I'd like to add a similar comment.

Just having an approach that you follow to gather your business rules is the key to everything.  We definitely have spent a lot of time gathering a lot of rules — discovering them — and we don't have all the resources right now to get that kind of a decisioning service actually into our rules engine. 

So we have a kind of hybrid.  We've discovered the rules.  And then we have some traditional, not-inside-the-rules-engine development going on to do a coverage selection service.  This is outside of the rules engine right now, just because of the time constraints that we're under.

The key is really figuring out how to discover those rules and to do it consistently first.  Try to not get caught up in figuring out the implementation early on.  You can always change that.

Wrap-up

Gladys:  I hate this — this is always too short.  I know when I said "last question" people gave me this odd look.  But it has been an hour.  I hate to end it but we have to.       Isn't this panel great?  Let's thank them — they have been right on!  <applause>  Special thanks to the panel.  I have facilitated this for eleven years, and I'm sure that everyone learned a lot from what they have shared so freely with us today.

# # #