Long before aggregate, cement and water are churned into roads, bridges and a myriad of other public works elements, concrete contractors already have spent millions of dollars on information. Far too much of this money was wasted, consumed by unnecessarily duplicative efforts or lost for failure to capture critical data. Operational costs were inflated and profit margins reduced well before the lime, silica and alumina hardened because the industry has more control over chemical reactions than it does over information generation, archiving, retrieval and transmission.
Industry experts claim that 60 to 80% of the total cost of operation, including capital, labor, materials and transportation, is directly attributable to information management. Information management in this context encompasses tracking labor, generating invoices, collecting accounts receivable, creating and coordinating construction and shop drawings, ordering materials, controlling inventory, paying taxes and monitoring energy consumption. More management time and sweat are expended creating, finding and sharing information than ever spent on bending rebar, moving sand and cement or building the perfect road.
The promise of technology is finally catching up with the real-world problems of information management. While the contracting industry has profited in the past decade from the proliferation of digital aids—expanding computer networks, the growth of the Internet and increasingly powerful software—there are serious downsides.
The greatest: Every software application and platform, every dot-com portal or collaborative site, every company information system is an isolated silo of information. They’re almost always incompatible. Exchanging critical information is difficult—if not impossible. There’s too much re-keying of basic information. Innovative applications are dismissed or rarely used because of the hassle and cost of collecting and entering data. Valuable information sequestered in one silo is unknown, disregarded or recreated at considerable cost in another.
The answer: Interoperability—freely exchanging information across data barriers. The industry needs to create information once and pass it among various applications seamlessly, complete with all of its attributes and dynamic relationships. Imagine one company being able to "read" construction drawings generated by another for cost-estimating data, then taking the same drawings and extracting scheduling, maintenance and other project management data. Imagine the potential of "mining" your computerized inventory, labor and delivery schedules to develop generic invoices that would easily slip into any accounting package operated by all customers—regardless of those customers’ unique needs.
Nothing lost in this translation
Help is on the way in turning the dream of seamless information transfer into commercial reality. The technical trick is to express information in formats that can easily be exchanged among various software applications and platforms without corruption or loss of functionality. The International Alliance for Interoperability (IAI), established in 1995, has been working on the problem with its counterparts throughout Europe and the Pacific Rim for the past six years.
During the past 18 to 24 months, IAI and its partners in the software industry have made significant progress and have been joined by other major professional societies and trade associations in the quest to develop and promote wide use of interoperable information systems. The American Institute of Architects, the Associated General Contractors of America, the Civil Engineering Research Foundation, the Construction Specifications Institute, the Design-Build Institute of America and the National Institute of Building Sciences have joined with IAI in the interoperability project.
Two common transactions explain the twin technological paths being pursued by IAI and its associates.
First, take the common invoice—the statement generated, for instance, by the fabricator of double-tees (the primary pre-stressed span used in bridges). Thousands of such invoices are sent to state and federal departments of transportation, county governments and private-sector clients daily. The fabricator wants to be paid for his product, including the cost of components, labor, transportation, design and other value-added essentials.
The problem, as defined by chief financial and information officers from some of the nation’s largest firms, such as HNTB and Parsons-Brinkerhoff, is that "if you have 2,000 clients, you will have 1,900 different formats" in which invoices must be structured. That means that critical data such as job numbers, dates, product quantities and more must be formatted differently for each client. Reformatting takes time and money, and mistakes are inevitable.
IAI, in its initiative to develop an extensible markup language for the AEC industry (aecXML), is developing standards that will be used by software companies to alleviate the problem and simplify the contractor’s life. An XML schema is a set of textual rules for tagging data with descriptive labels. Thus labeled, the data can be exchanged without regard to the vagaries of various software applications.
Using the invoice example, vendor A would be able to capture a range of data from its own systems and transmit it via aecXML to customers B, C and D. Each customer would then be able to manipulate the data into whatever format it needed. That means B could list a project number first, date second, tons of concrete third, and so on. Customer C could take the same file and list the road designation first, the amount of concrete second, account number next and, somewhere at the bottom of its format, the date.
All of this would transpire regardless of the accounting packages, websites or other traditionally delimiting information systems employed by each of the customers. To the invoice-generating vendor, the multitudinous formats of customers would be irrelevant; the data, transmitted in aecXML format, would be malleable to the needs of the various customers.
The second example involves more complex elements such as computer-aided design (CAD) drawings. A contractor is presented the construction drawings of a parking garage which, among other components, list a number of pre-stressed tees and double-tees. Traditionally, shop drawings would be generated. Separate software packages would be used to keep track of aggregate, cement and other components. Other software may even operate a mechanized fabrication plant. More software would generate accounting documents, and so on.
Further frustrating contractors, engineers, architects and customers is the fact that drawings generated in one software package cannot generally be used with another. Objects drawn using software from Autodesk, Bentley Systems, Nemetschek A.G., Bricsnet US LLC and other CAD vendors are not readily exchangeable.
That’s where IAI’s long-term project developing industry foundation classes (IFCs) comes into play. IFCs are object-oriented standards developed in ISO/STEP Express language. They represent elements of a building, such as a supporting member, a door, a corner post or a system such as a building ventilating system, and express a representation of the entire project as objects linked by relationships to other objects. The resulting computer model—the IFC—can be read by other IFC-compliant software.
Money to be saved
This is a revolution for the design process as well as for business applications. Software employing aecXML schemata and/or IAI’s IFCs will be able to maintain the integrity of critical data while it is transferred to other applications. Sir Michael Latham, a former member of parliament now active in the U.K. IAI, chaired a study that has been widely quoted saying that implementation of interoperable information systems would yield savings upwards of 30% to the construction industry. IAI in North America, using construction data provided by McGraw-Hill and Cahners CMD Group, estimates that use of IFCs and aecXML schemata in the AEC industry would yield $7.5 to $15 billion annually—a significant savings by any measure.
Within the past few months, Autodesk Inc. (U.S.), GraphiSoft (Hungary), Nemetschek A.G. (Germany) and Olof Granlund Oy (Finland) have been certified as implementers of IAI’s IFC 1.5.1. Another group of 30-plus software firms, cooperating under the name BLIS headed by Microsoft, will soon be offering software containing IFC 2.0. Bentley Systems Inc.; Autodesk Inc.; Timberline Software Corp. and others are working on products compatible with IAI’s newest published industry foundation class, IFC2x.
As more commercial products become available, end users will be seeing the IAI logo on software serving the construction market.
Work on developing aecXML schemata continues on the IAI website (www.iai-na.com) with candidate schemata being posted for open discussion. A primary issue for business users of aecXML schemata will be the adoption of common object schemata (COS), which provide standardized building blocks for the creation of new business-to-business XML applications.
IAI has entered into a major contract with technical experts in Germany and England to extrapolate XML schemata from the IFC2x model to greatly expand the COS for commercial use. Any member of the design construction industry who is interested in participating in IFC or COS schema development is encouraged to contact IAI. Once aecXML schemata are officially adopted, they will display a logo that will assert that the schemata comply with the aecXML standards and will perform with other self-certified compliant software.
Success in developing true interoperability depends more on the leaders in the construction, design, engineering and consuming industries—such as building owners, DOTs and government agencies—than it does on software developers. The market follows demand. When customers demand interoperability and are willing to help define the standards, the software industry will follow.
