How to balance DRY principle with minimizing dependencies?

Question

I'm having a problem with the DRY principle (Don't Repeat Yourself) and minimizing dependencies that revolves around Rete rules engines.

Rules engines in large IT organizations tend to be Enterprise (note the capital "E" - that's serious business). All rules must be expressed once, nice and DRY, and centralized in an expensive rules engine. A group maintains the rules engine and are the keepers of the rules sets.

When that IT organization is part of an American insurance company, there tend to be lots of rules. There are rules that apply to all states and products, but each state tends to evolve its own laws for different products, so the rules need to reflect these quirks. The categories are many: actuarial, underwriting, even for ordering credit and motor vehicle reports from 3rd party bureaus.

The problem that I have from a design standpoint is that centralizing rules and processing is certainly nice and DRY, but there are costs:

1. Additional network hops to access the centrally located rules service and return results;
2. Additional complexity if the rules engine is exposed as a SOAP web service - consumers have to package up SOAP requests and OXM the response back to their own domain;
3. Additional interfaces between the enterprise group that maintains the rules engine, the business that sets and maintains the rules, and the developers that consume them;
4. Additional complexity - sometimes a data-driven solution might be enough.
5. Additional dependencies - components who don't have control of their own rules have to worry about external dependencies on the rules engine for testing, deployment, releases, etc.

These problems crop up with lots of other Enterprise technologies (e.g., B2B gateways, ESBs, etc.)

The same Enterprise groups also tout SOA as a foundational principle. But my understanding of proper service design is that they should tile the business space and be idempotent, independent, and isolated. How can a service be independent and isolated if its rules are maintained somewhere else?

I'd like to err on the side of simplicity, arguing that eliminating dependencies should take precedence over centralization if the rules can be shown to apply only in isolated circumstances. I'm not sure the argument will win the day.

So my questions are:

1. Where do you fall on the centralization versus independence argument?
2. What's your experience with Enterprise tools like rules engines?
3. How can I make the argument for isolation stronger?
4. If my view is incorrect, what argument would you make in favor of centralization?

Answer 1

In the long run, easy maintenance of the whole thing would be an absolute requirement.

So DRY should be honoured at all cost even if that involves a loss of performance here and there, some additional configuration issues and other "minor" problems.

Also "independent" is different than "self-contained".

Otherwise imagine the situation when you need to change something and you have to contact a lot of different parties to force them to update. With DRY you also solve the problem of having incompatible versions running at the same moment for a brief period of time.

So

1. Centralization > Indepenence (at least in the system you describe)
2. Single point of truth for rule engines (everybody on the same page)
3. Remind them the cost of maintenance as years pass
4. I find your view correct.

Answer 2

Your question is very Enterprise-specific, and I'm more into desktop stuff, so I hope this answer is not too general. I liked the concept of Don't Repeat Yourself, until I found out how it was being codified and ossified. I liked it because it agreed with me (duh!) and my own ideas about how to make code more maintainable and less error-prone. Basically, I see greater maintainability as requiring more of a learning curve on the part of the maintainer. I don't think there's an easy way around that. Here's an example of how to increase maintainability by a good factor, but not without a learning curve.