Centralized vs decentralized rules strategy

[Joel Toland]

I have several areas in which introducing rules technology is a good match. Each of these will be a relatively small implementation for discretionary (read low budget) applications. As an enterprise architect I develop the strategy for introducing new technologies. Although there are advantages to going with a centralized approach, I am leaning toward a distributed approach initially. Each project will handle their implementation. I will standardize how each is implemented (and enforce the standards) so that I can move to a centrally managed implementation in the future without any major issues. When I have enough critical mass to create a single support team with common hardware then I will centralize. If I do it right it will be an easy transition later.

I am looking for feedback on what has worked for others as well as thoughts on this approach.
Thanks, Joel

[Johan Lindberg]

I'm usually on the receiving end of this type of effort but there are two things that you didn't mention that I'd like to hear how you plan to handle. The first is knowledge sharing across teams/projects and the second is about getting project members to commit to using the new technology.

[Joel Toland]

Good questions. About six months ago I formed a team that spans groups to evaluate rules engines technologies and explore options. So from a technology option perspective I think that aspect is covered. I plan to utilize this same structure to deal with the knowledge sharing challenge you mentioned. We will actually talk through the overall idea of starting out decentralized with the longer term goal of centralization to manage expectations.

[Rolando Hernandez]

I think you'll find that no matter which approach you use, knowledge acquisition and knowledge sharing will be the critical success factors to building your rule-based applications. The key success factor is usually "what are the rules", not "what is the rule engine".

Another thing to keep in mind is the order that you build each rule-based application in. Ideally each new application should reuse rules from previous applications wherever possible. And as new rules are added to the rulebase for each application, figure out which (if any) of those rules could be shared, so they can be reused by subsequent applications as well. Soon, you will have a rulebase of global common rules that can be shared and reused to build new applications.

We used this approach at Mobil Oil and we found that reusing rule-based code and reusing business rules increased quality and significantly sped up system development. Each system took less time to build than the previous one (up to 50% less for each of the first few applications).

[Joel Toland]

Rolando - thanks for the feedback. For the initial projects I have an advantage in that it will in areas that I know very well. I have already done a small proof of concept and have used it with various groups. Once I get past that point, however, I agree that we will have to figure out how to do knowledge acquisition. I will need to get a handle on that soon. Your post triggered me to look on my bookshelf. Back when I worked as a grad student at an AI research lab, I bought a book called Knowledge Acquisition - Principles and Guidelines. I could start there unless someone has a better recommendation.

Johan - back on the knowledge sharing across teams/projects subject, what have other people been doing? What has worked for you?

[Johan Lindberg]

Hi again Joel.

First of all I must say that I think it's nice to hear that you've taken the time to lay a foundation. A lot of people seem to miss that or expect it to work anyway.

What has worked for you?

See, that's just the thing. I can't remember having been involved in any change effort that has succeed in a larger scale (> 10 people). Knowledge sharing doesn't work very well at Nordea (where I work) today. There are some initiatives but they are generally one-off rather than continuous work.

I'd be very interested in hearing how this continues. The lessons you learn etc. Please keep us posted.

[James Owen]

Greetings:

Fortunately (or, unfortunately, as the case may be) I have been involved with many teams from 1 (myself) to 12. There is a general guideline that applies to all of them and that is that there HAS to be someone (a single person) responsible for ALL of the rules, top to bottom, side to side. And that person absolutely must have experience with multiple approaches to handling problems and arriving at solutions that actually will work rather than, "Hey, let's try this one and see what happens!" or "Well, the consensus is that we try to use approach A rather than D so let's try that one." Sorry, Charlie. That's a prescription for failure.

There is a whole host of books on the subject of knowledge acquisition but the best that I found was one recommended by Dr. Forgy (name dropper!!) called "Knowledge Engineering Management - The Common KADS Approach" by Guus Schreiber et al. It's a bit dated (circa 2000) now but still, methods that actually work don't change much. Girratano and Riley's book also has some good suggestions on knowledge acauisition and team management. I could tell you which ones are full of horse hockey but then I'd get sued for telling the truth. :-)

Seriously, the buy-in is not only in terms of dollars but also in terms of man-hours (woman-hours?) that the company will have to invest on a daily basis to arranging short, highly-focused meetings to get to the heart of the matter: What are the business rules and where are the overlaps and what EXACTLY does each rule mean and what should it mean. I was truly blessed to lead that kind of effort at Bell South way back when along with Greg Barton and Dr. Forgy and 10 other wonderful men and women. But, that kind of effort is very time consuming and must be properly planned or it will degenerate into lots of meetings with very little usable output.

Whatever you decide to do, stay up-beat and remember that YOU (if you are the technical lead) will have to make the really hard decisions and hurt as few feelings as possible in order to accomplish the job. Bon Chance!

SDG
jco