Paul Vincent of Tibco presented to the OMG Decision Modeling Notation day on the impact of event processing and real-time event handling on decision management. In particular the increasing need for true real-time, almost snap decisions. Tibco sees demand for these kinds of decisions across banking and trading, supply chains, telecommunications and more. Paul used a version of my favorite decision latency graph (described in this post on active data warehousing) that emphasized the importance of quickly identifying a business event, doing root cause analysis or correlation, making a decision and taking the action.
Many decisions are required in the context of a business process but Tibco sees increasing interest in decisions in less well structured environments – places where it is not known WHEN the decision will be required in advance. These decisions are, like most decisions, highly dependent on context and this is more complex in a non-process centric environment – involving state and time for instance.
Event Processing, Paul says, consists of some event transportation and distribution infrastructure that supplies events to a pattern detection engine. Once patterns are identified a decision is required to determine what to do next – involve a process, transmit a new event etc. These actions and the reactions to these actions then create new events that go back onto the event backbone. An Event-Decision-Action architecture if you will. Of course some of these events could be changes in databases or service invocations so that this architecture could be integrated with SOA environments. And within this environment, the Decision Management elements of this are the same as in a BPM context and are based largely on a decision table or rulesheet metaphor.
One of the key issues in this environment is that data and time matter more in event processing because they define the context of the decision – stateful information and time since/point in time replacing the process context. This means that, from a modeling perspective, we need to think about goals and end-states, about the models that support these goals (whether rule models, query models, stream models or state models for instance). And these models can be combined – to allow a state transition to be based on a decision, for instance, not just an event rule.
His conclusions:
- Decision modeling is part of Decision Management
- Decision modeling is not the same as decision maintenance
- Decision modeling is a process that can be supported by methods, could use common notations and metamodels.
- While base artifacts like decision tables are widely support, analysis artifacts are much less widely supported.
A rapid and a effective tour!
