Interoperability Summit: Good Intentions, Little Action

July 10, 2002

Alan Kotok

The Second Interoperability Summit, held 27-28 June 2002 in Orlando, Florida, showed that more e-business standards groups are willing to collaborate and showed various ways they can do so. The session also illustrated the difficulty of the task ahead and highlighted the need for more concrete action and urgency in achieving the interoperability goal.

The meeting, sponsored by OASIS, Object Management Group, Extensible Business Reporting Language, and HR-XML, continued the work of the first Interoperability Summit held in December 2001 (See Interoperate or Evaporate, XML.Com). At the first summit, participants wrestled with identifying barriers that prevented cooperation among standards groups. At the second, the group of some 50 participants -- down from about 80 the first time -- heard about ways that some organizations try to achieve interoperability, as well as the need for interoperability in particular industries.

The Need For Interoperability

Summit 2 participants received vivid reminders of why business needs interoperability. Jenny Huang of AT&T Labs described the environment in the telecommunications business, one that has not fared well in the current economy. Huang said that for complex services like telecommunications, the common supply chain models behind many e-business standards often do not apply. However, because telecommunications is a vital and ubiquitous service, it still needs to interact with most other industries.

Huang explained that the business processes behind telecommunications services differ markedly from those used to produce and distribute physical goods. The lifecycle for services starts with a provisioning stage, well before delivery of the service. These processes often involve many interactions among the parties and involve the assurance of service delivery as well as specified service level agreements, not often found in the production and distribution of goods. Also, consolidation in the industry makes value chains fluid and more complex.

Huang added that telecommunications providers need to integrate a large number of legacy systems, a condition not unique to that industry. An industry group called the TeleManagement Forum has developed a "Next Generation Operations Systems and Software" (NGOSS) framework to help integrate commercial off-the-shelf software into their companies' operations. NGOSS is a complex and broad program that includes:

• Definitions of business processes for business processes to support future communications services
• Definition of the service framework for building these business solutions
• Implementations and live demonstrations
• Collections of resources, codes, and training materials

Huang said the group of 350 members in 38 countries wants to develop a component architecture, but still needs a map to show how to fit all of the pieces together.

Ron Dorman from the Department of Defense (DoD) Information Systems Agency talked about the interoperability challenges facing that large and complex organization. While much attention is justifiably devoted to providing systems that support the purely military functions of the DoD, Dorman said those operations cannot function without the support activities, such as finance and logistics.

Dorman said for the DoD interoperability means "getting the right data in the right place at the right time". He described the need for a secure, inter-connected network that gets computing power to the end-user "at the edge". At this point, the DoD is characterized by a lot of point-to-point exchanges, in what Dorman called stovepipes.

In the case of tightly focused top-down data transfers in real time, often used in military operations, this approach works. But Dorman added for non-real time business-oriented data, better ways are needed. The DoD's business operations need to work in a more open environment, where the data flow is less structured and can change rapidly. As Jenny Huang noted in the world of telecommunications, the DoD's most recent operations have involved coalitions, which adds even more complexity and an even greater need for interoperability.

Dorman said his agency wants a market-driven approach to encourage innovation in the DoD's use of XML and connect with communities of interest outside the DoD. In this goal, the agency has begun cataloging and registering XML namespaces and created a management forum to decide on the use of new or amended namespaces.

He encouraged XML standards groups to increase their cooperation, particularly for the development of Web services. In this respect, he saw a role for both the business consortiums that can develop specifications quickly, as well as the traditional standards groups that can build a broader consensus.

ASC X12 and UBL Begin Cooperation

Both the Accredited Standards Committee X12 (ASC X12) and the Universal Business Language (UBL) initiative of OASIS talked about their efforts to reach out beyond their memberships and to each other. Both organizations develop cross-industry business messages, and without cooperation could end up with overlapping or contradictory standards.

Jon Bosak of Sun Microsystems and chair of the UBL technical committee, outlined UBL's goal of developing a set of Web-enabled business messages within the ebXML infrastructure of defined business processes, collaboration protocol agreements, SOAP-based messages, and standard registries. UBL would provide the payload, consisting of a standard a basic core message extended with UBL's context methodology to meet the needs of individual industries. Bosak said the combination of UBL plus ebXML represents the next generation of EDI: cheaper, easier, allows for the reuse of data, and fits into existing legal and trading frameworks.

