OO-edi or XML/EDI?

A Comparison Based on "Non-Functional" Requirements

Part 2 of 2 Parts

Michael C. Rawlins

Dr. Lawrence Chung

Recap

In Part 1 [RAWLINS99], we explained the concept "non-functional" requirements (NFRs). These types of requirements, also termed quality requirements or system constraints, deal with attributes of the system such as cost, performance, reliability, security, and maintainability. These are contrasted with functional requirements that deal with the behavior and functions of the system. We put forth the notion that non-functional requirements analysis is particularly appropriate for EDI since most of the documented barriers to EDI, such as cost and complexity, are more non-functional than functional in nature. We then gave some background on quality requirements analysis, and gave the rationale for selecting our analysis tool, the NFR-Framework [CNYM99]. Finally, we used the tool to develop a set of non-functional requirements for EDI, based on review of a representative sample of studies.

In this part, we use the framework to compare the front running approaches for the next phase of EDI, OO-edi (via distributed object technology), and XML/EDI. As we noted in Part 1, different companies might have different views about which requirements are critical. Since the main thrust of many of the new EDI approaches is to make EDI easier for small to medium enterprises (SMEs), we will evaluate these approaches in terms of how an SME might view them. To set a base line, we'll examine how traditional integrated EDI satisfies the SME requirements. We will then examine an X12 based version of XML/EDI (X12-XML), OO-edi using distributed object technology, and then compare all three.

Further Defining the Question

For this article we use the classic definition of EDI, which is the application to application exchange of structured business documents without human intervention. This type of exchange is typified by a customer sending a purchase order electronically to a supplier, then receiving an invoice electronically after the goods are shipped. This is traditional electronic commerce and not the Web.

Some authorities have estimated that over 95% of Fortune 1000 companies use EDI, yet only 2% of SMEs use it. Surveys also indicate that most of these SMEs use EDI primarily because a large trading partner requires that they use it, rather than due to any of the many other benefits cited for EDI in the literature. A typical trading community might have a large customer, such as Wal-Mart or Target, serving as the “hub” at the center of the community (See Figure 3). The suppliers, which might typically be SMEs, are then viewed as “spokes”, arrayed around the hub like the spokes of a wheel. The spokes must conform to the hub’s trading practices if they wish to remain suppliers. A spoke may be a supplier to several different hubs, all of which might have different trading practices. As we shall see, there are two main challenges in making EDI better for the spokes. One is enabling them to benefit from EDI in ways other than in just keeping their customers. The other is making it easier for them to deal with the differing requirements of the hubs with which they trade.

For this study we will only consider SMEs that use a business application to support the business processes that interact with their partners. SMEs that haven’t yet automated or don't own computers are beyond our scope. An SME has three basic choices for implementing EDI:

  • Don't
  • A stand-alone EDI system which doesn't interface with their business application
  • An integrated EDI system which does

In another study we analyze all three approaches, but for this one we analyze only the integrated approach.

So, the question we wish to answer is this: Which of traditional integrated EDI, X12-XML, and OO-edi best supports an SME's EDI transactions with their trading partners? We ask this question in Figure 1, showing the three options as Integrated_EDI[Exchange_Documents], X12-XML[Exchange_Documents], and OO-EDI[Exchange_Documents].

Figure 1 - Which is best?

It is obvious that this diagram only poses the question. It is too high level and provides no basis for deciding which is best. To answer the question we must examine some key features of each approach and determine how well each satisfies a few key requirements.

In examining how well these approaches satisfy the requirements, for integrated EDI we can rely on generally accepted industry opinions derived from actual experience. However, we have no such experience to draw on when it comes to X12-XML and OO-edi since there aren't yet any implementations. Therefore, our opinions we will have to be more a bit subjective and speculative, and therefore more open to challenge.

Traditional Integrated EDI

In traditional integrated EDI, the EDI systems interface with the business applications. Under the right circumstances, this is the best approach currently available for many SMEs. The main features of the integrated EDI system are:

  • Export outbound documents from the business application and translate them into standard EDI formats - represented as Export_Outbound[Process_Documents].
  • Receive inbound documents into EDI system, translate them into application format, and import into the business application - represented as Import_Inbound[Process_Documents].
  • Transfer documents via EDI network - represented as EDI_Network[Transmit_Documents].

Figure 2 shows how well the integrated EDI system satisfies our requirements. For this, as well as the X12-XML and OO-edi graphs, we omit several requirements for clarity and focus on a few key requirements that help highlight the differences between the approaches.

