Interoperate or Evaporate
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.
Pages: 1, 2