DMN: promoting decision-based software

Last week TIBCO hosted the first Face2Face meeting of the decision modelling / management experts from FICO, IBM and Oracle representing one of the submission teams for the OMG Decision Model and Notation standard. Although we cannot divulge any details of the meeting results, suffice to say that progress was considered as “good” by all concerned… publication (to OMG) of the first draft of this and the other submissions is due in May 2012.

From an event processing perspective, current decision-based methodologies mostly focus on the “decision as a service” (DaaS?) type models and associated stateless executable artifacts – think TIBCO ActiveMatrix Decisions and TIBCO BusinessEvents Decision Manager, and their equivalents Oracle Business Rules, IBM Websphere Ilog JRules, and FICO Blaze Advisor. Here a decision is something that occurs at a point in time, based on data / information valid at the time of decision, with some explicit process required to revisit said decision.

However for event-based decisions, we can also consider decisions as a continuous operation. This is best illustrated by the “decision” made when some event pattern is identified: the pattern may be identified and/or disqualified multiple times for the same entity, based for example on complex and sophisticated business rules (that may themselves be changing over time). A typical mechanism for this might be inference rules (as seen in TIBCO BusinessEvents). I would expect later versions of DMN to be extended to cover rule-based and continuous-evaluation decisions, but DMN version 1 will likely cover the simpler “Decision as a Process Task” role (where “process task” could be a BPMN Business Rule Activity or a dynamic rule-driven activity). The differences in decision models for continuous versus decision-point based decisions is an interesting area for future discussion!

My thanks again to the participants of the F2F for a successful meeting.

Trade Audit Trails: track and trace for capital markets’ regulatory compliance

tradetrackandtrace-snipOne of the other interesting meetings at the recent OMG standards event was by the Finance Domain Task Force on the requirement for a “Trade Transaction Traceability” standard to meet the regulatory requirements of Dodd-Frank (full name: Dodd-Frank Wall Street Reform and Consumer Protection Act). The idea here is to provide an audit trail (or log), to some SEC-approved XBRL- based XML format, of all the activities and processes that are involved in a “trade” in an investment bank. Thence the need for track-and-trace across front, middle and back office systems.

From a CEP perspective, this is more of a risk management problem than the typical low-latency algo-trading application usually associated with stream-processing CEP in the financial markets. A typical solution for trade track-and-trace would combine some combination of TIBCO Hawk monitoring and TIBCO BusinessEvents CEP to correlate trade processing throughout the bank into a single audit trail while minimising footprints and impacts on existing processes and execution times. Another solution, also CEP-based, would adapt TIBCO Active Service Gateway as a “financial service router” or Services Monitor / Message Interceptor (doing discrete monitoring to create the audit trail).

The OMG is continuing to work on this proposal, and their use of trade and process event correlations (using CEP) could also provide an input to the planned OMG Event Metamodel and Profile standard. And a similar, existing CEP use case is planned as a presentation by an existing TIBCO customer at TUCON this year (in conjunction with an update on TIBCO Hawk technology for the “edge of the Event Processing Network”)…

tucon2011_signature

Emergence of Case Management

govtcasemgmtI was at OMG this week when the submissions for the proposed “case management standard” (called Case Management Process Modelling or CMPM) were discussed. What was interesting was that one of the submissions spent a lot of time positioning ECA – Event Condition Action – rules as a means to model and execute the launching of activities and achievement of milestones in cases.

ECA is of course a widely used CEP paradigm: in a tool like TIBCO BusinessEvents the ECA rules are defined as conventional (in OMG parlance, PRR-type) production rules, where an event is just like any other fact to drive the rules. ECA rules also drive the traversal of state models (and state machines at runtime), as well as coordinate the conventional manual business processes. It is therefore interesting that Case Management – considered by many to be just an extension to BPM and mostly achievable with BPMN – is also proving to be an example of business process mechanism convergence (e.g. BPMN-type BPM orchestration of explicit activities, for example representing a plan, working alongside declarative rule constructs and technologies like ECA rules). For a real-world example of the latter, take a look at TIBCO Fulfillment Orchestration.

