A communication architecture for the digital economy

- 21^st century EDI -

Tim Weitzel, Peter Buxmann

Institute of Information Systems, 
J. W. Goethe University, Mertonstr. 17, 60054 Frankfurt am Main
Telephone: + 49 69 798-23318     Fax : + 49 69 798-28585
{tweitzel | pbuxmann}@wiwi.uni-frankfurt.de

Abstract

Together with our partner Lufthansa AirPlus, we have developed an XML-based architecture for B2B communication that offers flexible, inexpensive, and secure integration of heterogeneous partners into ‘supply webs’.

Using our prototype, formerly expensive and inflexible EDI-processes can become manageable for SMEs, too, enabling the next step towards open communication and cooperation networks and supporting the flow of information throughout entire purchasing and supply chains. The use of XML also enables the efficient support of various data formats, including EDI or EDIFACT standards, and different business documents such as orders, invoices or catalogs opening EDI networks to SMEs and enabling more dynamic business partnerships.

1. Introduction

Although already commonplace, the Internet is changing the economic world to what is sometimes called the digital economy. But what are the constituents of it? We will certainly not find a general answer to this question in this paper nor even dare to propose one. But we are quite convinced that open standards in general and the eXtensible Markup Language (XML) in particular will play a major role in emerging electronic marketplaces. So far, there was no ubiquitous way of describing data, e.g. on websites or for heterogeneous applications, in a commonly understandable way. There was no universal data format. XML, proposed by the World Wide Web Consortium in February of 1998, has the potential, especially in combination with Java, to be the data format of choice to enable the next step in the evolution of EDI [Bosak 1997]. Or with the word of Dave Brownell: "Java software is portable code ... XML is portable data" [Brownell 1998]. Together with the increasing importance of the Internet, overwhelming industry support [OASIS 1999], or at least strong preannouncements, seem to support our belief in the widespread adoption of XML as a basis for integrating business partners, processes and applications [for an introduction to XML see Bosak 1997; Weitzel et al. 1999a; Garshol 1999]. Eventually, XML’s ability to separate structure from meaning is expected to contribute to the emergence of open markets with non-proprietary XML interfaces being the foundation of business-to-business communication.

But, as one might ask, what is wrong with traditional EDI? Since the late 1960s, especially large enterprises have been using Electronic Data Interchange to expedite the exchange of business documents such as sales orders, invoices etc. In contrast to paper-based communication, EDI is designed to make communication between different systems possible without media discontinuities. Hailed as a strategic competitive advantage, a look at the literature paints EDI as the "killer application" for B2B communication, promising cost reductions in the millions, yielding time advantages and supporting Just in Time production [Emmelhainz 1993]. While this is often true for large enterprises, there is another side to EDI. Presumably, nowadays only 5% of all companies who could benefit from EDI actually use it [Segev et al. 1997]. Especially small and mid-sized enterprises (SMEs) often name the high costs of implementing and running EDI as dissuading factors, and a current empirical study found pressure from larger business partners ("gun-to-the-head-EDI") to be among the main reasons for the implementation of EDI [Westarp et al. 1999]. Furthermore, many of today’s solutions are platform dependent, meaning additional investments in both, hardware and software. Thus, EDI is predominantly implemented by large firms, preventing the electronic processing of data flowing through entire supply chains in open networks. Generally speaking, traditional EDI lacks the flexibility and efficiency required for state of the art electronic business.

In this paper, we will introduce a B2B communication infrastructure that utilizes state of the art Internet technologies (such as Java Servlets) and open standards like XML to support the flow of information throughout purchasing and supply chains. Using our prototypes, formerly expensive and inflexible EDI-processes can become manageable for SMEs, too, enabling the next step towards open communication and cooperation networks. Together with our partner Lufthansa AirPlus, we have developed an XML-based WebEDI-solution that aims at lowering setup and running costs, opening EDI networks to SMEs and enabling more dynamic business partnerships. The starting-point was the attempt to develop a solution which can process any data format, especially the different EDI-standards, but is still flexible enough to be used by SMEs. After defining general requirements for an up to date communication architecture in section 2, a procurement and an invoicing network are described in section 3, while section 4 evaluates the solution in terms of security, costs, integratability and flexibility.

2. WebEDI: Business potential and requirements

The term WebEDI describes the use of the WWW as the basis for both, EDI applications and the transfer of business documents. Existing solutions generally offer an HTML input mask which allows the manual input of structured data, similar to the HTML-front-end to a shopping system. Thus, there is no machine-to-machine connection and no way the client, i. e. the small partner, can import the EDI data into his in-house systems.

