OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [saf] RE: SAF meeting today - symptoms/prescription


Must be a Friday. J

 

From: Vaught, Jeffrey A [mailto:Jeffrey.Vaught@ca.com]
Sent: Friday, April 30, 2010 12:57 PM
To: saf@lists.oasis-open.org
Subject: RE: [saf] RE: SAF meeting today - symptoms/prescription

 

We could change from a medical analogy to a food analogy.

Symptom Ingredient

Protocol Recipe

Prescription Dish

Catalog Cookbook

 

J

 

 

From: Lipton, Paul C
Sent: Friday, April 30, 2010 12:41 PM
To: Black, Alvin; Vaught, Jeffrey A; saf@lists.oasis-open.org
Subject: RE: [saf] RE: SAF meeting today - symptoms/prescription

 

Just to clarify what I said below for the group, I agree with collaborative rule/knowledge/best practices sharing as the basic concept, but perhaps with a focus on the “exceptional,” rather than the mundane; a good recipe for life! :-) In other words, SAF could probably be used to carry everything in the world, but many standards probably exist to cover things like invoices or stock quotes and probably already have good ways to share that sort of information. We should focus on the “exceptional condition” (which could be an optimal one or a problematic one) and the best practices/rules/knowledge to deal with it. Does that make sense?

 

Thus, the direction we are taking is thus good, IMHO, but kill some of the more extreme medical terms like “Protocol,” which are confusing. I had no idea that doctors used that word before SAF and nobody else in IT will either. They’ll think we are talking about communications.

 

 

Thanks,

Paul

 

Paul Lipton

VP, Industry Standards and Open Source

Member, CA Council for Technical Excellence

Phone (preferred number!): +1 215 867-9231

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: Lipton, Paul C [mailto:Paul.Lipton@ca.com]
Sent: Friday, April 30, 2010 11:00 AM
To: Black, Alvin; Vaught, Jeffrey A; saf@lists.oasis-open.org
Subject: RE: [saf] RE: SAF meeting today - symptoms/prescription

 

Hi all,

 

Mostly +1 on what Alvin says below. I think the key term, as has been said, is “condition.” Perhaps we should expand that to be “exceptional condition?” That doesn’t mean we are limited to just problems. For example, an exceptional condition might be “The Sky (a.k.a. Cloud) is Falling.” But, it might also be an optimum condition or something else such as “for the first time this year, a sales person has reached our impossible sales quotas.” Of course, the proper business-heartless-cyborg response would be “we’d better raise our sales quotas so that we don’t have to give these poor guys any bonuses. :-)

 

Thanks,

Paul

 

Paul Lipton

VP, Industry Standards and Open Source

Member, CA Council for Technical Excellence

Phone (preferred number!): +1 215 867-9231

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: Black, Alvin [mailto:Alvin.Black@ca.com]
Sent: Thursday, April 29, 2010 11:15 AM
To: Vaught, Jeffrey A; saf@lists.oasis-open.org
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:Jeffrey.Vaught@ca.com]
Sent: Thursday, April 29, 2010 9:56 AM
To: saf@lists.oasis-open.org
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: saf@lists.oasis-open.org
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

 

 

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]