[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] UBL vs UN/CEFACT
|
Stephen, You pose some significant questions. At
the risk of pointing out matters that everybody already knows and experiences,
below are three observations: 1. "eBusiness" standards are
servants to internal business system conventions having to do with enterprise-level
process, data and exiguous rules (e.g., imposed by taxing authorities), with
many of these enterprise-level conventions being partially or entirely
idiosyncratic. A long-term "cure" is to have
eBusiness standards (object definitions, transaction definitions, code lists,
etc.) imported into internal systems to become "native" rather than
translation paste-ons. However, this cure is an evolutionary movement that
barely merits the term nascent. Meanwhile, two impacts of idiosyncratic internal
systems conventions on the shaping and utilization of eBusiness standards are:
a) the encouragement of fresh start standards as opposed to revising existing
standards, and b) a shortage of standards design resources, because no single
standards group can bring to bear enough "mindshare" to analyze and accommodate
the plethora of idiosyncratic needs. . 2. A given eBusiness standard is shaped by
(and trapped in) the technology extant at the time the standard's "version
1" was created – e.g., EDI was born when terseness was essential
because of then-existing constraints on and prices for computing resources,
disk storage and bandwidth. Although most constraints on computing and
network resources have been greatly relaxed through technological progress, one
technological constraint which has persisted is the lack of
"intelligence" in computers, and this technological shortfall has the
consequence that eBusiness standards still need to be inordinately detailed and
precise. For example, what to people are easily understood and actionable
transactions (e.g., faxed orders or invoices) often defy automated
interoperability. XML (as "markup") was an
enormous advance over the positional sort of approach used in EDI (and in comma
delimited data, still a very heavy competitor to eBusiness "standards),
but as we know the process of bundling payload data into XML transactions and,
on arrival, tearing down XML transactions for import into internal systems still
goes awry because automated processes are too stupid to overcome minor
differences and ambiguities that do not confuse human beings. Unfortunately,
comparatively "intelligent" data does not substitute for intelligent
computing. On the other hand, we probably have not
fully exploited the advances of "brute force" computing capabilities,
which unlike computer "intelligence" has progressed at the predicted high
rate. As an example of what may be a missed opportunity, today "master
data maintenance" is feasible across hundreds or thousands of computers, facilitated
by brute force computing and storage, but nevertheless eBusiness transaction
standards are designed on the basis that each transaction must carry within it all
of the "master data" needed to make the transaction informationally
autonomous. Often our discussions of the need to add something to a transaction
has little to do with the dynamic attributes of the transaction (e.g., number
of units shipped), but is intended to accommodate some static master data. There are not a lot of higher level "master
data" standards extant although certainly many code list standards constitute
master data standards at the tuple level (country code to country name, etc.)..
Oasis cis (a not quite finalized standard for relating parties to one another,
to locations, to organizations, etc.) is an example of a high level "master"
data standard as opposed to a transaction data standard, and if trading parties
held and shared such data (preferably through replication rather than
transactions) the complexity of transactions could be reduced. 3. Various industries or specific large enterprises
(or governmental entities) serving as self-appointed "hubs" (as in
hub and spoke) tend to set standards priorities – e.g., the EDI world was
shaped and prioritized by automobile and other very large manufacturers and
associated transport providers, while the cXML/xCBL world was prioritized by
"virtual" eBusiness entities primarily engaged in non-production
buying and selling )office supplies, maintenance parts, packaged chemicals,
etc.). Manufacturers were (and are) enormously
interested in complex supply chain operations of production goods (e.g., needing
shipping advices which have enough detail to convey data on the contents of
rail cars containing many different packages and parts and identifying arrival
schedule), so EDI and XML-based variants of EDI minister to those needs. On the
other hand, those in the cXML/xCBL world had (and today often still have) as a
top priority the user experience in the order entry/catalog process, with downstream
functions such as shipping being highly simplistic – a carton handed off
to Federal Express or UPS. The insurance industry and the medical insurance
industry have used eBusiness primarily as internal industry infrastructure: for
example, to streamline business processes between insurance providers and
insurance agents. Although these diverse needs can be melded, it takes a lot of
work and creativity to do so without merely layering complexity on top of
complexity. The bottom line is that eBusiness is
harder than it should be because of the negative synergies among these three forces
(and others). These interacting forces perhaps can be aligned to create
positive rather than negative synergies, but on the other hand as mentioned in
point 1 there just are not enough people and time to do the necessary analysis
and synchronization. Colts
neck Solutions LLC From: Stephen Green [mailto: Should we then regard
UN/CEFACT messages as a kind of successor to EDIFACT? |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]