What, exactly, do you mean by business rules

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”.

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.

Copyright © 2010 http://jtonedm.com James Taylor

Syndicated from ebizQ