Interoperate or Evaporate

December 12, 2001

Alan Kotok

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.

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.

Object Modelers vs. the Angle-Brackets

Another apparent division emerged between Unified Modeling Language (UML) and XML practitioners. Early in the meeting, Richard Soley, chairman and CEO of OMG, discussed the group's Model Driven Architecture based largely on UML. Many standards groups have begun using UML as a tool to define business requirements and processes, independently of potential technical solutions. Soley said the the Model Driven Architecture's goals are not only interoperability but also software portability, the ability to reuse software assets across different platforms.

The portability issue is an important one to software developers but not a critical need of e-business standards, which focuses more on exchanging data in business documents, and one of the participants questioned Soley on whether the issue of portability fit the main (interoperability) topic of the meeting. Solely noted that protocols may exchange the documents but APIs need to manipulate documents. The portability issue affects APIs. He also made a distinction between data models, often the stuff of e-business standards groups, and object models. Data models, while perhaps sufficient for interoperability, do not address software portability.

UML advocates got an even sharper shock when one of the key developers of HR-XML spoke at length about the inability of UML to meet the needs of a large-scale human resources systems project undertaken by the U.S. Department of Defense. Enrique Kortright, of the U.S. Navy Space and Warfare Command's Information Technology Center, discussed how the initial modeling of the planned Defense Integrated Human Resources System (DIMHRS) ran into problems using UML. This project is a large, complex undertaking, eventually serving 3 to 4 million employees, with thousands of entry points and concurrent users, and exchanging data with finance, education, health care, retirement, and civilian personnel systems.

Kortright said the goal of modeling this system was to capture the business knowledge of human resource professionals, and like Bob Sutor of IBM, he had to evaluate the available standards against the needs of that project. However, he found UML limited in its ability to record complex business behavior. Based on this experience, he said UML was both too complex and too restrictive and forced the modelers to make decisions irrelevant to the overall goals of the project, such as classifying professional human resources knowledge between classes and attributes. Kortright also discovered that human resources experts could not understand the UML notation. The DIMHRS designers ended up using another graphical modeling language called Object Role Modeling, which like UML uses a graphical notation but is more expressive.

The DIMHRS experience provided a reference model on which HR-XML was based. While the model had some unique features, many of the underlying principles apply to most human resources systems, and HR-XML took advantage of this basic research on human resources functions. Chuck Allen later said that HR-XML used UML for its business process modeling, and that the DIMHRS experience with UML applied only to that business domain.

Taking the First Steps to Bridge the Divisions

The conference included a brainstorming and facilitation exercise, led by Gary O'Neall of PlaceWare, to identify impediments to collaboration and to agree on steps for overcoming them.

The first brainstorming generated a list of 42 items that the group boiled down to 13 factors, from which five emerged as the leading issues:

1. Roll your own : reluctance to give up turf, hidden agendas, and lack of trust among standards organizations

2. Differing scopes and processes: incompatible operating processes, varying scopes of standards, different origins and missions of standards groups

3. Lack of perspective: failure to see the need for multiple groups contributing to e-business standardization, tunnel vision/inability to see the big picture

4. Lack of awareness of other groups: lack of knowledge of the existence of other groups, as well as their goals, missions, activities; lack of time and energy to keep up with standards world, lack of basic technical understanding

5. Lack of common vocabularies,: both industry and natural languages, as well as lack of international outlook

Of these five issues, most participants said the first was the most serious, and the group discussed steps for dealing with the problem, but they focused on steps that involve working with current organizations, not starting other groups. The most productive steps included establishing formal liaisons between organizations (including the use of online tools), and sharing groups' missions, architectures, and scopes. Practical steps such as scheduling meetings in the same cities at about the same times would help make coordination that much easier.

Four of the sponsors, OASIS, OMG, HR-XML, and XBRL, agreed to hold a second meeting in this series, focusing on procurement, in June 2002. Karl Best of OASIS offered that group's registry as a host for an authoritative list of standards. Bob Hager of American National Standards Institute also described its standards registry and metadata exchange work with ISO.

A basic understanding coming from the meeting was the need for a multi-dimensional approach to e-business standards, which means that no one group could or should try to control the entire e-business standards landscape. In that spirit, Chuck Allen saved perhaps the most important announcement about standards convergence for the end of the meeting, when the number of participants had dwindled to about 20.

In that last session, Allen and Kim Bartkus of HR-XML discussed the Staffing Industry Data Exchange Standards (SIDES), some of which include processes not unlike those found in many other industries: request for quotations, orders, and invoices. Rather than writing their own specifications for these processes, HR-XML will deploy SIDES transactions as Open Applications Group (OAG) messages in order to take advantage of their several years worth of work on these kinds of business documents. OAG messages can be implemented either in ebXML or in Microsoft's BizTalk, which will give HR-XML a wide base of potential implementations.

This approach allows HR-XML to capture its business knowledge in an HR industry vocabulary, yet at the same time connect with more generic business messages and architectures, and thus provide a greater chance for interoperability with other vocabularies. Since most companies and organizations conduct at least some human resources functions, one can see how this approach will benefit a wide range of industries, which should be the whole reason for using XML in the first place.