[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [saf] Possible TC Actions to Consider
I see the dilemma in either keeping the medical analogy or going full-IT or something else... the name of the specification is tied to this decision.
It depends a lot on what we want to be the focus. I believe we would want a very broad core specification and then do a deep-dive in each domain applications of the core spec, possibly in sub-groups under our TC or even totally different specifications spawned in OASIS after the core spec is ready. The IT Management space would be one, the Cloud space another, then others like Process Management, specific industries like Energy, Healthcare, etc. All these domains would have the option to extend the core spec to their own needs and to define authoritative classifications types for symptoms/syndromes/prescriptions/etc. (for better exchange of knowledge among intra-domain implementations).
A good non-biased replacement for "autonomic" has always been "self-management" but then again "management" has a bit more of an IT-specific connotation...
If we go with the IT-biased terminology my suggestion is this:
SMF - Self-Management Framework
AMF - Automated Management Framework
If we stick with Medical terminology:
SDF - Self-Diagnostic Framework
SDTF - Self-Diagnostic & Treatment Framework
If we abstract from everything and try to have a very broad terminology that can be applied to any multiple domains:
SRF - Self-Reasoning Framework
RAF - Reasoning & Automation Framework
SRKF - Self-Reasoning & Knowledge Framework
In my particular opinion I think we should eliminate the IT-biased option. I believe a medical analogy is something that everybody understands and despite what blog comments elsewhere may say it's something that differentiates this effort and gives it an interesting appeal... In a close second I also favor a broader generic terminology with the words "Reasoning", "Knowledge" and "Automation"... these are terms that - in my opinion - fit well in several different application domains - but are not as appealing I think.
I also disagree with having terms like Optimization and Remediation in the name associated to the core spec because I believe the uses will be broader than that - including prediction/avoidance and full root-cause resolution of problems (not only remediation), security issues identification and prevention, configuration and deployment issues, etc. In autonomic computing terminology we used to classify "Self-Management" in four different quadrants: Self-Healing, Self-Configuring, Self-Optimizing and Self-Protecting - symptoms were supposed to help in all quadrants, not being specific to one or two of them...
I'm also not too keen with "Framework" - I wish I had a better suggestion for that, but at the moment I haven't...
Marcelo Perazolo
IBM Systems Director
IBM Corporation
phone: +1-919-5438491
email: mperazol@us.ibm.com
"Lipton, Paul C" ---10/26/2009 02:01:52 PM---Hi all,
From: | "Lipton, Paul C" <Paul.Lipton@ca.com> |
To: | <saf@lists.oasis-open.org> |
Date: | 10/26/2009 02:01 PM |
Subject: | [saf] Possible TC Actions to Consider |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]