Jeff,
Thank you for trying to capture what was indeed struggling on my
part. I should have responded when my own thoughts were more current, but for
what it is worth please see below. Generally, I think you have captured it. I
merely elaborate more (and probably confuse more, I’m afraid).
I do think we have to examine the value proposition from a
higher-level, possibly cloud application if we don’t want to do business
domain.
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: Vaught, Jeffrey A
[mailto:Jeffrey.Vaught@ca.com]
Sent: Thursday, January 14, 2010 1:14 PM
To: saf@lists.oasis-open.org
Subject: [saf] SAF - value proposition for cloud
Near the end of today’s meeting, Paul was struggling
with the SAF Cloud Profile value proposition.
The gist of what he was saying (and hopefully he will
respond with a clarification if needed):
-
The SAF catalog, in the Cloud context, will contain
application specific information, not cloud generalizations.
[[Paul]] Well, it depends on whose catalog we are talking
about. SIS’s catalog (SaaS provider) should contain application/domain/customer
specific information. To me, the power of SAF is that a customer’s
situation (ie: my sales will increase 25%) can be translated to SIS’s
terms (ie: they will utilize our premium service instead of our regular service
and at twice the rate (not 25% because perhaps we’ve learned that they
call us multiple times per sale)).
However, SiS may also have Cloud specific information as it
applies to their own business (ie: when a Cloud provider runs slow more than 3
times a week, this is a prescription to change cloud providers). In many of
these cases Symptoms does come off as a deeper, more effective all-purpose type
of policy, sort of. I don’t know what you all think of that.
I’m also not sure what cloud generalizations really
are. You’d have to define that for me, I think. Is it something like “the
VM that you asked for is running slow or more like you asked for a VM, but I
can’t give it to you?”
YOU ALSO SAID:
For example, the cloud consumer may ask the provider:
“I need more widgets”. And the provider may respond by
provisioning more widgets. Thus, SAF catalogs (syndromes, protocols) will
be filled with information about widgets, semantics such as “more”
or “less”, and so forth.
[[Paul]] Yeah, I guess so. I guess the point is that the
semantics would be in SIS terms (cloud consumer terms) and in cloud provider
terms. SAF would bridge the gap allowing the SaaS provider to connect customer
issues/needs to its own needs/issues with its cloud providers.
Does this make sense? Is this a point-of-view worth
investigating?
Paul – Is this an accurate portrayal??