A radio receiver receives a signal composed of some carried content, and a carrier wave. The carrier wave has a fixed frequency and modulation. The radio removes the carrier wave from the signal,and then outputs the signal to the speaker.

Software does the same thing. In the “Hello World” program, the text “Hello World is the carried content. The rest of the code is carrier. We’ve written this program in a wide variety of programming languages and technologies. In the end, regardless of the various implementations, the program just display “Hello World.”

Carrier and carried is a generic characteristic of all media with software being a media.

In code, we make decisions in the carrier as well as in the carried. In business rules technology, the carrier is the responsibility of the programmer, and the rules are left to business managers. The carrier decisions can be left to the requirements. The carried decisions will constitute the business rules of the application.

It might be beneficial to treat the carrier decisions as rules, since they are volatile, but it will be critical that the carried decisions be business rules.

The real savings with business rules technology is that the manager will no longer need programmer support to change a business policy. With business rules technology, a manger change the policies driving their organization quickly, so the business will be more responsive to real world business drivers.

Roeland had an interesting post this week on the need for a new approach to requirements and BPM’s role in that. He outlined the three classic causes of problems with projects (Lack of User Input, Incomplete Requirements & Specifications, Changing……

Cheers,

http://www.snjtechconsulting.com.au/

Belive me, when you start using something like this, the green line is growing even faster and there is no reason to hide businness logic in the code.

“All the variables are constants, all the constants are variable”

I’m not sure that it allows you to write better software, faster. But I would suggest that it allows you to start writing it sooner. This is a good example of the benefits of an iterative approach. Once the design decision has been made about how a business rule will be implemented, some of the details (and it should be clear which ones) can be left to be finalised later in the development process, so they are removed from the critical path. It is a good rule of thumb that the longer it takes the stakeholders to define their business rule for you, the more likely it is to change… and sooner rather than later.

Another good rule of thumb, though, is that the more you abstract the implementation of business rules, and the more you try to make it easy to maintain them, the higher your costs will be… initially. So I would quibble with your otherwise excellent graph. I think the general case should be that the maroon line begins by leading the green line (a small decrease in time to deploy) and the green line crosses it later. How much later will depend on the extent to which, for the green line, there was worth-while investment in enabling the future timescales to be shorter. So the bigger the initial delay, the less time is required for each iteration and the greater the “acceleration”.

In conclusion, I would note that you omit one very good reason for abstracting “all” rules, rather than only the more volatile ones. This is that making a distinction based on volatility would imply a design decision. (From a theoretical standpoint, I don’t believe it is actually possible to abstract all rules, since you would, if successful, end up with only rules. So from a practical standpoint: How do you recognise what not to abstract?)

Interested readers might like to consider divergent opinions here: