Leonard & Catharine wrote:
>
> An earlier exchange questioned whether or not Standards Bodies should model
> business process. Clearly, driving business standards from a generalized
> business model with "common business objects" is 'the way to go.'
Why is it the "way to go"? This is far from a self-evident fact.
Do you feel like adding some reasoning to substantiate your assertion?
If one looks at the actual operation of an organisation, the "business
model" is highly dependent on the skills, background and experience of
the senior management. As a result, the way the business processes actually
operate is different (and needs to be) in each organisation. The concept
of "Common business objects" doesn't appear to make much practical sense.
So adopting a "common business object" may NOT be the way to go. The
detailed way in which a business operates is one way of building a
competitive edge. Anyone trying to implement a "common business object"
gives up that opportunity to build a competitive edge.
> But is it
> a viable role for SDO's to take charge of the business process model effort
> or approval?
>
> This question is at the heart of the role of SDO's in 'tomorrow's world' and
> their relevance to the business community. The answer is an unequivical -
> partly.
Why is it an "unequivical (sic) partly"?
Why only "partly"?
The role of SDOs in any field effecting the implementation of the business-
oriented use of computers has been a disaster in most cases. Here's
a few notable examples:
OSI (25 years of standards work, barely any parts implemented
and fizzles when Internet arrives).
EDI "standards". Implemented as custom designed interfaces because
the precise data structures for interchange can't be standardised
across all industries, processes and size of organization. Adopted
by very few organisations in the world (relatively). (Incidently,
that is also what ebXML is trying to do. Wouldn't one think that
people starting such ventures would take note and consider the
unworkability of that concept in the past?)
Open-edi. Years of work by ISO and many member organisations.
Unlikely to amount to anything or be implemented.
BSR (Basic Semantic Repository).
Part of the reason (at least) for this consistent failure by SDOs is
that there is no requirement for the people participating in the
standards process to be true experts in the area being standardised.
They only have to be nominated by a member organisation to the
national "standards" committee and by the national body to the
international "standards" committee. The result is political with
workability and adoptability not a consideration.
As long as mountains of paper work and final agreement are produced, the
"standards" committee is judged a success. Whether the result actually
works or whether an end-user business can actually benefit from using
it appears to be irrelevant.
> 1. Relevant SDO's (those that achieve funding from the business community)
> are involved in creating relevant standards. These can be industry or
> supply chain specific. The winner in the SDO process will be organization,
> sanctioned or not, that gathers the right group of partners to achieve
> consensus with.
Once again, why? I have demonstrated several reasons why this may
not be so.
Most businesses ignore the standards in the area of implementing business
processes using computer. They design and implement their
own proprietary methods. These appear to be much more widespread in
their adoption and more successful than anyone implementing formal
EDI "standards".
> 2. Standards can come in two forms- vertical and horizontal. As the
> efforts of organizations in the XML world have been explained to me, they do
> two things: either vertical standards (such as Rosettanet) with a specific
> supply chain or industry OR they do horizontal standards (such as ebXML)
> that seek to band together the vrtical standards against a common business
> model or process.
Rosettanet is highly proprietary. ebXML is just adding another
level of complication (XML syntax) on top of trad-edi. The first is not a
standard in SDO terms, the second will have all the unworkability
of trad-edi (X12, EDIFACT etc) since it is based on exactly the
same principles and philosophies. ebXML is not there yet. What it
is based on is just dreams. The practicalities have yet to surface
and be solved.
> Thus, the process allows for a natural tension between
> vertical (highloy specific needs) and cross function or industry needs.
It does? Please explain. If your previous statement proves to be invalid,
this could also be invalid.
> It
> should become a negotiation resulting in the most optimal creation of
> standards. This is a good thing.
Why is it a good thing? That conclusion does not appear to have any
preceding argument to support it. Common business practice would
indicate otherwise.
> 3. I see the future role of an X12, for example, in providing a central
> focus for "registering" the vertical standards, certifying their ability to
> interlock with horizontal standards that allow the supply chain or
> interlocking processes to 'participate' or both (e.g.- registering a cross
> function or industry standard that allows these to interoperate.
I suspect X12 will do that, too. But how useful will it be? There is no
point in any of the traditional EDI SDOs continuing to exist at all now
there are so many any-to-any translators available. The "standards"
produced by the two most dominant of these organisations go through
two destandardising processes before being implemented as proprietary
customised solutions:
1. MIG (Message Implementation Guidelines). These are industry
specific implementations or variations of the "standard".
2. Each pair of trading partners agree up front an interchange
structure and codes they will implement. Then they set up their
translators and re-engineer their application programs to work
to that agreement.
This latter point particularly obviates EDIFACT, X12 and all other
SDOs supposedly producing EDI "standards".
If each pair of trading partners must agree what they are going to
interchange, why not just send application level files and set up
the translators to convert at one end (instead of both ends). This
eliminates the unproductive step of translating to the non-businesslike
languages of trad-edi and then attempting to "untranslate" back to
business language at the other end. The result is much simpler,
and possibly even more workable. Most organisations operate using
propritary interfaces and "adapters" today - without any use of
trad-edi "standards" or thinking.
This way of working using any-to-any translators or even home-grown
file converters and adapters does not rely on or even use any of the
output or "experience" from X12, EDIFACT or any other EDI "standards" organisation.
There are little more than 100,000
organisations world
wide that have adopted EDI "standards" and many have dropped them as
unproductive or unworkable and used some other form of customised
interface.
In the light of the above, do you still think SDOs should play a
major role in the way you propose?
> 4. Who should do the model work behind either the vertical or horizontal
> standards? It is clear that the business community (in various groups) must
> do this. They can either opt to participate through the central focus an
> SDO brings or register their work with an SDO to gain 'global acceptance.'
Why register what? Who's going to use this work and suffer the consequences
other than the registrants?
Why should this be any more widely adopted than the current output of
SDOs in this area?
> In the short run vertical standards may have much appeal (quicker and easier
> to develop around a 'pressing need.') but we (the business community) will
> ultimately require the interlock ability implied by the horizontal standards
> efforts. Either way, a new level of corporate participation in business
> process model work is mandated and this in turn mandates more reource.
Why is process model work mandated. Does it even make sense? The only
people who resort to modelling in my experience are those incapable
of implementing. How many models have you seen that are even close
to being sufficiently detailed and correct to be used in practice?
Certainly, to the casual observer, formal modelling can look like
feverish activity. But how useful is the end result? Most of it ends up
in dusty archives or waste paper baskets.
> In a
> way, who cares how we get, the point is that the community at large
> benefits.
That is the point. How will your proposals get "the community at large"
to that point of benefiting?
> If an SDO is smart- it will want to embed itself into
> facilitating this process in a manner that encourages horizontal needs
> whilst recognizing the immediate vertical needs.
Is that sensible? Aren't you recommending that SDOs produce "standards"
that aren't standard? Isn't that what they are doing anyway in this area?
To my view, you need to do a lot more substantiation and explanation
of your case to turn the above collection of ideas into something that
is worthy of consideration.
If you have sufficient experience in this area, why not identify
the inhibiting problem areas and demonstrate (reason) how your proposals
will overcome them.
--
Ken Steel
ICARIS Services
Brussels and Melbourne
Research results: http://www.cs.mu.oz.au/research/icaris
[EMAIL PROTECTED]
[EMAIL PROTECTED]
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
