There’s been lots of talk in the trade rags over the last year about enterprise application integration (EAI). Basically, EAI is the process of creating standard bridges between the different systems that make up an organization’s computing environment. A lot of the emphasis on EAI is the result of the increasing number of mergers and acquisitions, which require companies to keep multiple similar systems operating while developing their long-term integration strategy.

Unfortunately, many of the resulting EAI initiatives have resulted in ill-conceived and short-sighted strategies designed only to solve the near-term problem of application integration within a company and not the longer-term issue of how applications between companies will be able to integrate. With an understanding of the role that XML can play in solving these problems, you can position your company to solve both the “within” and “between” application integration issues at the same time.

When integration problems are like rabbits
Let’s suppose you need to pass invoice data bi-directionally between two systems, where System A stores invoice data in Format A and System B stores invoice data in Format B. To solve your data transfer issues, you just need to take one of your entry level COBOL or VB programmers and have him or her write two programs—one to move data from Format A to Format B, and one to move from Format B to Format A. Simple, right?

Well, let’s suppose you add System/Format C to the mix. Now you don’t need to write just two programs, but six. Add System/Format D and you need 12. And this is just one set of data (invoices) being moved around. This can quickly turn into a “rabbit farm” problem (or “Tribble” dilemma—if you’re from a more technical background).

A more reasonable approach is to decide up front on the format and structure for the common invoice elements of all the systems. Then develop a single in/out conversion program for each system to and from the common format. Now imagine that you can get a large number of commercial software developers, integration firms, and industry groups to standardize on the same formats for data transfer even if their internal structures are different. All of a sudden, we’re not just solving our own EAI problem, but working toward a solution in which systems between multiple companies can now exchange data more easily.

When EDI isn’t enough
Isn’t this what electronic document interchange was designed to do? In a simplistic way, the answer is “yes.” In the late 1970’s, users and vendors input their requirements to create a set of national electronic data interchange (EDI) standards. They were working to develop data formats that could reduce the labor-intensive task of exchanging data while being:

  1. Hardware independent
  2. Clearly defined so all trading partners could understand them
  3. Structured in a way that allowed the originator of the transaction to control the exchange and verify if and when the recipient processed the transaction

Today there are two widely recognized EDI standards: X12 and the Electronic Data Interchange For Administration, Commerce, and Transport (EDIFACT). Although the X12 and EDIFACT standards provide a great deal of flexibility regarding how application data is represented by EDI data, they both suffer from the same problem: They’re rigid, externally defined data structures designed to pass data between systems and not allow systems to interoperate. Implementing EDI also requires the purchase and maintenance of expensive software and systems as well as a contract with one of 20 or so value added network providers (or VANs). None of these requirements makes EDI conducive to use in an EAI environment.

XML, on the other hand, provides a dynamic, self-describing or externally described data format. The flexibility of defining unique data structures for each vertical industry and document type versus the rigidity of conforming to the X12 or EDIFACT standard makes XML an ideal tool for enabling business-to-business transactions. With XML’s ascension to the throne as the next “on the wire” data format for Web applications, it’s natural that software developers and their customers are looking for ways to leverage XML as a data transport between applications.

When will XML be ready for prime time?
There are a few groups in the industry working to define the document structures (also called XML schemas) for specific vertical industries and promoting their use to software developers, industry consultants, and companies in the affected industries. One of these is the BizTalk consortium.

BizTalk is not a standards body. It’s composed of potential users of the standards who are committed to sharing their work in defining schemas in order to accelerate the adoption of XML-enabled, business-to-business e-commerce and EAI. The end result of this effort is called the BizTalk Framework™. The framework defines a set of guidelines for how to publish schemas in XML and how to use XML messages to easily integrate software programs.

It will take a couple of years for the standards defined by the BizTalk group and other competing efforts to shake out, but during the shakeout it’s well worth your organization’s time to investigate standardizing your internal application integration efforts on one of the industry schemas. I expect the competing groups to provide an XML- or XSL-based migration path from their industry schemas to the mutually agreed-upon industry schema. In the interim, you can derive a lot of value from getting your internal systems to communicate using a common, XML-based schema. The BizTalk site also has resources like mapping tools, sample code, and white papers to help you begin the process of defining your business using a common schema.

Tim Landgrave is the founder and CEO of eAdvantage. His company assists small to medium enterprises in the development of their electronic business strategy.