Jeroen asks, How maintainable is your Code? He goes on to identify 4 attributes of well written code.

1. Modularity
2. Consistency
3. Simplicity & Conciseness
4. Self-descriptiveness & Understandability

I will go and add one more to this list, Independent Testability. That will determine if the module can be tested independently of the rest.

I liked this topic because, one way to look at the business rules market is to see it as a subset of the software maintenance market itself.

We want to build business applications that can evolve with fast changing business requirements. And the business rules that drive operational decisions change real quick.

So, using a business rules management system to externalize your rules, and to deliver business decisions using Decision Services works very well, for many different kinds of systems(New Product Development, Insurance Claims, Trade Alert Engines etc)

Here are my five reasons why using rule driven Decision Services leads to more maintainable applications

#1 - Modularity

Modeling operational business decisions as Decision Services that internally use a rule engine, immediately provides this advantage.

1. A Decision Service is an independent Unit that can be reused by any number of applications
2. The Business Rules are externally managed using a BRMS, and their life cycle is determined by the Business Rules Life Cycle.
3. Modular and Reusable Services are enforced automatically when using a Rule Engine and rule driven Decision Services.
4. This allows the Architect to think in terms of the Service and its function, and leave the Rule Development to a Separate Team.
5. Because the rules and hence the business logic are so clearly separated, development & integration responsibilities are very clearly defined leading to modular designs.

#2 - Consistency

1. All logically related rules will be organized and maintained by business functions rather than by software module. This lessens duplication chances and improves consistency
2. The Same Decision Called from any number of places behaves in exactly the same fashion
3. Because rule driven Decisions are Independently testable, enforcing consistency is a lot less expensive

#3 - Simplicity & Conciseness

1. It is possible to capture the business rules in a form that is close to how business analysts can understand it.
2. Examples include Decision Tables (Can write them in Excel), or Flow Rules (can create in a form of a Flow Chart, using Visio)
3. There is no need to try and define complex abstractions to model business rules in code.

#4 - Self-descriptiveness & Understandability

1. For example, a Pricing Flow Rule will describe precisely how a Pricing Decision needs to be made. This level of descriptiveness will be impossible with code
2. Pricing Tables locked up in a Database Table will never be able to communicate the complete picture as effectively as a well designed Decision Table
3. Documenting complex System behavior as it applies to Decisions becomes very simple when you use Business Rules Technologies

#5 - Independently Testable

1. One of the main drawbacks with conventional programming techniques to build Decision Services is Testing.
2. When the rules change, as they will, Impact Testing will itself become a huge cost.
3. Using business rules enable teams to develop and test the decision services in parallel saving considerable time and cost

Related Reading >>

1. 10 Steps towards the Agile Enterprise
2. Real World SOA & Decision Services- One, Two & Three
3. Concurrent Development & Ease of Testing