Draft Reference Architecture

Some folks may have seen earlier updates on the EPTS Reference Architecture work. Well, the latest (Architect role Functional view) draft seems to be getting some approval (so far) among Reference Architecture Working Group members. Some of the terminology may change slightly to conform to (or influence) the EPTS Glossary; other roles and views are still in progress.

EPTS hasn’t set up a public review mechanism yet, so participants’ blogs will have to do: feedback posted here will be posted back to the working group wiki. Once the Working Group is satisfied with this, the Steering Committee and membership of EPTS will vote on it, and then it can be made “official”.

… was one made at the recent webinar promoting an OASIS standard for system event processing. Odd though, as of the 3 (non-TIBCO) vendors involved, one has acquired a Business Rule Management System provider, and one used to be a big provider of Business Rule Engines…

Now “rule maintenance” (/management) is a specialized type of content management, and related to other types of business model management (including business process management). Typically it’s just decision rules that are managed formally by business users (as opposed to, say, data relationship rules which are usually “baked in” to IT databases too much to be easily modified) [*1].

So, being generous, perhaps the OASIS speaker was referring to the lack of capability to easily manage and maintain all possible types of business rules in an application… although cynics might argue it was just a comment to justify not tieing SAF too closely to rules execution and rules engines…

Notes:

[1] TIBCO’s offering in rule management - TIBCO BusinessEvents Decision Manager - covers decision services and agents for use within BusinessEvents applications to be applied to business events as they are detected.

My thanks to Robin Cover at standards body OASIS for pointing out to me the OASIS Symptoms Autonomic Framework initiative. From the OASIS TC page, SAF is meant to:

“… integrate information and processes across the organization … by defining, enhancing, and maintaining a standard XML-based framework that will enable the collection, detection, isolation, and remediation/optimization of the operational or business characteristics of complex systems with applicability to both IT and non-IT domains including operational and service management, governance, and security.”

If that paragraph proves difficult to digest, the overview goes on to say more succinctly:

“SAF is intended to provide a common language for exchange of event-driven data in a distributed-computing, multi-vendor environment.”

In other words this is either a DSL or XSD  for “control events”, of the type handled by TIBCO’s CEP-based ActiveMatrix Service Performance Manager (i.e. the autonomic services’ performance policy engine) and its cloud (TIBCO Silver) oriented derivative. So it should certainly be targeting complex event processing of these control events.

The SAF Charter explains the SAF goals further as:

“Ensure that the specifications can be applied to various sources of event data, enabling a methodology to perform pattern matching, diagnostics, and analysis in order to achieve a timely and accurate resolution of a wide range of IT and non-IT situations.”

Sounds possibly a little wide-ranging, but we assume the 3 (as of Oct09) member organizations know where they are going with this.

The charter goes on to describe the medical-based terminology used in SAF, including  “symptom” as a current state, “syndrome” as a collection of symptoms, “protocols” used to generate “prescriptions” which in turn are (data) used to confirm, remediate or optimize a syndrome. Syndrome confirmation is (naturally enough!) via a “diagnosis” effected through  “validating Symptoms”. One wonders what ailments the authors had when coming up with this healthcare-analogous vocabulary!

The architecture roles mentioned also stay in the “doctors and nurses” theme: we have a Syndrome and Protocol Catalogs, a Symptom Store, a Diagnostician, a Practitioner (to administer Prescriptions), and a Case Manager (general manager). Probably someone could do a reasonable mapping of these to the EPTS Glossary and Architecture work…

Looking at the White Paper from the SAF docs collection we see a much closer correlation to the CEP world with use cases of “Denial Of Service attacks” (a.k.a security), “identity theft” (i.e. fraud), energy industry “data analysis”, and manufacturing “process optimization”.

Overall this looks an interesting effort - interesting in that the authors have found a compelling reason to develop the SAF standard, rather than the content itself - but one would expect that persuading end-user organizations to comply with a SAF approach to automating diagnostics and remedies will be a tall order. If the standard does prove compelling, then Complex Event Processing tools like TIBCO BusinessEvents should have no problem in reading SAF payloads, applying SAF roles and implementing SAF-type implementations. So one to keep an eye on, then…

