[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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] 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]