Figure 2 - How good is an Integrated EDI System?

In this graph we introduce a new notation. The dashed cloud, Many_Transactions, is called a Claim. Used here, the Many_Transactions claim indicates an "if then" type of condition. If there are a large number of transactions, the savings associated with eliminating data entry offset the costs of the EDI system. The positive impact is indicated by the plus sign on the link, and we assert that the claim is true by showing a check mark over the Many_Transactions cloud.

The integrated EDI system satisfies the critical requirements as follows:

  • Trading partner satisfaction is achieved (assuming of course that the hub has mandated EDI!).
  • Data Entry Costs (both direct and indirect) for the application are not only minimized, but eliminated. Importing inbound documents and exporting outbound documents have strong positive impacts on these costs, as shown by the two plus signs.
  • Integration Costs for the application are not minimized. Programming is often required to integrate the EDI system with the business application.
  • Value Conversion Costs for the application are not minimized. Programming is often required to convert general standard coded values such as SIC and SCAC codes to those used by the application.
  • Application costs are minimized due to reduced data entry offsetting the other application costs.
  • Cost of the EDI System is not minimized. The considerable acquisition, programming, and operations costs have a strong negative impact, shown by the two minus signs
  • Cost of transactions is minimized. If there are many transactions, application savings offset the EDI system costs.
  • Cycle time is minimized due to the due to the minimal time required to transmit documents over an EDI network.
  • The overall requirement of good transactions is satisfied since all three of its child requirements are satisfied.
  • A configurable, and therefore a dynamic EDI system is achieved since the EDI system is configured by the user programming maps.
  • Dynamic EDI standards are not achieved due to the lengthy process by which new X12 and UN/EDIFACT standards are approved.
  • A dynamic system that supports dynamic business processes is not achieved. Even though we have a dynamic EDI system, we also need dynamic standards.

This figure shows how the NFR-Framework is used to evaluate an approach. As noted above, integrated EDI brings its greatest benefit if there are sufficient EDI transactions such that the cost of the EDI system is offset by reducing the costs associated with manual data entry. So, for X12-XML and OO-edi to offer any improvements over traditional EDI, they must lower this threshold while still satisfying the other requirements.

Before we examine X12-XML and OO-edi, let us talk a bit more about "claims" since they will play a critical role in our analysis. Claims can be used to indicate "if then" conditions as shown in Figure 2. However, they can also be used to indicate assumptions. This is particularly important in our analysis of X12-XML and OO-edi. Unlike traditional integrated EDI, there is little consensus regarding how well these approaches satisfy requirements. The basis for any particular assertion we might make in our analysis may not be immediately apparent. Therefore, we will often require explicit justifications and assumptions for making assessments. This allows others to at least understand the reasons for our assessment, even if they don’t agree. In the NFR-Framework, claims can be very helpful in making clear these kinds of assumptions. In addition, since there aren't any X12-XML or OO-edi systems yet, there are some cases for which we can rely only on their design goals. We can also use meeting a design goal as a claim.

XML/EDI based on X12

XML has been widely touted in the trade press as a technology that will replace EDI. We feel that many of these pronouncements are exaggerations, since XML/EDI in the big picture is still just EDI. However, as we will show, XML/EDI offers some advantages over traditional EDI.

As a refresher, XML is Extensible Markup Language. It was developed for use on the World Wide Web to overcome the limitations of Hypertext Markup Language (HTML). XML's main advantage over HTML is extensibility, that is, you can create your own tags and formatting. The ability to create tags led to the idea of creating tags not only for document markup but also for data. This is the basis for using XML as an integration and EDI technology. For more background on XML/EDI, please refer to Rawlins article of last year [RAWLINS98].

There are many approaches to using XML for EDI, but so far only one addresses a wide range of business transactions and industries. That is the XML work being conducted by the Accredited Standards Committee X12 of the American National Standards Institute, responsible for cross-industry EDI standards in the U.S. For this reason, and because the readers are likely to have an interest in X12 EDI, we have selected X12's XML approach for our analysis. The approaches may have some significant differences, but we feel they have enough in common that analyzing X12-XML addresses most of the important issues.

X12C, the Communications and Controls subcommittee of X12, has been working on a methodology, dubbed X12-XML, to "represent X12 semantics in XML syntax". There is a great deal of information (or semantics) about business processes and data in the X12 EDI standards. However, it is bound to our current X12 syntax with all of its segment tags, segment terminators, delimiters, etc. The goal of the X12-XML effort is to describe a way to separate the business information from the representation in X12 syntax and enable XML as an alternate syntax.

