James Taylor's Decision Management

Noam Tamarkin had a post recently on Efficient or Effective in software development in which he asked an important question - would you rather be more efficient or more effective when it came to developing software. Most would, like Noam, answer that they preferred to be effective. Yet I see many programming teams pick efficiency over effectiveness, though they probably don't see it that way.

When a team picks a traditional coding language to automate decisions (like eligibility decisions or pricing decisions or risk decisions) they are choosing efficiency over effectiveness. To be more precise, they are choosing execution efficiency and development process efficiency over solution effectiveness.

Procedural programming languages like Java and C# are efficient. They execute efficiently, don't require special execution servers etc etc. They are also efficient from a development process point of view because they fit with the way programmers, and IT departments, like to develop software. And performance and "fit" are two reasons often given for rejecting the use of business rules and a business rules management system or BRMS.

Yet for decision automation the use of a BRMS would be more effective. By bringing business owners into the process and making it possible for them to collaborate effectively, a BRMS makes it more likely that the resulting application will do the right thing. The rules implemented are more likely to be the ones intended than if the business intent has to be translated into code. And, in the real world, the rules change all the time. A BRMS increases the effectiveness of the solution by making it easy to change the behavior as the regulations, policies or competitive situation change.

While coding a decision may be more efficient, using a BRMS to implement it is likely to be more effective. You choose.