Given a “situation” (either detected as a complex event, or pre-ordained through some business process execution pathway), one is faced with the decision on how to react. The decision can be again pre-ordained (such as the next acitivity in a business process pathway), or defined through some business logic represented in some appropriate form. And appropriate forms for such decision models include decision tables (one of the features upgraded in TIBCO BusinessEvents 4.0’s Decision Manager), and inference rules [*1].

• Inference rules (production rules in an if-then format): rule statements that infer new information or facts from events and data.
  • Advantages: declarative; flexible “knowledge” representation; can operate against large amounts of data at runtime without additional control structures; (relatively) common execution semantics in Rete-based rule engines
  • Disadvantages: semantics can be difficult to learn versus procedural if-then statements; potential for performance “gotchas”; not easily represented graphically
• Decision tables (business logic in a tabular form)
  • Advantages: (relatively) standard visual notation; semantics easy to comprehend; flexible to many execution strategies
  • Disadvantages: comprehension in large tables; extensibility may be expensive

The good thing is to have a choice of representation. Traditionally, business users have preferred the decision table format as it is much easier to provide for business control than over declarative rulesets - on the understanding that such business control will typically cost performance and/or flexibility.

However, choosing the right approach for the right use case can have a dramatic affect on performance. Recently one customer reported a 3x speedup and 30% reduction in CPU requirements after a refactoring exercise that replaced some inference rulesets with decision tables in TIBCO BusinessEvents. Food for thought, expecially considering that customer comparisons have shown that the TIBCO inference rule engine is anyway one of the fastest in the industry…

We will cover more on Decision Tables and the new BE4 Decision Manager features in a future article.

Notes:
[1] Inference rules are also used in the pattern detection step in CEP (i.e. for situation identification). Event and data patterns represented in production rules using the Rete-type pattern matching algorithm can be very effective - and this is the default, standard event processing paradigm in TIBCO BusinessEvents.

Having sufficiently had a chance to recover from a very busy and very engaging TUCON TIBCO 2010 user conference in Las Vegas, I wanted to pass along a few observations and notes from my track this year which was the Optimization and Visibility track.  This was a very full 2 days of mostly CEP customer presentations with a smattering of industry IT analysts and TIBCO engineering presentations thrown in for good measure.

I’ll include this as a series and cover one presentation at a time.

First up is PepsiCo, co-presented with their implementation partner, Infosys.

The use case was how PepsiCo uses CEP software to provide more efficient and cost-effective usage of their company transportation fleet and other dedicated transportation partners.

In specific, they wanted to use their CEP software to provide advice on when to use their own transportation fleet, or use another carrier for consumer product shipments all over the U.S.  Previously, Pepsi was using a manual, labor intensive process to manage the process.

In researching this project it was decided that they needed to be able to dynamically deploy their policies (or business rules), and automatically create decision trees to reflect the changing dynamics and costs of the transportation industry, they needed real time information on truck locations and cost valuations, and to capture metrics for performance measurement.

They also covered the architecture and design of their deployed system which was implemented with the Pepsi IT team and Infosys.  He explained how they were able to develop simple and timed events to automate and manage the business rules with the TIBCO rule authoring tool, deploy customized and re-usable processes to extract data from a 3rd Party tool at regular intervals and provide enhanced performance by querying large amount of data as subsets and utilizing XSL and XPATH capabilities within the TIBCO software.

They also wanted to provide the ability to correlate events or create alerts based on events. He described it as “managing their company transportation events”

Example: If xx# errors occur in an hour, then send email to baseline support.

Example: If the Dedicated Fleet carrier has not reviewed their trip within 2 hours of offering, alert the Network Coordinator.

They also covered their business benefits– which included the ability to strategically identify the placement of dedicated and company fleet capacity, scale their fleet best practices nationally, and provide an agile software platform that gives them the flexibility to adapt to change via business rules that require minimum to no code change.

Key learnings from their project included his observation that they were glad they involved the business side early in the project in defining business rules, actions and data elements. PepsiCo also chose to build this CEP solution using iterative methodology principles to in order to keep the business side engaged throughout the project, specifically in the area of User Interface and Rule Authoring.

One of the speakers also covered ROI and payback– but we were sworn to secrecy.

In general, it was a well received presentation by the packed room.

But what I really liked about this particular session was that it presented by the guys who were directly involved and it was to Infosys’ credit that they let the Pepsi guys (and the project’s) success speak for itself.

CEP applications are often touted as to be so cutting edge and revolutionary, but it’s applications such as these “bread and butter” projects that seems to have made a difference in their everyday company operations and sometimes it’s those applications that turn out to be the most important of all.

More customer presentations later …

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.

This week OMG’s Technical Meeting has had most buzz around the BPMN 2.0 submission (and congratulations to that team, for which TIBCO is a supporter). Some of the other stuff going on includes:

• PRR or Production Rules Representation (which, for complex event processing like in TIBCO BusinessEvents, can include event-condition-action rules using standard forward-chaining semantics) starts the Revision Task Force process for PRR1.1. A few tweaks are due, but more interesting was to see 2 more vendors attend the PRR session this week. Also, note that UML tool NoMagic is presenting on PRR at ORF’09 later in the year…
• DMN or Decision Model and Notation started on its first stage of development, which is the identification of use cases and roles for defining UML-based decisions for a future RFP. We had some good discussions (which I’ll report in a future post once I have reported to the DMN community), and it is clear that this could be a very key standard for business modelers, end-users and tool vendors. Of course the relevance of this to event processing is that many CEP/EP systems’ role is to support decisions…

A somewhat hotter debate continues (/is) regarding the proposed Case Management RFP, which was developed from a Dynamic Business Activity Modeling RFI last year (which TIBCO responded to, and was also covered by our session at the recent Semantic BPM day in Berlin). Many BPM applications are also case management applications, but some case management requires more sophisticated event-handling, rule-driven processes, decision management, and case record management and recording (technologies that TIBCO mostly covers under BPM+). One school of thought is that the more sophisticated requirements for case management need to be rolled into the common BPM standards stack (including BPMN); another is that multiple different standards should be used flor flexibility (such as combining BPMN with BMM, PRR and DMN). From an event processing perspective, of course, case management (by one definition at least!) involves applying incoming events to the state of some case in order to determine whether processes need to be started, continued, halted or changed - in other words CEP technology can often be applied for case management areas in government, finance, healthcare, etc.

Some of the other case management discussions can be found from EBizQ, Bruce Silver, and Derek Miers.