by Jerry Laiserin, AIA

Within the past decade, computer software has successfully applied cost-and-time formulas to manufactured products. This business-oriented approach is fine for factory-made widgets, but buildings are one-of-a-kind creations, pieced together in the field under varying conditions and from many thousands of parts and raw materials. Letting time and budget drive project delivery means ignoring these variables-and the many opportunities that come with them.

The architecture, engineering, and construction (AEC) industry has its own set of software vendors who understand the complexities of the process and are finding ways to connect all the elements of a project. Doing this successfully, however, means that AEC vendors must find a method to integrate the data contained in the different building models that each discipline develops. Allowing engineering software to communicate with the programs used by electricians, interior designers, and, of course, architects, would streamline the construction process. But making these links is not so easy.

What is computer modeling?
From basic CAD to the most sophisticated construction scheduling system, all software must achieve one basic goal: to form a bridge between mathematical coding-the language that computers read-and the characters and pictures that humans can see and understand. When software developers translate descriptions of the real world into mathematical code, they call that process "modeling." The use of this term by computer scientists confuses architects, who are accustomed to thinking of models as chipboard and foam-core replicas.

Basic CAD software that produces 2-D drawings is actually a model of the drafting process. Advanced 3-D CAD software creates what some vendors call a "virtual building." To the extent that such virtual buildings include mathematical descriptions of a building's geometry and parts, they do correspond to the physical scale models with which architects are familiar. Computer models of buildings, however, also can include the attributes of a building's components, like the density of the concrete or the fire rating of the partitions.

Other kinds of design and construction software also rely on models, or representations of real-world objects. Specifications software, for example, defines the composition and quality of the parts of a building and often includes descriptions of how to assemble those parts. Estimating software uses mathematical models of the relationships among materials, sizes, quantities, and unit prices. Scheduling software combines representations of material, equipment, and labor resources into time-based models that represent the sequence of design and construction events.

These diverse software models of the same building should, ideally, be capable of communicating freely with each other. But, in most cases, they don't.

Instead, software packages differ at many levels, including how they name, subdivide, and classify building parts; the ways they organize the attributes of those parts; and their methods for linking parts and attributes. They also differ in the techniques they use to represent parts and attributes. The consequences of all this variation include lost or duplicated information, inaccurately transferred or converted files, and multiple databases of redundant information (the digital equivalent of two partners' Rolodexes containing different phone numbers for the same client). Plus, much time and effort are wasted in checking these possible sources of error.

Everyone would benefit if these communication problems were eliminated. Architects and engineers could incorporate better cost and schedule information into early design stages, sparing themselves some of the agonies of redesign. Those involved in the construction phase would enjoy faster project documentation and smoother workflow. Building owners and operators would benefit from more predictable time and cost estimates and would get a useful set of "as-builts," along with other project information, when the job is done.

Building connections
Given the potential benefits, it's surprising that so little has been accomplished in linking design information software to costs and schedules-though it is not for lack of trying. Just about every building-product trade association has a classification scheme. In the U.S., most classifications fit within the Construction Specification Institute's Masterformat or the ASTM standard Uniformat II (for classifying assemblies like slabs or interior partitions). Other countries, including Germany, Japan, and Brazil, have their own classification systems, as well.

AEC software vendors have not, as yet, been able to build on these systems. Traditional data-linking tools, like file-conversion programs, are not general enough for the multiple linkages that software vendors want.

As an interim measure, vendors of some of the most widely used software have attempted to forge direct links to one another. Some of these links rely on common file conversions or translations. Others rely on an application programming interface-one vendor publishes a set of software "hooks" to which other vendors write special connection routines that move data between the two packages. But these are still program-specific links that are only valid between specific applications.

Dr. Martin Fischer and his colleagues and students at Stanford University's Center for Integrated Facility Engineering (CIFE) are pioneers in finding ways to link disparate software programs. Fischer has found ways to make multiple off-the-shelf software packages communicate using an actual design and construction project-a biopharmaceutical manufacturing facility in Menlo Park, Calif., designed by Flad & Associates, based in Madison, Wis.

Fischer's group linked the building model, created in AutoCAD Release 14 and the ArchT architectural CAD add-on package (now distributed by EaglePoint), to Timberline Precision Estimating software. This eliminated many time-consuming manual steps in quantity take-offs and definition of work packages. A construction schedule from Microsoft Project was linked to the AutoCAD/ArchT model through Jacobus Technology's Schedule Simulator to build a virtual version of the building and identify the most expeditious construction staging. This yielded an informative kind of 4-D CAD (3-D plus time).

The general contractor reported that the cost estimates that were produced came within 5 percent of those prepared by manual methods, but were completed 25 to 50 percent faster. The schedules that the CIFE demonstration generated uncovered conflicts that might not have been detected otherwise. While Fischer's work [see Digital Architect, August 1999, page 39] provides insight into the interplay of multiple software packages on a real project, it is still based on semicustom interfaces among compatible programs.

Joining forces
Several groups, including CIFE, are now working on comprehensive systems that allow any design or construction software to operate compatibly. The best known of these groups is the International Alliance for Interoperability (IAI), launched in 1995 by software vendors, building owners, and design and construction firms. IAI is developing industry foundation classes (IFCs) that standardize software objects that correspond to the physical objects in actual buildings, such as wall assemblies, doors, and windows. Because IFCs are backed by the descriptions and attributes of each building object that they represent, they can be accessed by any IAI member with IFCs incorporated into their software.

But until IFCs are more widespread, many software developers offer their own proprietary pairings. For example, builder-oriented CAD programs like SoftPlan have complete bill-of-materials capabilities built in. Graphisoft's ArchiCAD has its own "object" language, complete with links to WinEstimator's WinEst estimating program. DATACAD LLC's eponymous CAD software now bundles the Estimator for Windows program from CMS Estimating. Specifications software vendor ARCOM (MasterSpec), scheduling software vendor Primavera Systems (Project Planner), and cost database provider R.S. Means (CostWorks) have announced plans to link to each other and to Bentley Systems' TriForma CAD software.

How the Web fits in
Any discussion of how disparate software programs will communicate must take into account the impact of the Web. An efficient tool for locating and viewing almost any kind of data, regardless of the software that created it, the Web may indeed make it easier for designers and other members of the AEC team to communicate.

The primary language of the Web is HyperText Markup Language (ASPL). A newer Web language called XML, or eXtensible Markup Language, has features that ASPL does not have, like the ability to describe and classify the data content-not just the appearance-of a Web page.

Dozens of companies, including AEC, will benefit from the data exchange possibilities XML offers. The McGraw-Hill Construction Information Group (which publishes Record), Primavera, and Bentley have joined with more than 130 other industry leaders worldwide to form the aecXML Project. The goal is to develop a framework for XML specific to the building and design industry.

The high percentage of overlap between aecXML advocates and IAI members means that the two will likely develop a supportive relationship-perhaps with aecXML serving as the Internet transporter for the IFCs. Regardless, emerging linkages among cost, time, and architecture will enable buildings in the near future to go up faster and more economically.

Return to DIGITAL ARCHITECT INDEX