What Analysts Need to Understand about Business Events…

November 17, 2011 by Leave a Comment
Email

… was the title of the Business Rules Forum session presented earlier this month, targeting the Business Analysts attending the BBC2011 conference. This includes a quick overview of (some) of the various ways to model events (in business models), including using the EPTS Reference Architecture as a guide to event operations required or events desired. Sandy Kemsley did a great overview on her blog, by the way (and Sandy also covers event modelling in her tutorials and training).

Feedback welcome, and of course I’ll be adding things like VPEC-T to version 2 of this.

What analysts need to understand about business events – v1.2

Filed Under: Complex Event Processing (CEP) Tagged With: , , , , ,

Decision Modeling Information Day @OMG

March 24, 2011 by Leave a Comment
Email

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.

Filed Under: Complex Event Processing (CEP) Tagged With: , , , , , ,

After an Event comes a Decision…

January 18, 2011 by 1 Comment
Email
oodaloop

Analytics Magazine on OODA

While discussing the proposed OMG Decision Modelling standard with business rules specialist Ron Ross recently, Ron reminded me of the list of “roles” that “decisions” can provide:

Classification, Evaluation, Selection, Approval, Assessment, Assignment, Allocation, Diagnosis, Prediction

Curious as to what sources might refer to this list, I “googled” for these terms and one of the first relevant results was…

Threat evaluation and weapon assignment decision support: A review of the state of the art (2006-2007)

This is a fascinating paper that targets the military domain but nonetheless is very relevant to CEP (and indeed business) methodology:

  1. “Threat evaluation” is also a business task: business threats are things like poor customer satisfaction, poorly managed product marketing, changing business conditions (locally or across the business), inability to predict business changes, regulatory compliance risks, and so on.
  2. “Command and control” (a.k.a. business management) methodologies are also of interest: the paper refers to Boyd’s Orient-Observe-Decide-Act (OODA) cycle, Lawson’s Sense-Process-Compare-Decide-Act cycle, and a Monitor-Assess-Plan-Execute cycle.
    • Orient means setting up measurements, or event sources
    • Observe, Sense-Process-Compare, and Monitor means event (including “complex event”) detection, and all the associated processes for complex event processing.
    • Decide means making some decision based on our observed events.
    • Act and Plan-Execute mean behaviors that in turn will likely affect the environment and future events.
  3. The paper refers to the JDL Data Fusion model which may well be familiar to some CEP folk: this model describes (with a minor translation from the table in the paper) the use of and relationships between:
    • event assessment
    • complex event or entity assessment
    • situation or state assessment
    • impact or cost-benefit assessment
    • performance or goal assessment.

I would therefore claim that the relationship between events and decisions seems not only very clear, but also well recognised.

Filed Under: Complex Event Processing (CEP) Tagged With: , , , , ,

REA – an ISO event standard – for accounting

December 10, 2010 by Leave a Comment
Email

This week the OMG held its technical meeting and as usual there were some very interesting sessions – particularly the Tuesday meeting by the Business Architecture folks on “Value and Innovation” hosted by William Ulrich. This covered:

- Value Chain Modelling: where the actors or agents in an organisation have their inputs and outputs analysed to see what value is being added to a business and where – information which can then be used to prioritise investments, process improvements, etc. There is an effort to standardised a metamodel for Value Chain modelling – the VDM or Value Driven Metamodel. A good adjunct to BPM and Enterprise Architecture levels of business modelling, in my opinion,and related to metrics and BAM (Business Activity Monitoring) to identify the state of your “value chain” and your business operations’ net-current and potential values.

- REA or Resources, Events, Agents – provides a slightly more detailed view of the same value perspective. Agents, or actors, add value to  Resources, via Events. Simple, really. CSC’s Klaus Loehnert and Pavel Hruby presented this, with an excellent decomposition of REA diagrams to business events (what they called the IT implementable layer) as well as abstraction up to a value chain model.

To differentiate REA events (which are accounting abstractions of real events) from other events, the term “economic event” is used (and indeed economic resources and economic agents).

