Looking Beyond BIM to Business Information:
The Role of agcXML in Streamlining Information Exchange

Michael Tardif, Assoc. AIA, CSI, LEED AP
Director of Integrated Project Delivery Systems, Grunley Construction Company, Inc.

The primary focus of our attention in the AEC industry with respect to technology is building information modeling (BIM). But dramatically improving productivity and efficiency in the building industry will not be achieved through BIM alone. We need to look beyond the building-specific and project-specific information that can be compiled in a BIM model to the entire information flow, workflow, and business processes needed to create and sustain the built environment. We need to view our individual work efforts as part of a complete system. We need to view the information that we receive, create, and transmit to others as part of a continuous supply chain.

The product of any individual task is the “raw material” of any subsequent task. But all too often, we pay no attention to the downstream impact of our work products. As a result, electronic information in the building industry is recreated—again and again and again—in a repetitive process that adds no value to any project, and that actually diminishes the integrity and value of the information exchanged by introducing opportunities for error at every stage.

Most of the information we exchange in the building industry is alphanumeric, not geometrical. In a comprehensive building information model, a building’s geometry may be the most challenging data to express, but it is the alphanumeric data about the building—words and numbers—that make up 90-95 percent of the total body of information in a comprehensive model. The geometry is useful, but after construction is complete it is the alphanumeric data that is arguably the most valuable for facility management, asset management, operations, and maintenance purposes.

Beyond the model, there is a great deal of transactional information that is created during the design and construction process that is vital to those processes but that may or may not be appropriate to include in a BIM. Some of this information may be created and used in a BIM application, but most of it is created and used by other types of business applications such as contract document, project management, accounting, scheduling, and construction cost estimating software. It is this mission-critical but heretofore entirely neglected body of information that agcXML was designed to address.

Let’s consider one example: an Owner/Contractor Agreement. At first glance, it would seem that the “vital information” contained in such a document would consist of little more than the names of the parties and the contract sum. But when the agcXML technical team systematically compared ten different standard owner/contractor agreement forms, they identified a total of 184 individual data fields, or pieces of information, that might be entered into an owner/contractor agreement form. The team also found that those 184 data fields easily could be organized into the following 13 data categories:

• Agreement Date
• Owner Information
• Contractor Information
• Project Information
• Prime Design Professional Information
• Project Milestone Dates
• Liquidated Damage or Bonus Provisions
• Compensation Provisions
• Payment Provisions
• Insurance, Bond, & Indemnity Provisions
• Other Provisions
• Contract Documents
• Exhibits

Examining just one of these categories—owner information—the agcXML team identified 22 unique pieces of information that needed to be distinguished from one another:

• Owner Company Name
• Owner Project Number
• Owner Address 1
• Owner Address 2
• Owner City
• Owner State
• Owner Country
• Owner Company Phone
• Owner Company Fax
• Owner Representative Last Name
• Owner Representative First Name
• Owner Representative Phone
• Owner Representative Fax
• Owner Representative e-mail Address
• Owner Signature
• Owner Signatory Last Name
• Owner Signatory First Name
• Owner Signatory Title
• Owner Signature Witness Signature
• Owner Signature Witness Signatory Last Name
• Owner Signature Witness Signatory First Name
• Owner Signature Witness Signatory Title

Each of the other twelve categories has a similar list of unique pieces of information. For a typical project, all of this information is created or compiled for the first time when the owner/contractor agreement is prepared. But virtually all of that information will later be needed for “downstream” business processes or documents, such as schedules of values, RFIs, submittals, purchase orders, change orders, applications for payment, invoices, bond and insurance forms, and many, many others. The data will be entered into a plethora of software applications by every party involved in the project, including but not necessarily limited to the Owner, the Architect, every consulting engineer, the Contractor, the Surety, and every trade and specialty contractor. The software applications in which this alphanumeric data may be needed include accounting, bidding, BIM, customer relationship management (CRM), construction cost estimating, enterprise resource management (ERP), project management, project information management (PIM), purchasing, scheduling, and many others. One can just hear the sound of keyboards clacking away as every party to a project mobilizes by entering the same data over and over again into dozens of applications, duplicating the work of every other party and making mistakes or entering incomplete information at every stage.

What a waste! There is no value to any of that repetitive effort. In addition to viewing our individual work as part of a system and our work products as part of complete supply chain, we need to borrow the concept of “data normalization” from the software industry, which is nothing more than deciding that each piece of information will have a single authoritative source, and that all other instances of that piece of information will be retrieved from that source. But if we decide, for example, that the “authoritative source” for company contact information is our CRM system, than we need to be able to exchange information reliably between our CRM system and all other software applications.

