Interoperate or Evaporate
by Alan Kotok
December 12, 2001
The Interoperability Summit, held 6-7 December 2001 in Orlando,
Florida, was billed as the first of a series of meetings to find
common ground among XML and e-business standards groups. The group of
80 participants heard, and in no uncertain terms, that customers are
quickly running out of patience and resources to support multiple
standards organizations. The participants succeeded in bringing out
many of the factors that generate and perpetuate the multiple and
overlapping specifications, and agreed on the first steps to start
bridging the gaps. But it also exposed fault lines that show the task
will not be easy.
The meeting was sponsored by five organizations: OASIS, The UN's trade
facilitation agency, UN/CEFACT, Object Management Group, HR-XML, and Extensible Business
Reporting Language (XBRL). HR-XML
is a consortium writing XML messages for the human resources
community; XBRL develops messages for financial reporting. Chuck
Allen, the director of HR-XML, chaired the meeting and said the goal
was to facilitate information sharing and collaboration among
standards groups which are interested in agreeing upon common models
and approaches to support interoperability. Allen added that the
meeting should do more than just pass information among the
participants; it should make the first steps to establish mechanisms
to make standards interoperate.
From the outset the participants seemed ready for solutions to the
problem of overlapping XML vocabularies and frameworks. The group
consisted of representatives of industry organizations, solution
providers, end-user companies, and government agencies from the U.S.,
Europe, and Asia. Most of whom spoke of the confusion and frustration
in the marketplace caused by the proliferation of specifications
developed for individual industries and business functions. Yet many
of the participants also wore multiple hats, taking part in the very
groups that generate the welter of specifications.
The Standards Customer is Always Right
While all participants agreed with the need for collaboration, the
discussions evinced different viewpoints about how that collaboration
should happen. One of the fault lines divided the standards customers
-- i.e., those companies and organizations providing the bodies and
brains to develop the standards -- the standards groups
themselves.
Bob Sutor from IBM's software division, who makes decisions on
where IBM puts resources into standards development, unveiled
demanding new criteria for standards groups. Sutor said much of IBM's
interoperability strategy now revolves around web services, and IBM
will now measure its participation in standard efforts on the degree
to which those initiatives support its web services strategy.
Sutor called web services a disruptive technology; it will change
the way companies work with each other and the way IBM works with
standards groups. He expected to see implementations of web services
well before they receive a final stamp of approval from standards
groups.
He described three phases of web services development: (1)
development of the basic technologies, such as SOAP (messaging), UDDI
(directories), and WSDL (service descriptions); which leads to (2) the
current phase: security and reliability, adding routing capability,
reliable message operations, and security functions. Finally, (3)
enterprise features like workflow, transaction processing, systems
management, and service negotiations will be added.
To achieve this vision will require an unprecedented degree of
cooperation and coordination among standards groups, and it will also
require many groups to change some of their long-standing operations.
IBM's experience with developing the early web services specifications
showed that it could shortcut the usually lengthy standards processes
without sacrificing technical quality. Sutor said he still expected
to involve the traditional standards groups in the development
process, but IBM would not be tied to the extended timetables that
many groups have used in the past.
Sutor said IBM still expected high quality results -- "weeding out
the junk -- but he also expected standards groups to work with open
source communities, as well as coordinate their activities to get
architectural consistency. He also expected the work of standards
groups to get reality checks by having as many of the technical
decisions as possible made by industry representatives.
He included the Electronic Business XML (ebXML) initiative, in
which he served as vice-chair, in these new and demanding
requirements. He said the ebXML architecture needs to begin
converging with the web services stack. Duane Nickull of XML Global,
and chair of the UN/CEFACT work group responsible for continuing
development of the ebXML architecture, said his team had begun
building on the original design and is producing a white paper
describing how an electronic business architecture can be implemented
as a series of web services.
Share your opinion on interoperability and standards groups in our forum. |
| Post your comments
|
Earlier in the meeting, Jackson He of Intel Corp. and a
representative of the Business Internet Consortium (BIC), discussed
BIC's initiative to bring some order to the increasingly chaotic
business-to-business standards environment. BIC is a group of some 40
large end-user companies, such as Ford Motor Company and Pennzoil, as
well as industry groups like RosettaNet. He said the current state of
affairs was impeding adoption of e-business technologies, particularly
by small and medium-sized companies, which required more leadership
from a customer-driven rather than vendor-driven organizations. BIC
produced a high-level overall architecture as a way of putting
together the different standards activities into an overall conceptual
framework.
Several participants pointed out that BIC seemed to borrow many of
its ideas from the work of other initiatives. Sandy Paul, who worked
with publishing industry and EDI standards groups, noted that the BIC
framework presented by He strongly resembled the ISO Open-EDI model
used by the ebXML initiative. Other participants noted that BIC's
conclusions were similar to those of ebXML, suggesting that BIC should
work with existing groups rather than starting a new organization.
Jackson He said BIC wanted to make its conclusions available to
standards bodies but did not want to wait for standards bodies to make
more standards. The goal of BIC was to encourage more convergence
among e-business standards and, where convergence was not possible, at
least to achieve interoperability among them.
[1] [2] Next