The intent was a brainstorming exercise
to generate ideas about what symptoms could be generated.
The next step would be to see
what maps to the cloud. Perhaps not much.
Regarding invoicing/billing…
This could be an area where someone (DMTF) standardizes the interaction for
invoicing in the cloud and that could become part of our profile. At
present DMTF incubator has just defined contract interactions, and not
specifically to invoicing/billing.
Your “outstanding invoices
exceed credit limits” is a better example though.
Regarding the other comments
(symptoms is a standard for REPORTING)… I think this is way off the mark.
SAF is two things:
-
A standard way to
collaboratively capture decision/action information
-
A standard way to
share that information with similar domains
We are focusing on the cloud
domain.
The purpose of this exercise is
to understand what symptoms/prescriptions are typical in business setting,
scope it to cloud, and then hopefully identify any additional attributes that
would be needed to support these types of symptoms (and subsequent syndromes).
-jeff
From: Black, Alvin
Sent: Thursday, April 29, 2010 11:15 AM
To: Vaught, Jeffrey A;
Subject: RE: [saf] RE: SAF meeting today - symptoms/prescription
This exercise highlights one of
the key challenges we face with defining the problem domain of SAF. I
don’t THINK that any of us envision SAF as being just a generic
information exchange standard. Perhaps adoption and interest in the standard
will not develop until we become MORE restrictive about what SAF is, rather
than trying to make it more all-inclusive.
We’ve deliberately steered
away from any such restriction in the past, but perhaps we need to limit SAF to
the domain of “alerting about problems that may exist.” We
can still be generous in our definition of “problem” – an
under-optimized system, for example, could be considered a
“problem.” Perhaps SAF is really just a standard for generic
business process exception handling.
To take just the first row in
the below table as an example:
Invoices: Do we really
want to say that SAF can handle “primary” data packet transfers for
well defined business processes such as invoicing? My concern here is
that there are probably already established information exchange packets for
sharing invoices. I don’t think that we could possibly make any
inroads in to the exchange of invoices, and in fact, attempting to do so may
actually weak the argument for SAF (we won’t be taken seriously).
So, in my mind, sending an
invoice via SAF is clearly outside of the scope. However, raising
concerns about an invoice may not be outside of the scope of symptoms.
For example, the following may be a better example of something that would be within
the domain of SAF (at least in my opinion):
“Outstanding invoices
exceed credit limits of customer.”
So, sending an invoice within
SAF would not be a good fit (this is a normal business flow).
Sending a notification that an
invoice had been paid would not be a good fit (this is a normal business flow)
However, getting a symptom about
a chargeback on a credit card (for example) and using that to trigger a
prescription (turn off customer account) MAY be in the SAF domain (even this
could arguably be a normal business flow though).
So the basic mindset is –
if a system encounters a PROBLEM (or an indication of a potential problem)
which it CAN NOT HANDLE within its domain, symptoms becomes the standard for
REPORTING that problem to SOME OTHER ENTITY. Now the danger with this
approach is that someone might think it is “just another event
format.” Symptoms should perhaps be defined as the “subset of
events that require mediating actions by an outside source.” Hence,
an audit event (“User XYZ successfully logged in”) is NOT a
symptom, even though it is an event.
Thoughts on this anyone?
My fear is that we are becoming a giant vacuum cleaner for generic information
flow scenarios – and I don’t think we will succeed if that is what
we become.
- Alvin
From: Vaught, Jeffrey A
[mailto:]
Sent: Thursday, April 29, 2010 9:56 AM
To:
Subject: [saf] RE: SAF meeting today - symptoms/prescription
Here are the results of my
brainstorm (in table below), so far.
Will hopefully have more on the
call today.
From: Vaught, Jeffrey A
Sent: Thursday, April 29, 2010 9:26 AM
To:
Subject: SAF meeting today - proposed Agenda
Proposed Agenda:
-
Outreach review
-
Cloud Profile – potential prescriptions & symptoms
across different business functions
Most of the meeting will focus on the latter (Cloud
Profile).
Please be prepared to discuss candidate symptoms (and
prescriptions) emitted from different business functions. Pick your
favorite business function and “have at it”!
Below is a list of business functions (stolen from a
McDonald’s website). I’ve organized into two columns –
Cloud Consumer & Cloud Provider.
Function
Consumer symptoms/prescriptions
Provider symptoms/prescriptions
Accounting-Payables
Symptom: Invoice for XXXX
service
Elements needed in Symptoms
are:
-
Service identifier
-
Service
description
-
Duration of
service being billed
-
Amount
-
Unit (dollars,
etc)
-
Due date
Accounting-Receivables
Symptom: Paid Invoice for XXXX
service
Elements needed in Symptoms
are:
-
Same as Invoice above
-
Amount Paid
Accounting-Pricing/Estimating
Symptom: Estimate of XXXX
service
Elements needed:
-
Same as Invoice
Accounting-Costing
Internal Symptom: Cost of XXXX
service
Elements needed:
-
List of items in
the service
-
Materials cost per
item
-
Labor cost per
item
-
Overhead cost per
item
Communications-Corporate
Symptom: Our support staff
will be ‘on leave’ for the Holidays, Dec 24 & 25.
Elements:
-
Message
-
Category (hours-of-operation,
safety, new-service-announcement, etc)
-
Date of
applicability
Communications-Customer
Symptom: Release 11 of service
XYZ is now available.
Elements:
-
Message
-
Category
(hours-of-operation, safety, new-service-announcement, etc)
-
Date of applicability
Communications-Partner
Corporate Tax
Customer Satisfaction
Symptom: Interfaces are
difficult to use in Service XYZ release 11
Elements:
-
Service identifier
-
Service
description
-
Message
-
Satisfaction (excellent,
good, fair, poor)
I’m thinking of this
as different from SLAs. Almost like a quality survey card.
Product Engineering/Development
Environmental Affairs
Internal symptom: Disposing of
Server Rack 123
Elements:
-
Hardware identifier
-
Hazardous
chemicals reference
Energy
symptom: Service XYZ consuming
100 KW/H of energy
-
Service identifier
-
Consumption rate
-
Consumption total
-
Energy blend
Facilities
Government Relations
Human Resources
Information Services (might be the same as Engineering for
Cloud Provider?)
Insurance
Legal
Marketing
Purchasing
Quality Assurance
Operations/Infrastructure
