Symptoms Autonomic Framework submission to OASIS: CBE meets ITIL?

IBM, Fujitsu and CA have recently proposed a charter for a new OASIS technical committee, called the Symptoms Autonomic Framework (SAF) TC. Including a specification candidate and other submitted documents, listed here.

For context, you need to remember the Common Base Event (CBE) specification that IBM has shopped around for a long time, initially hand in hand with Cisco. As always, the Cover Pages offer the best references on this saga. CBE was submitted to WSDM and came out (in a much-emaciated form) as the WSDM Event Format (WEF) in WSDM 1.1 part 2.

Because so many parts of CBE were left on the floor of the WSDM editing room and because WSDM itself saw little adoption, I have always been expecting IBM to bring CBE back in some form. When I heard of SAF, my instinct was that this was it.

Not so. SAF is meant to sit on top of an event system like CBE. It turns selected events/situations and other data points into symptoms and tells you what to do next. Its focus is on roles, process and knowledge bases. Not on the event format. The operations and payloads defined are not for exchanging events, they are for exchanging “symptoms”, “syndromes”, “prescriptions” and “protocols”.

As the terms show, the specification espouses the medical dialect (even “protocol” is meant to be understand in the medical sense, not as in “HTTP” or “FTP”). While I have been guilty of a similar analogy myself, I also think that if there is one area from which we don’t want to learn in terms of automation, system integration and proper use of IT in general, it’s the medical field. So let’s be careful not to push the analogy too far (section 8.1 of the SAF specification is a fun read, but not necessarily very compelling).

BTW, since when do we use terms strongly associated with one company in the name of standards group (“autonomic”)?

More fundamentally, the main question is what the chances of success of this effort are. Its a huge endeavor (“enabling interoperable diagnosis and treatment of complex systems”) and it tries to structure activities that have been going on for a long time and in many different ways. No-one will adopt this structure for its own sake, so the question is what practical benefits can be derived from this level of standardization. For example, how reliably can incoming events be mapped in practice to symptoms, how efficiently can symptoms be matched to protocols (in typical IBM fashion there seems to be a big  “XPath is my hammer” assumption lurking), etc…

The discussion on the charter is currently open in OASIS if you want to weigh in.


Filed under Automation, Everything, IBM, IT Systems Mgmt, ITIL, Mgmt integration, Specs, Standards

4 Responses to Symptoms Autonomic Framework submission to OASIS: CBE meets ITIL?

  1. Stu

    I’ve seen this sort of thing implemented in practice (i.e. at BEA, there was Guardian

    The problem primarily is, of course, that prescription processes are highly context-dependent, and so while these systems can be “OK” at simple detection and diagnosis, automated resolution is unlikely until you can find ways to build a more contextual-aware prescription. They recognize this with the split between “Protocol” and “Prescription”, though I’m curious as to how they intend to implement it, short of generating BPEL processes at runtime. Which is only half-crazy.

  2. JINSPIRED JXInsight had this implemented well before BEA Guardian which was effectively dead-on arrival because it really had very little in the way to offer in terms of both the software execution and system execution models. Guardian focused mainly on the actual static (and to some degree dynamic) configuration of the application server whereas our approach looked at the behavioral and dynamic (and temporal) state change aspects of the software being monitored (or diagnosed). When a snapshot is loaded up our management console we associate various observations (linked to symptoms) with each execution element. Symptoms are in turn associated with one or more problems which in turn are associated with causes and advice statements.

    It does work to some degree when used in a problem management context but lets be honest here most organizations are still at stage one – incident management. Problem analysis is largely adhoc in terms of process, products and people.

    At the end most want tools that “don’t have me think” hence the need for all those large RED and GREEN circle dashboards that cost an arm and leg and provide very little value outside of narrow cases.

  3. stavros

    I know I’m late to this discussion but:

    “I also think that if there is one area from which we don’t want to learn in terms of automation, system integration and proper use of IT in general, it’s the medical field”

    while I agree that the analogy should not be pushed too far, the point is NOT to borrow IT management ideas from the medical field (that’s just naive inference)! Simply to borrow the language as it is easily understood and maps naturally to what SAF is supposed to be doing.

    Stu, why do you think generating BPEL processes is half-crazy (just curious for justification, mind you :-)). One of the points I think is this decoupling of the generic framework from the context/domain specific “rules” set. But SAF is not merely a rules-based system.

  4. Hi Stavros,

    Yes, I understand that the SAF proposal doesn’t borrow IT technology from the medical field, just terms and concepts. What’s an occasional cheap shot between friends? ;-)