[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] We could change from a medical
analogy to a food analogy. Symptom à
Ingredient Protocol à
Recipe Prescription à
Dish Catalog à
Cookbook J From: Lipton, Paul C 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] 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] 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] Here are the results of my
brainstorm (in table below), so far. Will hopefully have more on the call
today. From: Vaught, Jeffrey A 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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]