At the time of this writing, the technical report describing the X12-XML methodology was in the final stages of development. It will probably have a few revisions, but it is stable enough to allow an analysis. The X12-XML project has many goals. However, at the most basic level it seeks to "expose the semantics" hidden in X12 transaction sets so that they will be more useable by the XML community. This is not an approach to create or improve the standard for the business information (the semantic part of the X12 standard), but instead a technical effort to allow it to be used in XML documents.

The key aspects of the X12-XML methodology are:

  • Provide a unique “semantic identifier” for each X12 data item. These are human readable names that are used as the XML element names or tags.
  • Provide an optional unique “syntactic identifier” for each X12 data item. These are based on segment and element positional information, and would assist translation software in processing X12-XML documents.
  • Mimic the structure of an X12 transaction set (segments, segment groups, loops, etc.) in the structure of the corresponding X12-XML document.
  • Promote ID qualifiers to the level of the item being qualified. For example, the first element in the N1 Name segment, N1_01, provides a qualifier that tells the type of name in the second element, N1_02. However, in actual usage the qualifier also applies not only to just the N1_02 name but to the entire N1 Name/Address loop. So, if in native X12 the N1_01 element, Entity ID, contains an “ST”, in X12-XML "Ship To" in the loop tag identifies the whole name/address block as a Ship To location.

Several conditions must be met before the X12-XML approach can be implemented. These are pre-requisites to the approach, so are not shown as claims. Readers should consider these when assessing the viability of the approach.

  • The X12-XML Technical Report and related work items are approved by X12
  • Existing X12 translation software is enhanced to support XML syntax messages in addition to native X12 syntax messages. Additionally, for full XML support the translator vendors also enable automatic creation of XML Document Type Definitions (or DTDs) based on the user's implementation. A DTD is a template that specifies the tag names (i.e., the XML element names) and structure of the XML document.
  • Vendors of application software fulfill the current promises of including at least generic XML import and export features within their applications. This XML import/export is a key requirement for integrating XML/EDI with business applications.
  • XML to XML mapping is supported. We expect that X12-XML will be only one of many XML/EDI approaches. In addition, some low-end applications may import and export only using their own native tags and may not support any of these approaches. Therefore, mapping and conversion will be needed to allow these different XML encoding schemes to inter operate. Such support could either be built into the business application or be provided by a stand alone XML to XML mapper and converter.

There are several approaches to implementing X12-XML. Figure 3 shows a sketch of one in which a large, central hub trades with several smaller spokes using a translator that supports both native X12 and X12-XML.

Figure 3 - An X12-XML Hub and Spoke Architecture

Figure 3 shows the hub sending documents to a number of spokes. To understand how documents move through the systems, we can consider procurement. The hub’s procurement application creates an export file of outbound purchase orders, labeled “EXP” in the figure, and processes this file through the X12-XML enabled EDI translator. The translator produces documents that are encoded in either traditional X12 syntax or as X12-XML. These documents are then transmitted to suppliers through a network, the Internet in this example. The only change from the hub's current X12 architecture is adding X12-XML syntax capability.

For a supplier receiving traditional X12 syntax purchase orders, the X12 encoded documents are processed by an X12 translator to produce an import file, labeled “IMP” in the figure. This is then imported into the supplier’s order management system. So, those spokes continuing to use traditional X12 syntax are not affected.

The suppliers receiving X12-XML encoded purchase orders have three options. None require specialized X12 translation and management software. For all three options the hub supplies a DTD.

  • If the supplier's order management system has a built in XML mapper, they may import the XML formatted documents directly into their system.
  • If the supplier's order management system supports XML, but only using native tags or an encoding scheme other than X12-XML, a stand alone XML to XML converter is required. It reads the trading partner's DTD and the business application's DTD to convert an X12-XML document into the XML format that the application expects. The resulting XML document is then imported into the order management system.
  • If the supplier’s application is not XML capable, the X12-XML document can be displayed in a web browser using the DTD and what is called an XML style sheet, shown as “XSL” in the figure, to control the display and formatting. The hub creates the XSL style sheet using an XSL authoring tool, and makes it available to the spoke over the Internet in the same fashion that HTML pages are currently served.

The spokes send documents to the hub via a similar process.