RE: [saf] Cloud Profile Value Proposition

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

Hi Yasu,

Thank you for your thought-provoking comments, which I've excerpted with some of my statements below, for convenience along with responses:

FROM BELOW (Yasu's comments are numbered (1) and (2): 
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. 
 
(1) Why is CROSS-DOMAIN related to the catalog?
[[Paul]] I suppose you are thinking of the "Framework" as part of this, too. I don't deny that a framework capable of utilizing the catalog would be needed, but the catalog relates a Syndrome, which may be of one domain of business/knowledge (not Internet domain) (let's call it A) to a Prescription, which may be of an entirely different business/knowledge (say B). The point is that the connection between A and B is codified in the catalog, not the framework and certainly not the emitted Symptoms themselves, which are oblivious to the whole relationship. 


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


(2) Why is ITERATION related to the catalog?
[[Paul]] Here, the framework actually plays a centerpiece role along with catalog. Without framework what would do the iterating? Without catalog, what would framework iterate on? To me, the purpose of iteration is to do translations over and over, possibly across domains, until a problem is resolved or a system is optimized, or other broad uber-policy goals have been reached. Yes, I think SAF might have some sort of uber/meta policy aspects to it, but I'm not sure it is most appropriate to refer to SAF that way. 

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
-----Original Message-----
From: Yasuhide Matsumoto [mailto:ymatsumo@jp.fujitsu.com] 
Sent: Thursday, January 21, 2010 8:45 AM
To: saf@lists.oasis-open.org
Subject: Re: [saf] Cloud Profile Value Proposition

I can't attend today's call due to the business training course.

Instead, I do comment (1) to (2)

Regards

Yasu

----- Original Message ----- 
From: "Lipton, Paul C" <Paul.Lipton@ca.com>
To: <saf@lists.oasis-open.org>
Sent: Wednesday, January 20, 2010 1:53 PM
Subject: [saf] Cloud Profile Value Proposition


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. 

 

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. 


(1) Why is CROSS-DOMAIN related to the catalog?

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


(2) Why is ITERATION related to the catalog?

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. 

 

What can we do with SAF (some examples that can't be done by any *one*
of the existing/emerging cloud standards, I think:

* Integrate multiple IT domains 

A. A security breach precipitates the deprovisioning of all cloud
instances that use a vulnerable template 

 

* Integrate from application/business/level domain to IT/cloud domain
(kind of what I was striving for last Thursday). This is the catalog
expressed as business/IT expertise. 

A. A business event from a SaaS company customer is translated to
meaningful actions making meaningful changes or requests to the SaaS
company's cloud providers. For example, a 25% increase in a customer's
sales may mean an anticipated 25 more instances provisioned by cloud
provider A. 

 

* Integrate entirely at the application/business/service level

A. This is like our energy use cases, for example. An increase in energy
prices for one datacenter beyond a certain point might mean that other
datacenters, normally less preferred, are now the first choice for
provisioning. Ooops, this sounds like a cloud provider example. I guess
that's because it is a *business/application* issue for the cloud
provider. 

 

Again, I'm just throwing this out in an effort to open a brainstorming
thread around value propositions of various scenarios. 

 

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 <mailto: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.

 

 




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php