Dulles Airport: a Lesson for ebXML

May 16, 2001

Alan Kotok

For those of us who travel on business with any frequency, we rarely think about the external design of airports, much less even see them from the outside. But the story of Washington, DC area's Dulles International Airport offers a lesson for the future of ebXML.

Dulles now sits in the middle of Northern Virginia's high-tech corridor -- AOL headquarters is in the neighborhood -- but at the time of its opening in November 1962, its location, some 26 miles due west from downtown Washington, put it in the heart of rural Virginia, straddling the Fairfax and Loudon county lines. Its stark curved-roof design by architect Eero Saarinen drew raves from critics and awards from the architecture community. (Tourist hint: drive out from the Capital Beltway on the Dulles Airport access road as the sun comes up in the morning and you see this spectacular design both silhouetted on the horizon and reflecting the sun.)

Most air travelers to and from Washington, however, had other ideas. They liked the convenience of National Airport, sitting just across the Potomac from downtown DC. National Airport, until a few years ago, looked like a bus terminal with runways, hardly anything to inspire awards. But for many years, because of its remote location, Dulles Airport had no more than a few international and transcontinental flights and was used mainly for general aviation. Architects may have loved Dulles's design, but travelers liked the convenience of National, and airports of course are made for travelers, not architects. With a little help from the Federal Aviation Administration, which funneled more international and long-haul flights to Dulles, and the choice of Dulles as United Airlines eastern U.S. hub, traffic grew at Dulles to the point where it served 20.1 million passengers in 2000.

What does Dulles Airport have to do with ebXML? Like Dulles, ebXML has a well-designed structure. It offers features matched by few other frameworks, such as trading partner agreements and multi-functional registries/repositories. But at this point, all ebXML offers is an architecture. To be truly useful to business, ebXML needs to provide interoperable business semantics, which makes imperative the rapid and successful completion of the remaining work on core components. EbXML promised this capability in its first 18 months, and while it has come a long way, the job is still not done (see main article).

The main EDI standards bodies -- ASC X12 in North America and UN/EDIFACT elsewhere -- have taken on responsibility for defining core components, and they have vast experience with business semantics in electronic transactions. Both of these bodies need to put this job at the top of their priority lists, if not there already. Their combined credibility as authorities in e-business is at stake.