Of course, what neither the “rule technology world” nor these CMPM submissions have defined is a good business modeling technique to represent ECA rules. Such a business model may take the form of something as simple as a rule template, or something like a decision model. On the latter front, standardisation of decision models via the OMG DMN (Decision Model and Notation) effort seems to be gaining steam with pretty much all the main players in the process of registering (via Letters Of Intent) to take part. A good sign for process *and* rule standardisation … and of course decisions are somewhat useful in case management too!

EMP – time for an event standard!

BPMN2 event typesOne of the sessions at the EPTS VS was James Odell and Manfred Koethe presenting on the Event Metamodel and Profile RFP. I was surprised to see they already have some large vendors signed up for this. So why consider an “event standard”? What is wrong with say the TIBCO BusinessEvents idea that extends the idea of UML Class to build hierarchies of events, which in addition to properties and payloads have metadata like “TimeToLive” and datetimestamps?

1. There *is* a need for cross-enterprise understanding of events …  including derived, complex events, used across business and IT processes. So a common event spec should help here.

2. The requirement for such a standard is especially noticable when pushed up into the business domain (i.e. what are my business events?). Potentially this raises the bar for the vocabulary for event understanding to ontologies like OWL/ODM and SBVR, and associated modelling tools…

3. But what about the details of “complex events”? How can event relations etc be a part of this standard without treading on the toes of potential query versus rule language semantic issues? There is an easy answer to this (as I mentioned in the EPTS Virtual Symposium). We’ll see if the rest of the community agrees.

The “letter of intent” deadline to join the work on this specification is 20th May this year.

Decision Modeling Information Day @OMG

dtables-in-financeI was going to blog on the presentations at the Decision Modeling Information Day at OMG, but suffice to say that James Taylor has already done a great job of this so I will just add a few comments from the CEP perspective

1. CEP can be viewed just as “complex event” detection… but increasingly businesses want “complex  event” *processing*, where processing is not just event detection but also decision and reaction. Of course, the reaction can be a traditional orchestrated business process, as in a pattern like:

(a) detect fraud event (b) decide appropriate action (c) react with the Fraud Handling business process

2. Business modeling of decisions, as well as complex events, is an area that none of the traditional business modeling tools seem to be taking seriously. Yet both decision automation and CEP provide huge values to business operations.

3. Methodologists on the decision modeling side are finding receptive audiences in business. These include the KPI Decision Model, which was endorsed by Mark Pettit from Freddie Mac at the info day, the new BRS Question-Charts, and Alan Fish’s DRA. Adapting these for real-time, event-based decisions should be possible, as Larry Goldberg from KPI discussed in the meeting: the main difference with top-down analysis of decisions is that you may or may not be able to detect some of the desired business events!

4. There were some good questions on the role of analytics in, for example, driving CEP-based decisions, or in risk management for trading systems. For example, TIBCO Spotfire Data Miner can be used to generate rules for classification decisions inside a TIBCO BusinessEvents CEP system dealing with high volumes of trading events in a stateful manner.

5. The proposed DMN standard discussed at the end of the Information Day should of course equally apply to decisions in CEP as well as BPM.

Towards a comprehensive Date Time Vocabulary / Ontology

datetimeVery impressive work, by a team led by Mark Linehan of IBM Research, on Date Time was presented by NIST’s Ed Barkmeyer at OMG this week. This is a “work in progress” for likely completion later this year but clearly could play an important role in temporal operations in event processing.

To quote from the latest draft, the objectives of this work are:

1. Provide a Standard Business Vocabulary for Date and Time Concepts. Provide a vocabulary of date and time concepts that business users can share and exploit in their business domain vocabularies and rules…
2. Support Machine Reasoning about Time. Provide a formal ontology that enables machine interpretation and reasoning…
3. Enable implementation…

It covers a time infrastructure (intervals, Allen Relations, durations and SBVR “states of affairs” such as events and situations), organizing time in calendars, “indexical time concepts” such as the meaning of “now” etc in a business context, and so forth. Indeed it seems the only thing NOT covered are the ad hoc adjustments of “leap seconds” to a “year” that are made every now again. And there are versions for UML, SBVR and CLIF, and plans an ODM / OWL version.

Free report on the state-of-the-world in Event Processing

dagstuhlI see that last year’s Dagstuhl workshop report has been published, titled “Executive Summary and Manifesto — Event Processing”. This is an excellent 60-page group effort by some of the great-and-the-good in event processing, and recommended reading!