The obvious advantage of using the Web as a medium for EDI communication is that the only (client side) prerequisite is an Internet connection and a Web browser. In this context, form-based EDI proves to be a good idea for large companies seeking ways of having their small customers send their data in a standardized format without forcing them to invest large amounts of money [Weitzel et al. 1999b]. But in order to procure the exchange of information throughout the entire supply chain, the solutions need to be more flexible. While form-based EDI is a means of integrating small partners into existing sub-networks, the emergence of new electronic marketplaces, or as CommerceOne calls it the transformation of "supply chains" into "supply Webs" [Glushko et al 1999], requires a greater flexibility, e. g. enabling an easy alteration of transaction content and partners as well as fast and easy integration into in-house systems. Additionally, there are serious security issues to be considered. Although more than 50% of the Fortune1000 enterprises in both, Germany and the U.S. plan to use WebEDI in the future, it is so far only implemented by 7.4% in Germany and 16.9% in the U.S [Westarp et al. 1999]. Questionable security is, by far, the greatest stumbling block to widespread use of the Internet for EDI.

Given these considerations, compared to traditional EDI a state of the art WebEDI solution must meet the following five requirements:

• lower setup costs and time,
• reduced operating costs,
• security,
• easy integration in in-house systems especially of the smaller partners (‘clients’) and
• flexibility and extensibility.

3. Extensible Data Interchange (XDI) - an innovative architecture for exchanging business documents

In the following we offer an overview of possible applications and the technical conception of a solution for exchanging business documents across the Internet that we have developed together with our partner Lufthansa AirPlus Servicekarten GmbH. Through consistent orientation on open Web standards, we hope to offer an answer palatable even to users who reject previous classical EDI solutions. As the language for describing business documents, Extensible Markup Language (XML) plays a key role in this solution.

Extensible Data Interchange (XDI) has an open design, allowing the exchange of basically any business document. Currently, the business processes "sales orders" and "invoices" are available.

3.1 Procurement network

To begin, we assume a procurement scenario in which a customer can electronically place his orders using an XML-based WebEDI solution instead of traditional EDI. The basic idea is an XML-Webcatalog of the supplier’s products generated from his in-house system and entailing his in-house data structures that serves as the foundation of all order processes.

Business documents are exchanged using the HTTP protocol. To ensure secure data transmission, the solution is anchored in the Extranet platform from Lufthansa AirPlus (see section 4.3). The partners identify themselves with SmartCards, and the data is transmitted using SSL. This prevents third parties from reading or manipulating the data. Figure 1 shows the basic solution architecture: In order for a client (customer, left in figure 1) to place his order, he or she contacts the supplier’s website, and a Java applet presents a product catalog from the supplier’s server described in XML.

Figure 1: Extensible Data Interchange architecture for the sales order network

For this purpose, the solution includes an XML generator (or catalog generator) on the server side for the translation of in-house structures into XML. Basis for the catalog generation is an XML template that describes the tags and structure of the prospective XML catalog. Access to databases is accomplished through JDBC-commands (Java Database Connectivity) from a Java program. Based upon this template and the supplier’s database, the system generates the XML catalog. Figure 2 shows a table ‘products’ and attributes from a database. To generate an XML template, the user simply chooses attributes by clicking. Once configured, the business process can be repeatedly executed, e. g. with up-to-date data, based upon this template.

For the order process, the catalog document entails the supplier's product offering and is made available to the customer through a Java program. The customer, having contacted the supplier’s website, is thereby able to manually fill a shopping cart. In addition, according to trigger-events (such as critical stock requirements) determined by the customer, the order process can be fully automated. In both the manual and the automated processing alternatives, the order is sent to the supplier's web server as an XML document that contains the customer’s order data in the supplier’s format.

Figure 3: Original and completed XML order form in supplier’s internal format

Figure 3 demonstrates how the ‘completed’ XML document is being returned to the supplier. In-house, a Java Servlet further directs this document to the supplier's correct server. Two alternatives currently exist for integration purposes:

For documents like a sales order, SAP in-house formats in XML must, at present, still be created manually. The most time consuming aspect is the identification of the document structure in the SAP system (for example, customizing decisions). SAP AG is currently working to develop XML BAPIs which will automatically generate XML documents from the R/3 system. More precisely, in the context of ‘SAP Business-to-Business Procurement’ the Business Connector will translate BAPIs encapsulating IDOCs to XML [König/Buxmann 1999].

3.2 Invoice network

