On Interoperability

From The AIA Center for Integrated Practice

Throughout 2011 CIP featured resources from a range of topics that address how architects and members of the AEC industry tackle the issues and opportunities facing practice today. Listent to the November 2011 featured podcast here!

On Interoperability: Introductory Article and Podcast

Kevin Connolly, AIA, is the President of Connolly Architects Inc. in Milwaukee, WI.  He previously served as a member of  the Center for Integrated Practice Leadership Group and on the AIA National Board of Directors.

Interoperability: free your data from the chimera
By Kevin Connolly, AIA

“Interoperability” seems like a recent entry into the AECO industries' lexicon of buzzwords (such as “green design,” “BIM” and “sustainability”), but the concept is as old as one of Greek mythology's monsters. The chimera was said to be a beast with three interoperable heads: a lion's, a goat's and a snake's. It also breathed fire.

Like the chimera, some supposedly “interoperable” computer software can bite you or burn you in unexpected ways. But unlike the chimera, interoperability also has the potential to produce many benefits.

Many architects are unaware of the issues involving interoperability. They have more pressing concerns, such as staying in business. What those architects “know” about interoperability they may have learned from software manufacturers' ads, and they may be getting the wrong message.  In the absence of industry standards for data information, “interoperability” often refers to compatibility between a proprietary suite of packages, or a cross-organizational alliance which is good so long as the software vendors maintain their relationships.  And sometimes it merely refers to the ability to open another’s document, not data. In selecting software and setting up base files for a project, however, architects must critically consider how the software uses and stores data now and in the future.  

What is interoperability? The word emerged from the Industrial Age and the development of techniques to manufacture interchangeable parts. Among the early examples were standard specifications for railroads' rolling stock, so different manufacturers' cars were interoperable on various rail lines. “interoperability” acquired a new definition with the development of modern machines, our ubiquitous computers.

The challenges of interoperability have plagued architects – and every other business that depends on exchanges of information – since we learned in the 1980s that the PC in the billing department couldn't understand the Apple Mac plunked down on one of our old drafting boards. Then the problem could be simplified to translating data between two machines and a handful of software programs. Today, the complications have multiplied exponentially. A piece of spandrel glass is much more than an element in a curtain wall, it's also in multiple data frames on your computer screen, a highly engineered product with wind and energy considerations, a discrete digital object in a DGN or DWG file, and a billable entry on the contractor's ledger. Dozens, perhaps hundreds of people will “touch” that window's data in their computers before the building's maintenance staff wipes off the first fingerprints off the real thing.

Think about the number of team members involved in your architecture office's current project. Now multiply by the various activities they do. Then consider that for each activity every team member has on average a choice of five to eight software programs they can employ. You soon realize there are thousands of combinations and permutations which could generate data that people need to share, to interoperate.

But hasn't that always been true both for architects and across the AECO industries? Thousands of people worked to build the pyramids, and billions to build the modern world. Yes, that's true, but look at the construction industry's productivity statistics for the last 30 years. Increasingly complex, high-performing buildings demand interoperability through design and construction and into facility management.   More than ever, architects deliver data — data which must be available to every party involved.

Computers' power and speed have facilitated new building concepts, design techniques, systems integration and synergies from collaboration. But what's urgently needed is for software packages to “talk” to each other, using common, standardized terms and expressions so that data can be entered once by the most qualified source and then reused throughout the facility lifecycles. There should be no re-entering, which is a waste of time, very prone to errors and omissions, and expensive ($15.8 billion annually, according to a government estimate in 2004.[1]

With seamless interoperability, an architect's building information model (BIM) data can feed into energy analysis tools or a consulting engineer's analytical software. The contractor can port the model into his authoring software then continue to build  data that can be used for costing, scheduling, fabrication, execution logistics, supply chain, and dozens of other software programs.  And even more valuable it that same data set can be handed over to the owner at project closeout to support ongoing facility management.

Interoperability offers other benefits. When software packages can talk to each other, so do people; interoperability enhances collaboration. Software interoperability also facilitates integrated product delivery, but it’s even more valuable for non-IPD projects, especially when you get to the other end of the “collaboration spectrum.” When a team is completely “silo’d by contract,”  throwing interoperable data over the wall to the next team will greatly improve the productivity of the whole team.

Computer scientists and software engineers have pursued interoperability for decades. Remember Appleworks and Microsoft Works? But creating interoperability for AECO software programs is an ongoing process with an uncertain delivery date. Among the challenges:

• Development of open standards – the common standards on which everyone can agree, or at least agree to abide to – is a slow process and it is complicated beyond anyone’s imagination. Look for examples into buildingSmart (formerly the International Alliance for Interoperability), which has developed specifications for the Industry Foundation Classes, and the CAD industry's Open Design Alliance; both have been around since the mid- to late-1990s.
• The various capital facility industry players are demanding interoperability. In response to that market pressure, some software companies are creating suites of “solutions” that interoperate only among themselves, much like the afore-mentioned PC packages. They promote these suites as interoperable, but this is not going to help the industry as a whole if other software can't integrate the data.
• Other companies are creating business alliances with each other, then writing API’s (custom-tailored software exchange programs). But what happens when the alliance ends?
• Some very strong proponents of IFC are pushing various versions of “IFC lite” specifications so as not to burden the file transfer, but more importantly to just get moving on interoperability. This may be a short-term solution.

AIA’s Board of Directors approved the oAIA's own “Interoperability Position Statement” in 2009. It says, in part:

“The AIA believes that all industry-supporting data must facilitate, not inhibit, project planning, design, construction, commissioning and lifecycle management. This software must support non-proprietary open standards for auditable information exchange and allow for confident information exchanges across applications and across time. This is best accomplished through professional, public- and private-sector adoption of open standards.

“The AIA encourages its members and other industry organizations to assume a leadership role in the ongoing development of open standards.”

Individual architects and their firms must lead, too, by making informed choices of software that supports the emerging standards for interoperability. Just like you learned in high school driving class, it’s all about high-aim steering. Look out as far as you can so you can steer your team in the right direction.

Listen to the From CIP: On Interoperability Podcast on the AIA Pod Net and hear Kevin Connolly, AIA discuss the complexities associated with Interoperability, and how architects can better engage in this important topic.

Center for Integrated Practice Resources

AIA Interoperability Position Statement (2009) - a high quality definition of interoperability for architects at all levels of the issue.

Additional Resources on Interoperability

COBie College - instructional videos on COBie standards for interoperability led by Bill East, PhD, PE, F.ASCE

McGraw Hill SmartMarket Report on Interoperability

buildingSMART - Information on Industry Foundation Classes (IFC)

General Buildings Information Handover Guide: Principals, Methodology and Case Studies- Documents all types of information exchanges across the entire lifecycle, including data exchange formats.

The Lifecycle Challenge Beyond Interoperability - NTAP 2010 presentation by Aram H. Kailian; Leo A. Daly; John M. Russo, AIA; and Jan Reinhardt, PhD

Faster Forward 2011 - the TAP 2011 conference discussed architectural technology issues across a broad spectrum, including Interoperability.  Presentations and supplemental videos are available now!