According to Bosak, UBL's deliverables, scheduled by 2003, are a set of naming and design rules for XML schemas, a library of XML business information entities (BIEs) based on ebXML core components, and a set of standard common XML business documents, such as invoice, ship notice, and purchase order. The context methodology, for extending the basic documents for specific industries, is scheduled for 2004.

To help with the context methodology, UBL has formed liaisons with the two leading standards organizations -- ASC/X12 and UN/EDIFACT -- as well industry groups in accounting, retail, insurance, convenience stores, electronics, and computer technology.

Ralph Berwanger of bTrade, vice-chair of ASC X12, noted that ASC X12 hosted the most recent UBL meeting earlier in June, which offers an indicator of that organization's new attitude toward cooperation with other organizations. ASC X12 is accredited by the ANSI to develop electronic business messages in North America, which up to a few years ago meant the X12 standard for EDI.

Berwanger said the explosion in the number of XML business vocabularies in the past few years mirrored a similar phenomenon that occurred in the early 1980s. At that time industry groups developed their own electronic data exchange formats, which led to the establishment of the ASC X12 standard in 1983. While ASC X12 had initially held back from working in XML, Berwanger says the group is now fully engaged. Several of the X12 industry subcommittees -- transportation, health care, and government -- have written messages using XML. Berwanger added that ASC X12 now requires that subcommittees writing XML messages to prepare representations in X12 and UN/EDIFACT syntax. ASC X12 has as well drafted XML design guidelines, circulated both within and outside the committee for comments.

This time around, according to Berwanger, ASC X12 will bring its business domain knowledge to the interoperability table. The group realizes that it needs to cooperate more energetically with other standards groups and has established a Convergence and Outreach Task Group (COTG) for this purpose. While ASC X12 created the COTG, this group operates more as a open forum rather than an organ of the committee. The goal of COTG is to function as a "community of equals who exchange practices and process, and collaborate in neutral environment". The results of the collaboration, Berwanger added, may end up in ASC X12 or in other groups.

A Little Concrete Progress Noted

The only concrete progress reported since the December meeting involved a registry of standards. In the first summit, participants listed the lack of knowledge about the existence of related work as one of the barriers to convergence. As a result, the group attending the first meeting suggested establishing a registry to serve as an authoritative resource that industry or standards groups could first check before starting comparable efforts.

The group heard a report from Karl Best of OASIS and Bob Hager of ANSI on progress in designing a registry of standards. Best confirmed that standards groups looking for related work or developers seeking to find out what standards groups are doing have few meaningful tools at their disposal. He showed that an ordinary Web search for e-business standards can result in thousands, even hundreds of thousands, of hits with varying relevance and quality.

But Best reported that a project team created at the first summit to work on the registry discovered that a single, central registry would probably not do the job. Instead, the team, chaired by Best, has proposed a common set of metadata that standards and industry groups can use to describe their standards work, as well as encourage these groups to create their own registries.

Hager, the editor of the team, said that the registry team borrowed ideas from several sources, although Dublin Core seemed to be the greatest contributor. The proposed elements include:

• Designation
• Title
• Description
• Identifier, which can be a URL
• Name of standards development organization (SDO)
• Committee within the SDO
• Source of information about the SDO , which can be a pointer to URL
• Subject, expressed as keywords or reference to defined classification schemes
• Current status, from initiation to published
• Date of most recent action
• Referenced standards, which means normative references in standards
• Standards replaced by current versions
• Related resources
• Format, physical or electronic
• Language, using ISO 639 and ISO 3166 codes
• Rights management, covering issues such as copyright and other intellectual property issues

The registry team will now work on refining the metadata semantics, developing an XML implementation, expanding participation, and launching a few pilot test sites.

How to Integrate Standards? Let Me Count the Ways

Several presentations discussed ways that different standards groups integrate the work of other organizations. Sandra Dinetz of the Depository Trust and Clearing Corporation, and participant in several financial standards groups, described how the industry has set a goal of completely settling investment trades no later than one day after the trade (T+1, in their lingo) by 2005. Settlements used to take five days, but recent improvements had cut that time down to three days.

This goal, according to Dinetz, has helped the industry focus on integrating the separate XML and pre-XML standards, covering the entire process from pre-trade to post-settlement interactions. Dinetz said the industry is converging around ISO standard 15022, but it still needs to accommodate the existing standards and account for international initiatives such as ebXML. It also needs to be prepared for any new technologies beyond XML.