A company, e. g. a telecommunications service provider or an energy or water supplier, wishes to provide invoices to its customers in a convenient way which enables the flexible and inexpensive integration of the invoice data into the customers' computer systems, conforming to the requirements we proposed in section 2.

Typically, large enterprises use EDI standards to exchange structured business data. But traditional EDI is quite inflexible and implies prohibitive costs for many SMEs. Especially in an invoice scenario, the SMEs or small business units etc. are often on the receiving end of the information flow. In order to find a way to take advantage of the benefits associated with XML and enable a larger community of users to handle existing EDI messages, we built a converter that can transform ELFE messages, the EDIFACT data format used by the telecommunications industry, into easy to operate XML documents and vice versa. As shown in figure 4, the converter requires both, the EDIFACT message (EDIFACT Source-file) and a dictionary or repository containing the information needed for interpreting the EDIFACT message (Format-Description), analogous to the XML template in the first scenario.

Figure 4: EDIFACT-to-XML converter

Comparable to the architecture in figure 1, a customer (invoice receiver) contacts the sender’s website, authenticates himself with his SmartCard and gets access to his (converted) invoices stored in a database.

Because all invoice data is described in XML, customers can easily process the data conforming to their particular needs. The customer either saves the XML-file from his browser to some storage medium and processes it with his own tools or he uses a signed Java applet from the server for importing the invoice data into his database. In the latter case, the applet synchronizes the client’s import template (an XML file) with the XML invoice, using among others XPointers to select particular elements from the XML files, generating SQL commands. This import is supported for all databases accessible via ODBC or JDBC.

Figure 5 shows the converter displaying the original 'raw' ELFE message on the right and its representation in XML on the left.

In contrast to the original ELFE message which can be neither edited nor read outside an EDIFACT application, the tree structure of the XML document in figure 5 together with semantic information about the invoice-elements (as a human-readable documentation of the invoice format as used for the converter) makes it much easier for the client to match the message’s data fields with those in the in-house system. Once this visually aided data matching is complete, the information relating EDIFACT data fields to the in-house computer system is stored in a separate XML file and serves as a template for any future data import of documents described with the particular standard. Thus, "applications processing XML/EDI documents can 'understand' a transaction with access only to the content of the transaction" [Peat/Webber 1997].

Apart from the import of relevant invoice data as defined in the XML-template, the invoices can always be presented in a browser or printed out. Here, style sheets can be used either to display the documents or to print them as needed. While the layout information for document presentation, i.e. fonts, tables, graphics, etc., is stored in a style sheet, all variable data comes from the converted EDIFACT file.

4. Evaluation of the solution

In the following section, the solution presented here is evaluated based upon the requirements listed previously in section 2.

4.1 Setup costs and time

The solution is entirely based upon open standards. On the server-side, a Web server, a Java runtime environment and a 32-bit operating system (Unix, Windows 9x/NT etc.) are the only technical requirements. The client needs to have a Web browser (Netscape Navigator, Internet Explorer, Versions 4.x or higher), also with a 32-bit operating system, as well as a card reader, including a SmartCard (delivered together). The costly procurement or adaptation of existing hardware and software technology can thereby be avoided, simplifying both, time and monetary setup costs. Apart from the card reader which costs about $50, all other requirements are freely available or in almost all cases already available. The simpleness of XML as compared to EDIFACT makes the integration of the solution into the legacy system of the users much easier. The visually supported mapping process, for instance, can be done by any person familiar with his or her database, there is no need for EDI specialists any more, reducing, among others, external consulting costs. And, possibly even more important, since the establishment of compatibility is achieved by mapping database fields to the respective invoice elements he or she wishes to import, the use of ‘full-size EDI’ is no longer necessary, when ‘custom-size EDI’ is to be used. According to the U.S. Chamber of Commerce, the costs for a typical initial installation of an EDI system that is only compatible with one particular EDI standard average at least 50.000 US-Dollars [Waltner 1997]. Although we do not yet have concrete examples of setup costs of an XDI solution, it is obviously only a fraction of the costs associated with traditional EDI.

4.2 Operating costs

Operating costs can be reduced with the help of the solution presented here. Whereas traditional EDI solutions required costly point-to-point connections or expensive Value Added Networks (VANs), the use of the Internet as the medium of communication involves a bare fraction of these earlier costs. In addition, the alteration of transaction content, i.e. the data to be exchanged, requires no more than an update of the XML template document.

4.3 Security