Solving that problem is tedious, but it is neither difficult nor expensive. Business software applications can exchange alphanumeric data far more easily than BIM or CAD applications can exchange building geometry. All we have to do is agree on the data set of information we are going to exchange, and what each “data field” will be called. Each of those data fields, such as “Owner Company Name” has to be unique, so that it is not confused with similar information, such as “Prime Designer Company Name.”

The tool for facilitating this information exchange already exists: it’s called XML, or eXtensible Markup Language. XML is a system of data tags that allows software applications and information systems to intelligently recognize both the type of data in a data field as well as its specific value. When you enter information into an online form on the Web, you are using XML, even if you are unaware of it. Each data field on the Web form has an XML tag, so that, for example, your telephone number is clearly distinguished from your zip code. This is known as “structured data,” and it allows software applications to intelligently search, sort, and exchange data in a way that is useful. It allows online vendors to retrieve the information you enter into an online form and transfer it directly into their proprietary relational database systems.

For this to work, software companies need to collaborate to support the same set of XML tags, known as a schema. Whenever you use the Google “auto fill” feature to complete an online form and the data goes into the wrong data field, it is because Google’s XML schema and the vendor’s XML schema don’t match.

Though XML was originally designed specifically for the Web to support eCommerce, it has proven extremely useful for any kind of data exchange, whether it is Web-based or not. An added benefit of XML is that software vendors can support reliable information exchange without sharing or revealing their proprietary software code or proprietary data formats.

The Associated General Contractors of America (AGC), recognizing the need for a standard to support the exchange of business information during design and construction, underwrote the cost and led the effort to develop a set of schemas for this transactional information. ACG contracted with the National Institute of Building Sciences (NIBS) to develop the schemas, known collectively as agcXML, in an industry-wide consensus-based process under the auspices of the buildingSMART alliance. The scope of the initial effort was limited to the following types of information exchanges or documents:

• Owner / Constructor agreements
• Schedules of Values
• Requests for Information
• Requests for Pricing/Proposals
• Supplemental Instructions
• Construction Change Directives
• Submittals
• Change Orders
• Applications for Payment
• Bonds

There are many other information exchanges to which agcXML easily could be extended, but this group was identified as the “low hanging fruit” for the first version of agcXML, which was completed and made publicly available in early 2009. A key aspect of agcXML is that it is freely licensed in perpetuity to any software developer that wishes to include support for agcXML in any of their software products. Conceptually, any data entered into any software application that supports agcXML could be exported to any other software application that also supports agcXML, which would allow us to “normalize” a great deal of our project data, both internally in our own organizations as well as with our project team members.

Since agcXML was released earlier this year, four software companies have announced support for agcXML, and two – VICO Software and Newforma – have announced that agcXML is their platform of choice for an intensive information exchange and product integration strategy. This is especially significant because agcXML was specifically designed for this “use case”—the reliable exchange of business information between two dissimilar software applications. Newforma Project Center is a project information management (PIM) solution, while VICO is a “BIM for construction” company that offers a suite of tools for coordination, quantity takeoff, cost estimating, project scheduling, and production control. Both companies, however, recognized that their applications, while used for very different purposes, create and store similar data sets of information. With agcXML, they can serve their customers better by eliminating the need to repetitively enter the same information into each application. Because agcXML is a public data specification, end users will be able to validate the content of any data exchange, a vital attribute of interoperability.

Other software companies should follow Newforma and VICO’s lead. End users can help by creating market demand. You don’t need to know anything about the technical aspects of agcXML to build the buzz. All you need to do is ask (er, demand) that your software vendors provide support for agcXML in their software applications. It’s very easy for software companies to do, requires relatively little software development effort, and has enormous potential benefit for the building industry. After all, it’s your data, and after you’ve entered it into a software application once, you shouldn’t have to enter it ever again.

About the Author

Michael Tardif is Director of Integrated Project Delivery Systems for Grunley Construction Company, Inc., in Rockville, Maryland, where he develops and implements Grunley’s advanced technology initiatives. Previously, he served as the Project Manager (under contract to the National Institute of Building Sciences) of the agcXML Project. He can be reached at michaeltardif@grunley.com

Note: The views expressed in Viewpoint articles are those of the individual authors and do not necessarily reflect those of AECbytes. Also, AECbytes content should not be reproduced on any other website, blog, print publication, or newsletter without permission.

Viewpoints > Issue #49 > Printer-friendly format