Using Business Rules To Prevent Software Spoiling

by FICO

(Posted by guest blogger, James Taylor)

One of my favorite sites on software development - Coding Horror - had a great post today on how software spoils. Jeff's focus in his post was on how feature bloat can kill commercial software products. They go from tightly focused, easy to use products to bloatware that contains so many useless features (useless to any particular person, that is) that they are "spoiled"

When it comes to internal software - applications or services developed by an organization for its own use - one tends not to see this kind of bloating. However, even this kind of software "spoils". In particular the software no longer meets the needs of the business because the evolution of the software is out of synch with the evolution of the business. Typically this means that the business has changed and the software has not changed in ways that make sense given the new focus of the business. It can also mean that the software is simply not changing fast enough and so has fallen behind the business. You see this all the time as workers share tricks and tips to get around software problems, as note fields are used to contain data that can no longer be stored in structured fields as the rules about what's valid have changed. You see more and more manual exceptions generated and so on.

Externalizing business rules in decision services and empowering the business to manage the rules in such services can really help with this problem.

Business rules, being declarative and atomic, are easier to change as each change has fewer ripple effects.
Business rules, especially once templated, allow business users to much more actively change their rules for themselves, reducing the time from need to change.
Externalizing change into a decision service can dramatically reduce the rate at which the rest of the application "spoils" as so many of the changes that cause spoiling are changes to business rules.
If the application is originally developed so that the rules are under business control then developers may avoid introducing capabilities that will never be used. Business users might ask for something they don't really need but are unlikely to create rules they don't really need when they are doing the work themselves.
The separation of concerns that results from having decisions (business rules or business logic) managed separately makes any kind of change easier. A process change only requires change to process definitions, a policy change only to rules in a decision service, a technology change only to the plumbing.

I am sure you can think of others.

One additional thought. Several commenters on the original post made the point that Firefox's add-ons and greasemonkey scripts help fight bloat and therefore spoiling by allowing features that only some people want to be added only by those people. I have not given a lot of thought to how this might work with business rules but I could imagine allowing, say, store or regional managers to include or exclude specific rulesets for transactions in their scope of control to achieve something similar. Because one particular manager has a need to make a decision more complex thanks to some local problem, would not have to mean that everyone had to do so. The structuring of decisions with rulesets and rules would allow different degrees of complexity, even different approaches, to be assembled and disassembled by business users as they needed them. This might allow more business users to feel that the system reflected their true needs rather than some bloated corporate uber-policy.

Additional posts on this topic that you might enjoy include:

Don't forget to subscribe to my new blog in addition to this one (RSS)