Using Technology to Cross Organizational Boundaries, part 2

A Variety of Approaches

No one system can be appropriate in every situation. Instead, as designers produce a new system, they make specific tradeoffs around the issues we discussed above. The exact tradeoffs made for any given system will make it better suited for some situations and less appropriate in others. To understand the way these tradeoffs play out, we take a look at several electronic business systems in detail. There are many different approaches and systems available. We've chosen a representative sample that includes the most widely deployed systems.

EDI

Electronic Data Interchange, or EDI, was the first electronic business approach to be widely adopted. And many implementations of EDI have shown impressive returns, although EDI deployment has required sufficiently high levels of investment and integration work to limit it to only the largest enterprises. In recent years, EDI deployment costs have dropped and enabled more organizations to take advantage of it, but EDI implementations still tend to be expensive.

The development of EDI was motivated by the realization that simple cross-organization business processes such as purchasing, shipment tracking, and inventory queries were tremendously inefficient. Two business partners were likely to each have enterprise systems that provided internal support for these processes. Yet, when it came time to make a purchase order, the order itself and all associated documents would be transmitted and processed using inefficient manual processes and slow delivery mechanisms such as postal mail.

EDI thus focused initially on producing electronic versions of traditional business documents such as purchase orders and invoices, and then enabling automated processing and transmission of those documents. By introducing EDI systems, organizations were able to transform processes that could take as much as a week and perform them in hours.

In a typical EDI application to support purchasing, an EDI system is integrated with the existing purchasing system at the buying company. When a buyer enters a new purchase request into the purchasing system, a corresponding request is sent to the EDI system. The EDI system then constructs an electronic purchase order document and transmits that to the selling company. Originally, EDI transactions were all sent over dedicated communications channels, which meant that such channels had to be set up between any pair of organizations wishing to use EDI between themselves. To alleviate this bottleneck, 3^rd party organizations have emerged offering Value Added Networks, or VANs. These VANs take care of the transmission details between subscribers. Thus, a company can subscribe to a single VAN and require all its partners to subscribe to that VAN. In this way, the company does not need to set up dedicated networking connections to each of its partners. Currently work is underway to enable the delivery of EDI transactions over the Internet.

When the purchase order is received at the selling company, over a dedicated connection, via a VAN, or via the Internet, it is processed by the receiver's EDI system. This system transforms the message as required and inputs it into the receiver's enterprise system. Once in that system, the new order is handled just as any other order would be.

This process is illustrated in Figure 1, EDI Implementation, below.

Figure 1. EDI Implementation

This example illustrates the source for the costs of an EDI implementation. First, the two partner organizations need to agree on the exact formats of the documents exchanged between them. The EDI standards provide initial definitions of common business documents, but historically, these have been inadequate for actual use. Instead, each EDI deployment has involved negotiation on and agreement to a set of Implementation Conventions describing the extensions to the standard documents and the actual formats that will be exchanged. This negotiation and agreement process represents a significant cost for EDI deployments.

To address this issue, the EDI standards organizations, EDIFACT and ANSI X.12, have undertaken an effort to standardize sets of documents for various industries. For example, ANSI X.12 has recently released a set of standard EDI document definitions for the health care industry. Using these industry standard document definitions, the customizations required per relationship can be reduced, although in general, per-relationship work is still required.

Next, once the Implementation Conventions are decided on, custom integration work must be done at both partner organizations in order for the existing enterprise systems to process the EDI documents. This typically involves purchasing a commercial EDI system, integrating it with the enterprise systems, and writing custom code to transform between the EDI system document definitions and the corresponding enterprise system records. These projects are often significant IT and system integration efforts and can take months to complete and cost hundreds of thousands of dollars.

Because EDI is based on document interchange, one significant integration cost is avoided. The EDI and enterprise systems at the two partner organizations do not need to directly reference each other -- instead all interaction is accomplished via document exchange. This means that most firewall and security issues are bypassed. EDI also provides some insulation from upgrade costs when partner enterprise systems are upgraded or changed.

But, because the set of documents supported by EDI is relatively limited and extending this set is expensive, it is difficult to use EDI as the basis for a closely coupled relationship. EDI transactions, as currently defined, simply don't support a rich enough set of possible business interactions. Current work in EDI is addressing this issue, extending EDI to support more fine-grained and transactional interactions.

Given the set of tradeoffs involved in the use of EDI, it is best suited for long-term and stable business relationships between organizations that can make significant investments in mechanics to support their relationship. Work that requires tight coupling and coordination such as supply chain optimization or product design is best done outside the EDI context. Straightforward business transactions such as purchase orders can be well supported using EDI. In general, each new EDI relationship requires new customization and integration work. These relationships are thus not entered into lightly -- and return on EDI investment is gained over long periods of time, not over individual transactions.



Previous: Executive Summary		Next: Approaches: Classic Middleware