The solution is based upon a secure Extranet with a public key infrastructure and Lufthansa AirPlus being the certificate authority. Anyone accessing the system is authenticated by a SmartCard. The Web server (as in figure 1) checks validity and access rights via a directory server. Data transmission is secured using 128-bit SSL. SSL is a public/private key method for the secure encoding of HTTP connections which denies access to transmitted data to third parties. Because all conventional Web browsers support SSL, it has become the standard security protocol for the WWW, also supported by most Web servers, as well. The Extranet platform provides the necessary infrastructure for authentication of both client and server.

4.4 Integration in in-house systems

As shown, the solution presented here allows not only the ‘manual’ exchange of business data (manual input of order data, presentation of invoice in a browser), but also the integration into the (relational) databases of participating firms. Business processes can be automated to a great extent using triggers. Integration in the system SAP R/3 is achieved using BAPI-calls. The advantage to using BAPIs lies in the lack of adaptation costs involved for the participating partners' internal business logistics systems. Integration with other software systems largely depends on the existence of open interfaces like XML, for example, in these packages. The invoice scenario shows how particular data from a possibly much larger datasource can be imported into various in-house systems without being forced to reengineer internal processes, as is often the case with traditional EDI.

4.5 Flexibility and extensibility

The flexibility requirement is particularly well met through the use of XML. This solution allows the structure of exchanged business documents to be changed with relative ease, i.e. by only changing the application-external XML template document. Furthermore, this concept simplifies the extended incorporation of new business partners in the order or accounts payable networks. Because - in contrast to classical EDI formats - numerous applications can easily process the XML data stream provided by an XML parser, data stored in XML format can be adjusted to meet a number of different software and media requirements.

The proposed open architecture also enables an efficient support of different standards. To be compatible with these standards, separate XML import templates need to be created for each, connecting the datafields of the respective standard to those of the in-house system. Thus, there is basically no limit to the number of different standards that can be supported. Apart from EDI documents, for instance, product catalogs can be distributed, or more generally speaking, business data in basically any format for which there is a dictionary to configure the system can be exchanged. The data source can be any database, an R/3 system or a flat export file format [Weitzel et al. 1999b].

5. Conclusion

While EDI can provide a significant savings potential to large enterprises, many SMEs do not participate in existing EDI networks due to prohibitive setup and operating costs, thereby preventing a smooth flow of information through all stages of a value chain. We presented an XML-based architecture for B2B communication that offers flexible, inexpensive and secure integration of heterogeneous partners into ‘supply webs’. The use of XML also enables the efficient support of various data formats, including EDI or EDIFACT standards, and different business documents such as orders, invoices or catalogs.

The results presented here should help to break down the barriers to network-wide information flow that was so far only achieved between few large partners in parts of much bigger supply chains. Although today EDI is predominantly used by large firms, using open Internet standards and non-proprietary interfaces, e.g. defined in XML, also promises the integration of smaller and mid-sized firms into EDI networks, as well. As a result of this progress, one may further expect WebEDI solutions to gradually replace previous EDI solutions based upon VANs in a first step. A case study from 3Com shows just such a trend [Westarp et al. 1999]. 3Com currently uses solely classical EDI solutions with its business partners. By the year 2000, however, 3Com expects WebEDI to account for an estimated 15% of all EDI transmissions. By 2005, the WebEDI share is estimated to jump to between 85% and 100%. While form-based WebEDI will mainly be used to economize on transmission costs, 3Com also plans the bilateral integration of partners, and here XML will be the foundation.

The full potential of using XML as a data format lies in its ability to empower millions of Web users to participate in and create new dynamic networks. With XML being the basis of information networks, the definition of flexible, open interfaces outside of applications becomes possible, opening networks to a large number of users and enhancing the life span of data. This is why many initiatives striving to make electronic commerce "easy, trusted, and ubiquitous" [CommerceNet 1999] are XML-based. For example, the cost and flexibility advantages of XML as well as the possibility of using a vast variety of existing products and legacy systems are the foundation of the XML/EDI-Group’s E-Business-Framework [Peat/Webber 1997]. Others, like CommerceNet with over 500 participating companies or emerging Internet specifications as OBI or OTP, envision XML libraries or repositories offering a wide range of possible applications [Weitzel et al. 1999a]. Wheter XML will live up to these expectations remains to be seen. We are looking forward to seeing the emergence of open markets with non-proprietary XML interfaces being a foundation of business-to-business communication which some may somewhat prematurely call a pillar of the digital economy.

Acknowledgement

The authors would like to thank Lufthansa AirPlus Servicekarten GmbH for their support and cooperative teamwork and Ralf Kronenberg and Frank Ladner for their superb work in developing and programming the prototype.