RE: [saf] Cloud Profile Value Proposition

["Lipton, Paul C" <Paul.Lipton@ca.com>]

Title: Message

Hi all,

 

Continuing the thread on identifying value proposition(s). I think it would be easier to start with value propositions now focused on Cloud Profile, perhaps leveraging the ideas proposed below for that purpose. Afterwards, a more general discussion of value propositions might also be helpful.

 

Stavros, regarding your excellent comment, some comments…

“I usually also emphasize the framework and the clear (?) definition of the architectural roles one has to realize and their flexibility, e.g. multiple practitioners coming from different users, multiple symptom emitters, multiple catalogue sources (to combine domain specific knowledge?) etc.

[[Paul]] Architectural roles in themselves are not a value-proposition, I think, but rather an artifact of good design, but +1 on the architectural roles enabling diverse domains to work together supported by automation based on a common framework.

 

Further, it is the possibility of sharing this knowledge in standard means, that also attaches value to SAF.

[[Paul} agree

 

Finally, we could mention the possibility for runtime adaptations to the catalogue, the ability to have the system evolve in response to the environmental changes, e.g. add a new syndrome after data mining over historical records and identify a new, previously unknown pattern (as Dave has mentioned in the past). This might be implied in Paul's "iteration" but not sure.”

[[Paul]] It is a natural consequence of my point regarding “Iteration,” but may be considered a higher-level business/technical value derived from Iteration, I think.

 

 

 

[[Paul]]

This leaves us with the below, I think:

 

Higher-level Value Propositions in no Particular Order (with the supporting lower-level values (if that is what they are) that I identified earlier:

·         Standardized knowledge sharing and best practices (actions) across domains (also Symptoms/events, etc., but that may be of less value)

o    Translation, Cross-domain, Standardized expertise/knowledge

o    In the cloud: domains can take meaningful action based on the Symptoms and situations of other domains that they know little/nothing about, but have a business dependency/relationship with

·         Real-time or near real-time evolving knowledge and action repertoire enabled by data mining and “pattern” recognition (including identifying new situations)

o    Standardized expertise/knowledge, cross-domain, translation  

o    In the cloud: Cloud entities and enterprises using the cloud can react to changing situations (business, security, operational, service, app) across domains and respond appropriately without internal visibility into the internal properties/characteristics of the other domains. I may not be saying this well.

 

Does this make sense? Am I skipping a value proposition?

 

 

 

Thanks,

Paul

 

Paul Lipton

VP, Industry Standards and Open Source

Member, CA Council for Technical Excellence

Phone (preferred number!): +1 215 539-2731

Mobile: +1 267 987-6887

Email: paul.lipton@ca.com

THIS MESSAGE MAY CONTAIN CONFIDENTIAL, PRIVILEGED OR OTHER LEGALLY PROTECTED INFORMATION. IT IS INTENDED FOR THE ADDRESSEE ONLY. IF YOU ARE NOT THE ADDRESSEE (OR SOMEONE THE ADDRESSEE AUTHORIZED TO RECEIVE THIS MESSAGE), YOU ARE PROHIBITED FROM COPYING, DISTRIBUTING OR OTHERWISE USING IT. PLEASE NOTIFY THE SENDER AND RETURN IT AT OUR COST. THANK YOU.

 

 

From: Stavros.Isaiadis@uk.fujitsu.com [mailto:Stavros.Isaiadis@uk.fujitsu.com]
Sent: Tuesday, January 26, 2010 8:33 AM
To: saf@lists.oasis-open.org
Subject: RE: [saf] Cloud Profile Value Proposition

 

Hi Paul,

 

Good idea to try and grind out the value of SAF in concrete terms. My two cents along the lines

Hi all,

 

Not really liking my previous missive regarding the Cloud Profile too much (it goes too deep too quickly), please allow me to “pop the stack” with a higher-level perspective, if I may. Forgive oversimplifications and generalizations, but I am just trying to open up a brainstorming dialog.

 

One might also note that since without SAF it is hard to do some things it might be hard to find cloud use cases evolved and sophisticated enough in the real world to be useful at this time in the industry. Just a thought.  

 I guess without SAF it would be a combination of rules based systems and a complex event processing system. One would also have to glue everything together with some cross-domain integration "middleware" or similar... Nasty stuff...

 

 

Existing and emerging management and security standards will do things like the below (basically everything done for SOA, but more RESTful and with a cloud provider and virtualization slant):

* Complain about misbehaving manageable resources (cloud entities, perhaps, like virtual networks and CPUs) and provide metrics

* Provide protocols and schema to manage your cloud resources (ask for a template, establish a contract, provision a VM, whatever). In short, a sort of standardized equivalent to EC2 APIs and protocols, if you sould.

* Identity, autht, authz in the cloud (and federation stuff)

* Privacy and location stuff (ie: “don’t host my data outside the country, etc.”)

* And so on…

 

So we shouldn’t do that stuff.

 

What is unique about SAF (some assertions)

* It’s not the Symptoms, it’s the catalog. What is cool about the catalog?

A. TRANSLATION: You can “translate” a meaningful pattern (Syndrome) to a meaningful action (Prescription).

B. CROSS-DOMAIN: This translation can be from one domain to another domain or at a higher-level within the same domain. These domains can be IT/cloud domains and/or business/application/service domains.

C. ITERATION: You can keep doing translations adding value over and over again

D. EXPERTISE/KNOWLEDGE: The catalog can encapsulate the expertise of human experts, which is often most valuable when it is doing (guess) translation, is cross-domain, and is iterative.

I usually also emphasize the framework and the clear (?) definition of the architectural roles one has to realize and their flexibility, e.g. multiple practitioners coming from different users, multiple symptom emitters, multiple catalogue sources (to combine domain specific knowledge?) etc.

 

Further, it is the possibility of sharing this knowledge in standard means, that also attaches value to SAF.

 

Finally, we could mention the possibility for runtime adaptations to the catalogue, the ability to have the system evolve in response to the environmental changes, e.g. add a new syndrome after data mining over historical records and identify a new, previously unknown pattern (as Dave has mentioned in the past). This might be implied in Paul's "iteration" but not sure.

 

Cheers,

 

Stavros

______________________________________________________________________

Fujitsu Laboratories of Europe Limited
Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
Registered No. 4153469

This e-mail and any attachments are for the sole use of addressee(s) and
may contain information which is privileged and confidential. Unauthorised
use or copying for disclosure is strictly prohibited. The fact that this
e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does
not guarantee that it has not been intercepted or amended nor that it is
virus-free.