We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

James Taylor's Decision Management

James Taylor

What, exactly, do you mean by business rules?

Vote 0 Votes

Scott Cleveland had an interesting post this week on the single greatest benefit of BPM that included the information that 17% thought it was "Change business rules and processes without impacting underlying applications". This focus on agility is not, perhaps, surprising but it prompted an interesting comment from John Owens (who tweets as @johnimm - I am jamet123 btw) who said "business rules ought to be embedded in the underlying applications". This of course is something I disagree with but when I double-checked his comment it was clear we are not talking about business rules the same way.

This is a persistent problem with business rules as the little b****ers get every where. There are business rules in user interfaces, business rules in business processes, business rules in data quality (John's focus), business rules in event correlation and business rules in operational decision-making (my focus). This is one of the primary drivers for me to focus people on decisions and decision making not on rules.

The reality is that you should do different things with these different business rules. Rules about data quality should be enforced when data is being created, rules about process escalation and routing should be enforced as part of the process design, rules about event correlation should be enforced in your CEP engine. But rules about business decision-making should not be mixed in with these. These rules only change when your business changes (not because you have refactored the database or redesigned the technical details of your process). They change because you change your discount policy or because there is a new regulation about eligibility or because your analytics tell you that your customer base is shifting.

Rules for decision-making should be in decision-making components - decision services - that applications, processes and event handlers can access. This ensures consistent decision-making across channels and processes. It gives you a point of leverage for analytics and a single point of control for compliance.

A rule for everything and every rule in its place.


Hi James

I completely agree with you - well almost. :-)

Business rules will be enforced at various levels. Some will be enforced at the level of Function, some at the level of Process and others, for example, complex exceptions wold need an ad hoc management decision for resolution and should not be automated.

My rule of thumb for robust design is to implement business rules at the lowest level possible. This ensures they will be automatically implemented at all higher levels. For example, if you implement a rule at the level of Elementary Business Function (EBF), it will be automatically implemented in every Process the includes that EBF.

The example you cite of discounting should definitely be implemented at EBF level. The discount ranges, discount values and the discounting rules for any enterprise should be represented in a generic relational discounting structure together with a generic discounting algorithm that accesses that structure.

Whenever the discounting policy changes, that change can be easily implemented by changing an appropriate a set of values, and will be automatically applied everywhere it is required at the appropriate date.

The most effective approach to Complex Event Processing (CEP) is to remove complexity. Complex events should be the exception, not the rule, and should be so few as to not require a CEP engine. However, it takes quality analysis, modelling and design to achieve this - practices sadly in short supply in too many enterprises.

With regard to "data quality rules", this is really a misnomer applied by the some practitioners in the Data Quality world. These are in fact business rules which, when properly applied, result in quality data.


One slight elaboration, James: separation of decision rules at the modelling / management level of course is not the same thing as separation at execution time.

PS: Not sure if John understands that "complex events" are simply event aggregates and patterns - they exist just like decision patterns (ie rules!) to be detected and exploited. I'm not sure how you minimise for example "fraud detection complex events"... although of course eliminating fraud from society would be good!


Rules are important not only on business environments. There are different kinds of business rules or, better say, different business areas need to enforce specific regulations. At a management level rules should be focused on a global perspective and in the executive level rules should aim at ensuring consistency and delivering good results.

James Taylor blogs about decision-management technologies such as predictive analytics and business rules, discussing how they deliver agility, improve business processes and bring intelligent automation to SOA.

James Taylor

James Taylor blogs on decision management for ebizQ, and is an independent consultant on decision management, predictive analytics, business rules, and related topics.

Sponsored Links



 Subscribe to this blog by RSS
Subscribe by email:

Recently Commented On

Recent Webinars

    Monthly Archives