The REA concept was first published in 1982 by William McCarthy and is now an ISO standard – see ISO 15944-4. So now you can answer any pub quiz (or inane RFP) question on “what is the ISO standard for business events” …

In both the above, REA and value chain models could probably be emulated in TIBCO BusinessEvents by using a state model and scorecard, with results displayed in a TIBCO BE Views dashboard.

Filed Under: Complex Event Processing (CEP) Tagged With: , , , ,

Do Businesses need 63 different types of event?

November 23, 2010 by 8 Comments
Email

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…

Filed Under: BPM, Complex Event Processing (CEP) Tagged With: , , , , , ,

Modelling Rules and Inferences: the goal network diagram

October 11, 2010 by 2 Comments
Email

The Goal NetworkThis week is RulesFest in San Jose California, at the Dolce Hayes Mansion on the South side of the city (which I think I last visited a decade ago during a dot-com-era company party that involved riding, er, “toilet buggies” around a car park – thats quite enough reminiscing I think).

One of the presentations planned this week is by Barbara von Halle and Larry Goldberg who wrote the “Decision Model” book, and who are one of the influences for the DMN Decision Modelling standard being worked on (as an OMG RFP) with IBM and Jan van Thienen (Mr Decision Table). One of the things I liked about the KPI model is how it can be viewed as a Goal Network model (albeit more an analytical logical tree in KPI’s view) for organising decision metaphors like decision tables. Such a Goal Network is of course ideal for modelling inference rulesets of the type used in rule engine programming and complex event detection: the goals define the intermediate states and the rule conclusions represent goals that are subgoals in other rules’ conditions.

The interesting thing about the Goal Network is that it applies equally to process design and decision design (where decisions can be decision tables or inference rulesets or anything else). The nice thing about a Goal Network for inference rule engines is that the goal network can be “executed” automatically during “inferencing” or rule engine processing; with decision tables you have to explicitly control the execution path (which of course could be preferable in some scenarios).

I’ve a strong feeling that “goal networks” and their multiple viewpoints are the next interface development area for those bridging the gap between business models and IT.

Filed Under: Complex Event Processing (CEP) Tagged With: , , , ,

OMG Decision Model Notation update

September 22, 2010 by Leave a Comment
Email

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…

Filed Under: BPM, Complex Event Processing (CEP) Tagged With: , , , ,

Do “events” have “durations”?

September 7, 2010 by 18 Comments
Email

This might seem an odd question, but there are 2 schools of thought here:

  1. An event is a point in time.
  2. An event is an activity that can take a period of time.

Taking the latter view, we can say things like:

  • Earthquake MMM took place from date-time D1 to date-time D2
  • Fraudulant act on account NNN took place from date-time D3 to date-time D4
  • Flight QQ123 was delayed in the period date-time D3 to date-time D4, when it completed disembarkation time T1 late
  • World War 2, an historical event, took place from 1 September 1939 to 2 September 1945.

The problem with this view is that activities, and therefore processes, can therefore be viewed as “events”, which in IT terms can lead to confusion and generalisation. And what about “historical events” like World War 2, which definitely have a duration. But in reality “world war” was a “state” the various nations affected found themselves entangled in – for sure it had a start event (invasion of Poland) and an end event (surrender of Japan), and many many events in between. And indeed many many “predictor events” (or even “causal events”) beforehand.

In event processing terms, we want to predict certain events – when will Earthquake MMM start, and with what strength? – as well as states – Flight QQ123 is now in a “delayed” state. In effect, in the real world, we are concerned not just with event patterns, but also state management and processing. Passengers might not care about the events that lead to their flight being delayed, but they may certainly care about being delayed!

The EPTS Glossary specifies events as points in time as “instantaneous events”. From the EPTS perspective, the 1929 Stock Market Crash was a complex event. At the time it was a “crashing state” for the Wall Street markets – within a period of instability, local rises interspersed with sharp falls. Top-to-bottom, the period covered Sept 1929 to July 1932, and an overall 89% decline in the Dow.

So perhaps History should be formalised, as a science, using event terminology?

