|
|
01-25-2008
Registered User
26,240,
27
What’s coming in CEP: Modeling of Events?
vincent
Thu, 24 Jan 2008 23:07:09 +0000
One of the "next big things" for the CEP industry to consider is the modeling of "events", both from a business and IT perspective [*1]. Events from a business perspective [*2] might include:
- sending or receipt of a business instruction (order, order cancel, order query, payment, payment receipt, service statement, etc)
- observation or notification of some business activity, task or process (flight landing, train departing, order shipment, ERP batch process completion, etc)
These can be considered "base", simple events, from which more complex business indicators can be implied or inferred:
+ a Service Level Agreement is at risk of being broken
+ a customer (or group thereof) is likely to be dissatisfied
+ business performance is improving / getting worse, per some Key Performance Indicator(s) such as account balance, number of customers, number of new customers, etc.
Of course, the latter may traditionally be derived by conventional data processing (business processes, IT services, databases, and all the corresponding IT paraphanalia), or through Complex Event Processing. Such business indicators may of course be then used as "high level" events or data for additional inferencing of other useful metrics, at operational or executive levels.
So how does one model / represent these events, both base/simple and complex/derived [*3]? To date, the representation is tied closely to the event processing paradigm: for example, in TIBCO BusinessEvents we define or map an event from an underlying IT message (such as from JMS or TIBCO EMS, or TIBCO Rendezvous, which in turn can be fed from a wide range of disparate IT system adapters). But we represent missing events through the use of a UML State Model, and event patterns through the use of event declarations defined in rule conditions (per UML Production Rule Representation or PRR). Other tools describe patterns in (potentially wordy and complex) SQL statements, or as proprietary process graphs and procedural languages.
One of the current initiatives to address event modeling at a standards level is the OMG Event Metamodel and Profile (EMP). This will likely extend UML Events to enable easier event modeling for CEP, through the process of having the relevant members of OMG argue what needs to be done for what and where. Related standards include the OMG Business Process Definition Metamodel (BPDM), which also models business "happenings" as they pertain to conventional business processing / BPM, the OMG Business Motivation Model (BMM) which describes the motivations of the business but stops short of operational aspects, and the OMG Semantics of Business Vocabulary and Rules (SBVR) which describes business vocabularies in general terms, including (presumably) descriptions of business-level events. Of course, there are also various IT message/event standards in abundance, such as the Java’s already mentioned JMS, and WS-Eventing (for those stuck in a web service track).
So what will happen next? As the evolution of the Model-Driven approach, with business-through-IT modeling for traceability and governance, continues apace, the modeling of business events and event patterns alongside processes is bound to become a requirement. It could well be the next item on the OMG agenda after Organization Models; watch this space!
Disclaimer:
This blog entry is NOT a future product announcement! No Product Managers were harmed in the writing of this blog message.
Notes:
[1] IT events will normally correspond 1-to-1 with base business events: the B2B communication is a message with an XML payload whose occurance is precisely the same from both the business and IT perspectives. Others may be more circumspect: the mailing of a letter (and signal as such from the mailing department) may be an intended event, but does not guarantee receipt by the addressee.
[2] Some pundits have commented on the use of the term "Business Event Processing" as a potential replacement for "Complex Event Processing". Unfortunately, the 2 terms are orthogonal. Conventional BPM tools process business events (input: a customer order; output: a receipt letter, etc). CEP tools process events differently, to correlate across events in time and source, to produce new event information. For sure, most of the events I am interested in processing and/or deriving in CEP are business-related events (where business includes everything from finance through healthcare through military C4I through process control). This is similar to a "discussion" at the last ETPS meeting, where some of the use cases looked succinctly BPM-like (BPM is good, but its not CEP).
[3] Not that we want to get into the somewhat academic discussion of "event classification". Or an "ontology of events", which in any case is likely to be domain-specific in its structure, and application-specific in its metadata needs.
Source...
Thu, 24 Jan 2008 23:07:09 +0000
One of the "next big things" for the CEP industry to consider is the modeling of "events", both from a business and IT perspective [*1]. Events from a business perspective [*2] might include:
- sending or receipt of a business instruction (order, order cancel, order query, payment, payment receipt, service statement, etc)
- observation or notification of some business activity, task or process (flight landing, train departing, order shipment, ERP batch process completion, etc)
These can be considered "base", simple events, from which more complex business indicators can be implied or inferred:
+ a Service Level Agreement is at risk of being broken
+ a customer (or group thereof) is likely to be dissatisfied
+ business performance is improving / getting worse, per some Key Performance Indicator(s) such as account balance, number of customers, number of new customers, etc.
Of course, the latter may traditionally be derived by conventional data processing (business processes, IT services, databases, and all the corresponding IT paraphanalia), or through Complex Event Processing. Such business indicators may of course be then used as "high level" events or data for additional inferencing of other useful metrics, at operational or executive levels.
So how does one model / represent these events, both base/simple and complex/derived [*3]? To date, the representation is tied closely to the event processing paradigm: for example, in TIBCO BusinessEvents we define or map an event from an underlying IT message (such as from JMS or TIBCO EMS, or TIBCO Rendezvous, which in turn can be fed from a wide range of disparate IT system adapters). But we represent missing events through the use of a UML State Model, and event patterns through the use of event declarations defined in rule conditions (per UML Production Rule Representation or PRR). Other tools describe patterns in (potentially wordy and complex) SQL statements, or as proprietary process graphs and procedural languages.
One of the current initiatives to address event modeling at a standards level is the OMG Event Metamodel and Profile (EMP). This will likely extend UML Events to enable easier event modeling for CEP, through the process of having the relevant members of OMG argue what needs to be done for what and where. Related standards include the OMG Business Process Definition Metamodel (BPDM), which also models business "happenings" as they pertain to conventional business processing / BPM, the OMG Business Motivation Model (BMM) which describes the motivations of the business but stops short of operational aspects, and the OMG Semantics of Business Vocabulary and Rules (SBVR) which describes business vocabularies in general terms, including (presumably) descriptions of business-level events. Of course, there are also various IT message/event standards in abundance, such as the Java’s already mentioned JMS, and WS-Eventing (for those stuck in a web service track).
So what will happen next? As the evolution of the Model-Driven approach, with business-through-IT modeling for traceability and governance, continues apace, the modeling of business events and event patterns alongside processes is bound to become a requirement. It could well be the next item on the OMG agenda after Organization Models; watch this space!
Disclaimer:
This blog entry is NOT a future product announcement! No Product Managers were harmed in the writing of this blog message.
Notes:
[1] IT events will normally correspond 1-to-1 with base business events: the B2B communication is a message with an XML payload whose occurance is precisely the same from both the business and IT perspectives. Others may be more circumspect: the mailing of a letter (and signal as such from the mailing department) may be an intended event, but does not guarantee receipt by the addressee.
[2] Some pundits have commented on the use of the term "Business Event Processing" as a potential replacement for "Complex Event Processing". Unfortunately, the 2 terms are orthogonal. Conventional BPM tools process business events (input: a customer order; output: a receipt letter, etc). CEP tools process events differently, to correlate across events in time and source, to produce new event information. For sure, most of the events I am interested in processing and/or deriving in CEP are business-related events (where business includes everything from finance through healthcare through military C4I through process control). This is similar to a "discussion" at the last ETPS meeting, where some of the use cases looked succinctly BPM-like (BPM is good, but its not CEP).
[3] Not that we want to get into the somewhat academic discussion of "event classification". Or an "ontology of events", which in any case is likely to be domain-specific in its structure, and application-specific in its metadata needs.
Source...