… is the title for the replacement to (and presumed superset of) the Case Management OMG specification proposal, per this report from OMG task force co-chair Fred Cummins, albeit within the interesting context of advanced healthcare IT [*1].

Very relevant to the knowledge-driven medical domain (and to case management) is the ability to respond to events (as in event-driven or event-based processes) - events provide new information that extend both the current patient and medical condition knowledgebases, for example. Out-of-sequence and disruptive events need to be handled, and medical deductions and conclusions can certainly be defined as “complex events” (i.e. aggregations and combinations of prior events) … probably with the addition of some probability factor!

Also very relevant is that inference rules are one of the more useful knowledge representation mechanisms - used both in formal logic as well as business rule engines - making rule-driven processes truly declarative, ad hoc and dynamic. Event-driven and rule-driven processes are both areas covered by CEP technologies like TIBCO BusinessEvents. And in OMG inference rules are covered by the PRR extension to UML.

On the other hand, the term “knowledge-driven” [*2] can cover a number of things beyond “event-driven business processes” and “rule-driven business processes”. For example, events can be viewed as documentable and classifiable constructs for use in ontologies (like OWL), and rules can be followed by medical staff, such as via checklists or flowcharts. There is also the domain of “knowledge management” in the form of content or document management  - probably ideal for case note recordings.

Fred’s comments include:

“Knowledge-driven processes for treatment of medical conditions will support intuitive medicine with improved tracking and record-keeping while supporting performance measurement and encoding of insights to improve and streamline practices.” Whenever I read “tracking” and “performance measurement” I think of event tracking and concepts like “track and trace”. When I  read “encoding of insights” I see “situation awareness”. Note these are both key complex event processing indicators!

“Specifications of activities can easily be changed to introduce new technology or to provide guidance in the use of certain procedures or medications. More precise processes can be incorporated using conventional business process modeling technology, but processes can still be adjusted to deal with unforeseen circumstances.” I’m pretty sure Fred doesn’t mean to imply ad hoc processes are imprecise, but in fact may be selected or defined according to current knowledge. Knowledge representation in automated systems usually involves rules - and event-driven rules are typical of CEP technology.

“Both intuitive and precise processes can be interwoven and evolved as improved techniques that are discovered or developed.” This means ad-hoc processes mixing manual and automated processing. Most medical processes involve a health-practitioner-in-the-loop, so this makes perfect sense.

In my humble opinion, knowledge-driven processes (including medical processes), and their associated models, are a very interesting area, with much overlap with the state-of-the-art rule-driven CEP world. Whether there is enough concensus for a standardization effort yet, given (1) only 2 vendors responded to the preceding OMG RFI on “dynamic process activity modeling” and (2) “knowledge-driven process” is such a new term it doesn’t even have an entry on Wikipedia yet (!), is open to debate… which no doubt will occur at the next OMG meeting.

Notes:

[1] Interestingly, advanced medical healthcare support is one of the first use cases in the EPTS Use Cases Working Group.

[2] Possibly the proposed standard is simply misnamed. For example a better fit might be the moniker “Ad hoc Process Modeling” (or somesuch) that would avoid any contentious issues around “knowledge” coverage and representation.

Thanks to TIBCO’s Scott Vorthmann for updating me on the SCA-Assembly-Extensions-for-Event-Processing-and-Pub/Sub draft, which was reported on InfoQ a few months ago. This seems to be mostly an Oracle + IBM effort, and seemingly is occuring outside of OASIS, which seems strange if it is true.

• There is some interesting commentary on its relevence versus the WS-Eventing / -Notification efforts. Possibly all these are together in the same logjam. Some of the associated comments seem to make the case that there is a difference between message processing and event processing - even if most CEP tools utilise messaging systems as transports for events, the appearance of a message *is* an event, etc….
• This SCA effort seems to have similarities with the OMG Event Metamodel and Profile initiative - indeed “SCA-AE4EP&PS” would likely be an input to EMP (if either take off).
• Work seems to be progressing on an initial implementation anyway as a part of the Apache Tuscany project - they have a page on event processing too - but one gets the impression the differences between services, components, and event processing components might be a problem here.