Filed Under: Complex Event Processing (CEP) Tagged With: , , ,

Event processing, states, and something called BEDL

April 27, 2010 by 3 Comments
Email

BE4 State ModelI don’t normally have much to say on BPEL (as a language for orchestrated processes). A BPEL engine can be used to execute business processes and actions post-”complex event detection”, but at the end of the day its just a particular – albeit common and standards-based – technology for executing process orchestrations [*1].

On the other hand, state management of entities is particularly interesting for Complex Event Processing. In a nutshell, the state of some entity will often determine some event pattern detection, as well as the relevance of certain business decisions, operations / processes, and actions. CEP tools handle state, and some (like TIBCO BusinessEvents) actually allow developers to model state explicitly – usually for entity lifecycle management, including complex event pattern lifecycles…

It was therefore somewhat fascinating to find a new IBM initiative called BPEL4Data and an associated Business Entity Definition Language (BEDL) comprising of entities and state models (and indeed, almost MDM-like data management operations) [*2].

One trick I think the IBM team have missed is in tying themselves to (another reinvention of) BPEL. State models involve states and event-driven state transitions: to me this means that states are part of the behavior of entities, an active not a passive attribute. And conditional state transitions mean rules rather than processes. Ergo its no accident that TIBCO BusinessEvents state models are defined in an environment that combines them with events and declarative rules.

Of course BPEL – and orchestrated BPM – have their place and use cases – indeed TIBCO has many successful BPM customers, some of whom are combining entity models and states (in TIBCO BusinessEvents) to control workflow processes (in TIBCO BPM). There are indeed many patterns to combining event-based state changes with process orchestrations, and IBM’s focus on just one will be interesting to watch.

Notes:

[1] TIBCO’s BPM group of course has much more to say on BPM and BPEL …

[2] TIBCO followers will be bemused by the acronym overloading here:
- IBM BEs (Business Entities) are directly equivalent to TIBCO BE (BusinessEvents) concepts, with UML-based state models applicable to both.
- IBM BEs map via IBM BPEL4Data to BPEL business processes, whereas TIBCO BE concepts and states are directly executed in the TIBCO BE rule engine (with no BPEL intermediate step, if you like), with BPM processes as optional (downstream) activities.

Filed Under: BPM, Complex Event Processing (CEP) Tagged With: , , , , , ,

Event standards? The Event Ontology and Events-ML

February 12, 2010 by 7 Comments
Email

Reading a paper from last year’s Knowledge Capture (K-CAP 2009) academic conference, I came across some references to various “event standards”. All of these were very domain specific, but 2 seemed they might have more generic uses.

One was Events-ML G2 from the International Press Telecommunications Council for registering “events as in conferences, meetings etc” (rather than the sorts of events the CEP world is mainly interested in). The event schema therefore includes properties such as phone and contact details, implicitly recording the observer’s data on the event (as opposed to some observer identifier from which that and other data could be gleaned, presumably). On the other hand they did have a nice test form!).

Event in Event Ontology

Event in Event Ontology

There was also an “Event Ontology” defined as part of a Music Ontology (!) project. Things started well when the authors stated:

This ontology is centered around the notion of event, seen here as the way by which cognitive agents classify arbitrary time/space regions, which is essentially the view expressed by Allen and Fergusson [or its HTML version via Google].

The next quote was less impressive though, seemingly going beyond abstraction and on into the realm of philosophy…

[..] events are primarily linguistic or cognitive in nature. That is, the world does not really contain events. Rather, events are the way by which agents classify certain useful and relevant patterns of change.

Reviewing their definition of event we see relationships between event and:

  • place and time
  • factors and products
  • agents (acting on the events)

Presumably from the musician’s point of view, a set of notes (as events) may combine into a musical chord (an event product) – or in other words, agents combine events and context (“factors”) to define complex events (“products”). So not a million miles away from the EPTS’ labors on the EPTS Glossary, newly refreshed in a draft version 2…

Filed Under: Complex Event Processing (CEP) Tagged With: , , , , ,
«Older Posts