The top-level Table Of Contents is:

Chapter 1: Why event processing?
Chapter 2: What are the characteristics of event processing?
Chapter 3: Synergies and relations to other areas
Chapter 4: Event processing related standards
Chapter 5: Grand challenge: The global event processing fabric and its applications
Chapter 6: Near-term research

Disclaimer/disclosure: TIBCO was a co-author of Chapter 4.

Do Businesses need 63 different types of event?

BPMN2 event typesOne of the drivers of success in the BPM world has been BPMN – the Business Process Modelling Notation – developed under BPMI before it got absorbed into OMG, and probably a bigger success than any other modelling standard – and now as BPMN 2.o (beta, at this time) slightly reconfigured in name as the Business Process Model And Notation. BPMN is used to provide a “process” perspective (versus, say, a data or an event perspective) of a system and shows the flow or orchestration of process tasks and activities. It is made up of (per the excellent bpme.de BPMN2 summary poster):

  • 2 flow subtypes: sequence is the normal flow, with default and conditional conditional subtypes
  • 7 task types: send, receive, user, manual, “business rule” (really decision), service, and script
  • 6 activity markers: sub-process, loop, parallel, sequential, ad-hoc and compensation
  • 7 gateways: exclusive, event-based, parallel, inclusive, exclusive event-based, parallel event-based, and complex
  • 6 types of data: input, output, object, collection, store, and message
    and
  • 63 types of event

OK, “63 types of event” needs a bit of explanation (and justification). These consist of:

  • 13 main event types: untyped, message, timer, escalation, conditional, link, error, cancel, compensation, signal, multiple, parallel multiple, and terminate

… across 8 situations classified by location in a process:

  • Start: top-level, event sub-process interrupting, and event sub-process non-interrupting
  • Intermediate: catching, boundary interrupting, boundary non-interrupting, and throwing
  • End

… but with some situations not requiring certain types of event (e.g. there is no “start cancel process” event) leaving 58 63 event types defined [*1].

Presumably BPMN tools will let the user specifiy the main event type and associate the correct symbol from the context in most cases, leaving us to consider just the 13 main event types.

So let us analyse these event types from an event processing perspective:

  • Message and timer events: these are probably most familiar with to those with an event processing perspective, with a message relating to what we consider either a source or a derived event.
  • Escalation: this is really a deferal to a different process (e.g. a supervisory process), and can be handled by some internal message in event processing.
  • Conditional: this is “reacting to conditions becoming true” – in other words equivalent to a rule-firing (or event query) success. In a rule system this might be handled just by setting some fact or data, which in an inferencing rule system will use some internal event to signal to the rule engine that other rules may “fire” – however there is no need to explicitly model this behavior. I may also of course create an event (or in a query system, insert / update some event), which is again is not explicitly modelled as “conditional” per se…
  • Link: some means of connecting models: this is more a “page break” than a business event!
  • Error: I prefer the term “exception” here, which of course is a local context – an error event in one process is a normal event in an error-handling process, etc.
  • Cancel: this is more a transaction-specific event: if dealing with transactions then some events may indeed be “cancel transaction X” requests, which may or may not be satisfiable, etc.
  • Compensation: this is where some process route may require some compensatory process – for example in relation to a “cancel” event.
  • Signal: signalling information across processes: this is might be used as a control event, such as in controlling a choreography.
  • Multiple: one of a set of events is “caught” or provides the cue to continue the process.
  • Parallel Multiple: all of a set of events is “caught” to continue the process.
  • Untyped events are used for start and state changes. Typically, though, a state change is the main event we are interested in (in event processing)!
  • Terminate event – process complete! From an event perspective this (process end) might never happen of course…

The extra detail might be explained by the fact that in BPMN you are detailing *how* to implement a process, and the “event symbol” is providing you with some specific context for that event. In event processing languages, you usually describing “what* is to be processed, and where all events contribute to some situation or context. It will be interesting to see how these 58 symbols work out in practice, as a hindrance or a help for process designers…

Note:

