Laiserin's Lemma—Ad BIMinem Argument
(lemma: a short theorem used in proving a larger theorem)
Jerry Laiserin

In rhetoric, an ad hominem argument is a statement that crosses the line from "Your point is stupid" to "You are stupid." In our ongoing dialog about the future of AEC design/documentation software, I've been pushing for Building Information Modeling or BIM as the best label for the superset/successor of CAD. Lots of folks, including the major AEC design software vendors, agree with both the concept and the name. However, there are other folks who seem to agree with the underlying concept but still want to attack the name—sort of an ad BIMinem argument. Everyone's entitled to personal choice in nomenclature (just as some people cling to "CAAD" or "CADD"), but industry-wide communication usually is best served by industry-wide terminology.

Both Volker Mueller and Ken Jensen, in this month's LLLetters, veer close to the ad BIMinem argument. Although I may not have articulated the point as clearly as I should have, I meant to be inclusive in my evangelizing for BIM. Volker's "my CAD, your BIM" approach and Ken's "AIM over BIM" approach remind me of a conversation with a friend who teaches philosophy at one of the USA's leading Jesuit universities; somehow our conversation got around to consideration of two kinds of people in the world—those who divide people into two kinds and those who don't . My intent with BIM was to unify, not divide. The asynchronicity and emotional tone-deafness of serial correspondence on line can easily lead, as it has here, to semantic differences that are more apparent than real.

First, as noted elsewhere in this issue, I'm inclined to agree with the positioning of BIM as a superset of CAD. In other words, one might reasonably expect that whatever design and documentation could be done in or with a given CAD tool can also be done in its corresponding BIM superset or successor tool. Conversely, this also implies that any design/documentation functions—especially on the front end—that are ill-served or under-served by a given CAD tool are unlikely to be any better served in the superset/successor BIM tool.

Next, we need to be more precise in our use of the term "design phase." In the previous round of this dialog, Volker referred to designers using "6B pencils and markers on bumwad... torn and sticky-taped paper for 3D sketches... clay models... ink drawings and laser cut acrylic maquettes." From an architect's point of view, this is the "design phase"—specifically, schematic design. Among my consulting clients, those design principals who use computers insist on using software tools that support the schematic design process even though most such front-end tools do indeed require what Volker rightly characterizes as "additional steps of painful data migration, data amendment, or data reconstruction" to move schematic design ideas into the firm's design development and construction document production tools. The reason, so these designers tell me, is that as many as nine out of ten schematic designs never advance to design development—better to suffer the inconvenience of "redrawing" one in ten than to cripple all ten designs by using tools better suited to working drawing production.

From the building lifecycle perspective, the term "design phase" applies to everything that architects and engineers do before releasing documents for bidding and construction. Only 15%-20% (on a fee basis) of the total project "design phase" is what A/E's would call schematic design. All of A/E design may account for only 5% of construction cost, which may be only half of total first cost, which is itself a small fraction of total lifecycle cost. Do the math: the front-end design work that is not supported by current CAD (and, by extension, future BIM) accounts for as little as US$100 (maybe less) of each US$1-million of total lifecycle cost. Conservative estimates of BIM benefits run in the 1%-10% range of total lifecycle costs—or US$10,000 to US$100,000 per US$1-million of lifecycle cost.

Unquestionably, most of the human, social and environmental value of each US$1-million in lifecycle cost flows from that initial $100 of schematic design input. No one is suggesting we sacrifice that, just as no one can afford to ignore potential BIM benefits that are several orders of magnitude greater than design costs. My point is that the CAD we've known rarely if ever supported schematic design, and it is off point to expect the BIM superset/successor to CAD to be any better in this regard. From a building lifecycle cost/benefit perspective it is essentially immaterial how many incompatible software formats designers use and discard in schematic design (just as it's immaterial whether schematics are modeled in chipboard, foamcore and plasticene or in formZ, VIZ4 and Piranesi).

I strongly encourage both: BIM for the total building lifecycle, starting with the earliest feasible phase within the A/E design process; and new or improved front-end tools for the schematic design explorations that CAD/BIM don't/won't support. If multiple vendors create diverse front-end and back-end tools (as we have now), that's fine with me. If one software vendor wants to work on both problems in some internally compatible way, so much the better. If some outfit can deliver that one magical, mythical tool capable of capturing without disruption the most unstructured design doodlings and propagating them through a database system tight enough and robust enough to model and manage a regional medical center or international airport for forty years, please tell me where to sign up. However, regardless of the name-label-acronym attached to any class of tool, I'm not going to discourage any vendor from pursuing any reasonable and responsible strategy that adds more intelligence and value at any stage of the building lifecycle.

Ken Jensen's arguments for Architectural Information Modeling (AIM) over BIM plow much the same ground as does Volker Mueller, albeit from a slightly different angle. Ken also lusts after the magical, mythical, end-to-end design modeling and data modeling tool, with special emphasis on enabling "the architects and the design team to focus on the future architecture that they are collaboratively creating." Certainly, we need better tools to capture and communicate design intent. BIM tools (or AIM tools, as Ken would have it) needn't be any worse in this regard than current CAD; BIM, with its inherent coordination of all 2D views of a multi-D model, likely is superior to current CAD for documenting/communicating from the design development phase onward.

However, Ken embeds his argument for AIM in the context of architectural licensure—"...not all buildings are designed by architects... [but] buildings are the only type of structures that architects are licensed to design..." While true, at least in USA practice, this context is a troubling one. I have argued since the first commercial wave of AEC-capable CAD tools that computerized building design information opens up previously unimagined realms of danger and opportunity for architects. As an architect myself, I welcome the opportunity to assert more control and capture more value in the building lifecycle through our digital mastery of the building information that starts in our offices and those of our engineers and consultants. The danger is that others in the process will turn their digital mastery of the same information against us if we fail to match their technological ambitions.

I still prefer "BIM" as the name for the overarching, end-to-end building information lifecycle modeling and management tool. Maybe Ken Jensen's "AIM" should be the new name for what Volker Mueller wishes CAD would become. Others with sentimental attachments to their historical slice of the building lifecycle could call their corresponding slice of BIM by their favorite names. For example, contractors could justify construction information modeling, or CIM, on the grounds that they have state-issued contracting licenses that allow them to do things that A/E's and owner-operators cannot. The owner-operators, in turn, might opt for FIM, or facility information modeling, and so on. Of course, AIM, CIM, FIM and others yet unimagined (ad-infinitIM?) all describe the same building, so presumably contain the same information handed from the A/E to the GC to the FM. But, um, isn't that exactly where we started this entire BIM discussion?

Special thanks to Ken Jensen, Volker Mueller and all the other contributors to this dialog to date. I know there are thousands more reading and following these vollies, so let me know what you think.

Editor and Publisher, The LaiserinLetter
Analysis, Strategy and Opinion for Technology Leaders in Design Business

< back