Lawrence Leff of Western Illinois University showed how LegalXML had incorporated the collaboration protocol agreement and business process specification schema from ebXML to develop an XML-based contract form. Leff said that should a contract dispute occur, this XML contract would handle the contingencies covered in pre-trial litigation, where the vast majority of disputes get settled.

Gavenraj Sodhi of Business Layers, and a participant in the Service Provisioning Markup Language (SPML) project, discussed how SPML fits into a larger framework of security specifications, including the Security Assertion Markup Language (SAML), the eXtensible Access Control Markup Language (XACML), and XML Key Management Specification (XKMS). These specifications, according to Sodhi, operate on top of other Web services and transport protocols. OASIS established a joint committee to coordinate the development of OASIS specifications (SAML, SPML, XACML), but XKMS was not an OASIS initiative and thus not part of the group.

Where's Web Services, Where's the W3C?

Aside from the security discussion, the only other presentation to address web services came from Sinisa Zimek of SAP AG, who described the Web Services Choreography Interface (WSCI), an initiative of SAP, Intalio, BEA Systems, and Sun Microsystems. WSCI describes the flow of messages in an interaction, often called a choreography, which operates on top of WSDL. Zimek mentioned WSCI as part of a larger discussion of SAP's exchange architecture.

However, the infrequent discussion of web services at the meeting contrasted with the frequent references to ebXML. Many participants were also involved in the development of ebXML or taking part in related efforts such as UBL or the EDI standards. No representatives from the Web Services Interoperability, the W3C, or Microsoft spoke at the meeting.

Next Steps?

A closing panel representing the chairs and sponsors of the meeting -- Karl Best of OASIS, Chuck Allen of HR-XML, Eric Cohen of XBRL, and Jon Bosak of OASIS's UBL committee -- tried to sum up the two days of discussions and suggest the next steps to achieve greater convergence. Except for reiterating the problems and noting that some of the standards groups may fall by the wayside, they came up with few concrete steps that organizations can take.

Cohen and Allen mentioned the Interoperability Pledge drafted at Summit 1 that encourages groups to voluntarily work with each other and avoid duplication. But the task ahead will require more than just promises to collaborate. Some of the Summit 2 presentations had suggestions on how a successful collaboration might work.

First, there needs to be more of a realization that a solution providing interoperability among the multitude of standards and specifications is far greater than the sum of its parts. The collaboration between ASC X12 and UBL discussed at the meeting, for example, shares the belief that new electronic business messages need to combine the business domain experience of EDI with the advantages of a web-based technical infrastructure. By themselves, neither of these standards will fill the bill. Together, they have much more of a chance for success.

Second, there cannot be any one owner or driver of a solution. The parties need an active network where all stakeholders can be connected and engaged in the process. The discussions at the meeting offered two examples of a possible structure for this network. One model comes from the committee writing the metadata for a standards registry. Karl Best of OASIS chairs the committee and that group currently hosts the group's web site, but OASIS does not operate or control the group. In fact, the web site will soon move to ANSI, another of the project's participants.

Another model comes from ASC X12's COTG, which serves as a forum for collaborating on e-business standards, but is not an ASC X12 sub-division. It also does not require that ASC X12 develop solutions recommended by COTG.

Third, interoperability needs to account for the complexity of business, which will not be an easy task. The presentations about interoperability requirements of the telecommunications industry and the DoD showed that any solution needs to address detailed variations in ways that different industries operate, sometimes supporting vastly different cultures within the industries. Also, in the discussion at the end of the meeting, the panel recognized vertical industries will have different business processes and semantics, thus any solution needs to provide interoperability among these industries while still preserving their differences.

Fourth, all major players and standards need to get involved, which means participation by Microsoft, W3C, and WS-I. Without all key players in the mix, the Interoperability Summits will be an empty exercise.

Fifth, there needs to be a greater sense of urgency. Sandra Dinetz showed how the investment industry set specific performance and time goals (T+1 settlements by the year 2005), which focused the attention of the industry and encouraged parties to make significant progress toward those goals. The Interoperability Summits need those same kinds of goals and incentives.

At the opening of the meeting, Eric Cohen of XBRL talked about his fantasy where a piece of business information can be entered anywhere in a supply chain, flow into a company's general ledger, then be reported out in any form needed by the company or its trading partners. Why not make Cohen's dream become the goal of these summits, in time for T+1 settlements in 2005?