Gartner’s David McCoy recently posted on his frustrations with the idea of “business rules” - or at least some prevalent ambivalency towards the management of rules:

<<I’m beginning to think that most people DO NOT CARE about business rules… So, is it any reason we haven’t seen more uptake of Business Rule Management? No. I think the story is clear. BRM isn’t sexy. It’s not even something that people want. It’s a necessary evil in too many eyes. … >>

He adds some exceptions, though:

<<We’ll just let those of us who know the power of rule-driven behavior benefit from BRM …. Those of us who know, know things like this:

Rules + events = real-time reaction
Rules + scenario analysis = policy-driven agility
Rules + process = mutable processes that stay within bounds
Rules + applications = rapid adaption to new opportunities>>

Of course, different people have different understandings of rules. The “business rule gurus” talk about rules that to many are more like policy or regulations - i.e. constraints on the business like “A Driver of a Vehicle must have a valid Driver’s License”. While documenting and communicating such rules allow good governance, as well as providing useful input as requirements to an IT project, you can see why such efforts could be construed as “not something people want” per Gartner.

On the other hand, decision rules - determining either facts or actions - are what drives businesses (e.g. the sorts of rules one usually associates with “real-time reaction” and so forth).

Therefore it was interesting to read from John Hall on the EU Ontorule research project when he posted about a Decision Oriented Business Applications workshop to take place this year; I’d understood that Ontorule had been about mapping SBVR vocabularies and (policy-like) rules to production rules executed in a rules engine.

<<One change that has occurred since the [Ontorule] project [researching operationalising rules and ontologies] started is the growth of decision management and modelling…>>

So when analysts complain about the lack of take-up of “business rules”, I suspect they are really talking about SBVR-type rule repositories (which remain useful for governance, but are not yet used to support many IT projects today). “Decision rules” as used in Business Processes, and the management of said decisions, remain a hot topic and bridges the business vocabulary world with the IT execution world. And event-based decisions provide the real-time reactions that businesses are increasingly concerned about…

A customer was asking about methodologies around business rules, which was also the topic of a recent LinkedIn discussion started by Paul Harmon of BPTrends (who is apparently extending his BPM methodology to rules). Some general thoughts on methodologies below:

What am I trying to achieve?

1. For (stateless) business decisions, as usually associated with business rule automation in the literature today, consider that common paradigms like decision tables can be viewed both as specification documents (e.g. in a spreadsheet) as well as executable artifacts. As an example, TIBCO BusinessEvents can import Excel spreadsheets into its Decision Manager.
2. For (stateful) rule-based CEP and event-driven business processes - event-rule processing can involve multiple entities - events being filtered, patterns detected, facts inferred, actions made etc - and ideally the rules will be specified declaratively, guided optionally by state models.

What is the generic approach to identifying / specifying business rules?

The generic approach is:

(a) Identify the business entities being processed

• E.g. use cases and actors

(b) Identify associated states

• E.g. entity states and what decisions need to be applied in these states

(c) Identify the associated events

• E.g. business changes like new customer, new agent, removed order, etc
• E.g. occasions when we need to make a decision in a process

(d) Identify business rules against entity / state / event

• Conditions that apply
• Reactions or results
• Inferrences to be made
• Patterns to be identified
• Rulesheets / decision tables

What about “business rules” in the widest sense: rules about the business for the business?

The above comments apply to the common-use of  “business rule” relating to rules and decisions in processes, possibly automated (e.g. in rule engines, with the relevant OMG standard being PRR), and possibly as a part of complex event processing.

For the wider definition of business rules, defining business rules as constraints against the business and documented as a business asset (relevant OMG standard being BMM and SBVR) there are additional steps, usually via some controlled business ontology or vocabulary:

(a2) Identify declarative business rule statements that associate entities with each other

• Eg statements of constraints between the business entities at particular times or on particular business level events

(d) Map business rule statements to associated entity / state / event occurrences to enforce the business rules in particular processes.

What are the  main published methodologies?

There are 2 main providers of methodologies (outside of particular rule vendors’ thoughts … ):

i. Barbara von Halle @ KPI: the main reference remains Business Rules Applied and associated methodology although unfortunately this has not been updated (for example, it predates the concept of CEP and indeed TIBCO as the ~3rd largest rule engine vendor). KPI also have a new book about to be released covering more of a decision model approach.

ii. Ron Ross @ BRSolutions: business rule documentation focus - the main book is Business Rule Concepts which is uptodate and covers mostly the wider definition of business rules, but does relate how these map to automatable rules (and events).

iii. For simpler requirements gathering, the (very) basic separation of business rules from use cases is often covered in Use Case books.

How do these apply to CEP?

Part (d) of the generic approach is obviously far more important in pure event processing. The identification of what filters (to events, payloads etc), what patterns (including patterns on streams as well as individual events, and across data combined with events), and combinations thereof are required to identify a complex event effectively requires its own methodology, which we can cover separately.