*1: the table of events above, from the BPMN2 poster from bpmb.de, has 63 event symbols, and is slightly re-organised from the equivalent table in the BPMN2 beta specification (Table 10.93 pp 269-270, in 10-06-04.pdf). Interestingly the specification document also includes a table to detail the event symbols (Table 12.23 ppp 405-411, in 10-06-04.pdf) but this shows only 58 symbols! Let’s just say “lots of event types” in BPMN2 then…

OMG Decision Model Notation update

At the OMG technical meeting this week we had a review of the draft DMN RFP by the Business Modelling and Integration group experts, and a thought-provoking presentation by Barbara von Halle and Larry Goldberg of KPI on their KPI Decision Model which is proving very attractive to business analysts.

From an event processing perspective, “decisioning” is part of “event processing” in that it is the consumer of complex events: when you detect an event pattern you decide what to do with it. Of course, it is also extremely relevant to day-to-day business processes and operations…

Goals as related to processes (per Wikipedia)

Goals as related to processes (per Wikipedia)

Some of the conclusions the DMN RFP team came to this week:

  • Decision modelling is more than just a complement to BPMN, and indeed the RFP will not over-emphasise the relationship between the two. Indeed, in some respects, the “goal-driven network” idea for business models is as applicable to process models as it is to decision models. Decision modelling could become the dominant analysis aspect in future years: consider a business process like “loan approval” and you don’t need a degree in computer science to work out that the business process is there just to support the business decision on whether to approve a loan!
  • Barbara and Larry emphasised the need for metrics and business motivation in decision modelling. Monitoring decision events is of course yet another event processing task.
  • The “business model” – “IT model” dichotomy can take many forms in a decision model, with the classic being the business analysis model being the logical decision structure or goal-driven network, using business terminology, with the underlying decision metaphors (such as decision tables – the first and obvious choice for the DMN RFP) being IT models. Transformations from things like SBVR to UML Class, and decision table to PRR, will be out of scope for DMN itself though – such transformations will either be subject to other standards or be vendor-specific. But they and the Model Driven Engineering ideal become much clearer using a DMN.
  • The logical decision model or goal-driven network has ramifications for the inference rule engine business. I’ll blog on that separately! :)

So in summary: DMN is looking like it could be very useful. And I expect attendees at the RulesFest and BAForum conferences next month will enjoy the KPI show as much as I did. For those interested in decision metaphors, BRForum (alongside BAForum) also has the Decision Table World Congress

Case Management, Social BPM and other extensions to the business process idea

Forrester (and prior to that, long-time independent) BPM consultant Derek Miers often extolled the virtues of “case management” over “generic BPM” (and it was often commented that TIBCO BPM technologies were well regarded in this area). Yet until recently there seemed to be not much going on in the case management space except for the appearance of a few specialist case management vendors.

Then TIBCO and Cordys presented back in 2008 on “Dynamic Business Activity Modelling” that led indirectly to the current OMG RFP work on the “BPM superset” called “Case Management”. The pertinent TIBCO technologies we presented, over and above conventional BPM, were Conductor (goal-driven processes), CEP (rule and event-based processes), and combinations thereof (goals, rules, CEP, processes) such as in TIBCO AFF. Subsequently it seems that there has been a veritable explosion in interest around case management: for example, Fujitsu’s Keith Senson (chair of the WfMC) has published an acclaimed book on what he and WfMC are calling Adaptive Case Management. Per WfMC and the very popular LinkedIn discussion board on this, the area also covers the idea of social collaborations in “process” development and execution (another hot topic, per advocates such as Sandy Kemsley).

One intepretation of how processes work with event processing and rules

Processes, decisions, rules and event processing, with Inference Rule use cases

At the OMG meeting last week I discussed the nascent OASIS SAF framework with CA’s Paul Lipton, and its possible role in providing a standardised collaborative (a.k.a. “social) community framework for suggesting / organising / developing solutions (a.k.a. “processes”) to problems (e.g. business goals and issues – see BMM) … we will cover more on this idea later. Meanwhile, I offer the interesting observation that (1) SAF is based on the ideas of medical practices (symptoms, prescriptions, etc), and (2) case management’s widest use is probably healthcare (e.g. see the Wikipedia reference). Coincidence?

From the CEP perspective, I presented at OMG and SemTech this week the idea that business processes are just ways of organising events, decisions and actions, and that capabilities like Operational Intelligence are just advanced business processes – and are dynamic and “case oriented” too in many scenarios…