Works and Plays Well with Others (AEC Insight Column)

Industry participants need to implement and adhere to AEC interoperability standards.

As defined by the Institute of Electrical and Electronic Engineers (IEEE), interoperability is "the ability of two or more systems or components to exchange information and to use the information that has been exchanged." The International Organization for Standardization (ISO) requires "the capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units."

Consequently, according to the popular online encyclopedia Wikipedia.org, "interoperability tends to be regarded as an issue for experts, and its implications for daily living are sometimes underrated." Wikipedia also notes that "interoperability can have important economic consequences. . . . If competitors' products are not interoperable . . . the result may well be monopoly or market failure. For this reason, it may be prudent for user communities or governments to take steps to encourage interoperability in various situations."

Regarding interoperable software for AEC, user communities' and governments' principal focus since 1995 has been the International Alliance for Interoperability (IAI), which has developed a recognized standard: Industry Foundation Classes (IFCs). Responsibility for IFCs in the United States lies with the National Institute for Building Sciences (NIBS), which groups IFCs in its buildingSMART initiative along with aecXML data exchange and its progeny, AGCxml, gbXML and so forth; National CAD Standard (NCS); National BIM Standard (NBIMS); and related activities supporting intelligent and sustainable building processes.

What's at Stake?

"Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry," a study published by the National Institute of Standards and Technology (NIST) in August 2004, estimated interoperability-related economic losses of $15.8 billion in 2002, or nearly 2% of all U.S. construction spending that year. The study's authors noted their estimate was "likely to be a conservative figure." Other estimates of bad information and processes in AEC have ranged as high as 10%, as in the 1998 United Kingdom–based study, "Rethinking Construction," popularly known as the Egan Report, which estimated a further 20% improvement in project quality (hence the oft-misquoted 30% improvement attributed to the report's principal author, Sir John Egan).

Averaging NIST and Egan estimates at 5–6% and applying that amount to current construction spending of $1.2 trillion implies $60 billion to $72 billion per year wasted because of inadequate interoperability in the United States alone and $250 billion to $300 billion worldwide. Again for perspective, total worldwide spending for AEC design software approximates $2.5 billion per year. Thus, each penny spent on AEC design software results in at least 99 cents of construction value wasted due to the software's lack of interoperability.

"Interoperability in the Construction Industry," a 2007 report by McGraw-Hill Construction, estimated an average of 3% of direct project cost lost to poor interoperability. Furthermore, McGraw-Hill identified building information modeling (BIM) technologies and methods as key drivers for enhanced interoperability and related benefits.

Which Comes First?

However, the results of the McGraw-Hill survey imply a chicken-and-egg situation: BIM adoption drives greater interoperability, yet implementing BIM depends on greater interoperability. This paradox is neatly summarized in quotes in the report from CAD/BIM software vendors. Bentley Systems vice-president Brad Workman said, "Now that we're starting to see adoption [of IFCs], we're going to have to do a better job of fulfilling it." This response sharply contrasts earlier positions by Bentley corporate marketing, which responded to the 2004 NIST study by blaming archrival Autodesk for "business practices that create waste by reducing software interoperability in our AEC industry" — thereby implying that Bentley already was doing "a better job."

For its part, Autodesk is represented in McGraw-Hill's report by vice-president Phil Bernstein, who commented that "the demand for interoperable applications right now exceeds our capacity to achieve it." Here, too, the remark contrasts sharply with prior public statements from this same Autodesk vice-president to the effect that "when there's a market demand [for IFCs], we'll meet it."

How're We Doin'?

Software vendors' delivery of real-world IFC-based interoperability can be judged from a January 2008 report by Erabuild, representing 10 European countries — among them Finland, the Netherlands, and Norway — that are pioneers, leading adopters, and strong advocates for IFCs. "Review of the Development and Implementation of IFC-Compatible BIM" was brutally frank. Erabuild found that the IFC standard "is generally agreed to be of high quality and is widely implemented in software," but it judged that "the certification process allows poor-quality implementations to be certified and essentially renders the certified software useless for any practical usage with IFC."

Backing up its stunning conclusion, Erabuild reported anonymous tests of eight leading IFC-certified applications. Two top performers achieved average scores of only 96% and 93% accuracy, respectively, on real-world data exchanges. For context, imagine a single data round trip that includes a 96% accurate export to a 93% accurate import, followed by 93% re-export and 96% reimport. After one such round trip, data accuracy could be reduced to 80%. After three round trips, odds may be little better than a coin toss that any bit of project data remains as designed.

Some blame must go to software vendors that also participate in determining certification processes and that might view IFC certification as a marketing coup rather than a technological imperative. However, the ultimate fault lies in the process itself. Wikipedia explains that software interoperability is achieved by several means, the first of which is product testing. In turn, product testing "depend[s] on the clarity of the standard, but there are often discrepancies . . . that system and unit testing do not uncover. . . . Interoperable product testing is different from conformance-based product testing, as conformance to a standard does not necessarily engender interoperability with another product also tested for conformance."

To be fair to IAI, its standards-writing role extends only to certifying whether products meet those standards — conformance testing, a top-down approach. True interoperability among real-world products must be achieved on a case-by-case basis, a bottom-up approach. This is where enlightened building clients can and must play a role.

Where Do We Go from Here?

The U.S. Army Corps of Engineers (USACE), responsible for the world's largest inventory of buildings and property, takes a cautious approach for 43 Army standard facilities types in its Center of Standardization. Until true design interoperability among BIM platforms is achieved, USACE will specify only one BIM platform for Center of Standardi-zation projects. That platform happens to be Bentley MicroStation, which matters to Bentley's competitors and their users, but the more important point is that a major consumer of AEC data believes multiplatform interoperability remains inadequate for many mission-critical facilities.

As the world's largest owner-operator of nonmilitary real estate, the U.S. General Services Administration (GSA) can afford to take a different tack. To help achieve its bottom-up goals of real-world interoperability, GSA has engaged Georgia Tech professor Chuck Eastman and his students in the AEC Integration Lab to test, debug, and redefine interoperability use cases from concept design through the entire AEC process across all leading platforms (figure 1). This approach exemplifies the difference between conformance testing (against a standard) and true interoperability testing (products against each other).

Figure 1. Under contract to the GSA, Chuck Eastman and students at Georgia Tech s AEC Integration Lab are working out details of real-world interoperability during early concept design and beyond. (Courtesy of Georgia Institute of Technology)

In July, Autodesk and Bentley announced intent "to exchange their software libraries and support each other's application programming interface tools to improve interoperability between their products." Hailed by some as a "historic great leap forward," this news was disturbingly silent regarding IFCs. Optimistically, making two leading product suites interoperable with each other could simplify making both interoperable with everything else. However, the result also could be an Autodesk–Bentley duopoly at the expense of IFC-based interoperability generally — to the detriment of user choice among worthy products such as Gehry Technologies' DigitalProject, Graphisoft's ArchiCAD, Nemetschek's Allplan and VectorWorks, Onuma Planning System, Tekla, Vico, and many others.