Feedback about our recent pronouncements on Building Information Modeling (BIM) versus CAD—"Comparing Pommes and Naranjas"— continues unabated. Dr. Paul Teicholz, P.E., professor emeritus of Civil Engineering at Stanford University and founding director of Stanford's Center for Integrated Facility Engineering (CIFE), writes:
> "The main reason why CAD should be replaced by BIM is that the model created during the design phase can be used for much more than design; it is the starting point for all the processes that use information about the building (or other type of facility) and this is the most important value-added capability of [the] BIM over CAD. It avoids the need for multiple models at each step of the process and by collaborating members in the design/construct team and then, most significantly, the owner for managing the facility. Thus, the move from CAD to BIM is driven by economic advantages that go far beyond any advantages to software vendors, market movers, etc. I think that Jerry is absolutely right to make this suggestion for change and that it goes to the heart of his message."

> I'm not one to demur when an intellect the caliber of Paul Teicholz's declares me to be "absolutely right" . That said, Paul's point exposes one of the major obstacles that has impeded and continues to impede industry-wide adoption of BIM: "The main reason... is that the model created during the design phase can be used for much more than design." In other words, the benefits of BIM flow primarily downstream from the design phase of the facility lifecycle—to "collaborating members in the design/construct team" as well as to the owner. However, outside of design-build and design-build-operate projects, none of the downstream beneficiaries of BIM have yet to offer to upstream design professionals any additional compensation for their BIM adoption/implementation costs (tools, standards, process change and so on). Until the players devise a system for equitably reallocating and realigning the benefits and costs, BIM will remain the province of a small group of hard-core technophiliac design professionals. In my view, designers can continue to wait and hope for crumbs from the contractors' and owners' tables, or designers can proactively assert and capture the project lifecycle value inherent in their BIM output.

Volker Mueller, Design Technology Manager with NBBJ in Columbus, OH, offers a contrasting view:
> "Very interesting column about foreign names for fruit and an interesting exchange with Martyn Day you had. I agree with Martyn—if I interpret his responses correctly—that BIM tries to solve a self-created and moot discussion about apples and oranges in whichever language. Furthermore and dangerously so it helps CAD software developers to avoid the question where those fruit do come from in the first place.

"In my experience and opinion, with BIM as "Building Information Modeling," software vendors continue to miss the most important and almost oldest question implied in the term Computer Aided Design. While the applications of the CAD software vendors (or are they now BIM software vendors?) may upon time very well succeed in supporting the activity of modeling some known building information, the core problem of architectural and engineering design is to generate building information that we do not know, yet. Design often follows a complex idiosyncratic creative process whose results can vary widely even if based on the exact same input. Submissions to design competitions may illustrate this point. A computer aided design software would need to be able to support such processes. As a user advocate in the court of CAD software developers and as an activist for the architectural design profession I claim that the switch to Building Information Modeling and any three word predecessors replacing CAD may simply point to the admission that what they have been selling us as CAD software is incapable of supporting design processes. With that perspective... BIM is to CAD [in computing] as using laser cut acrylic [in design] to build a physical scale model is to using 6B pencils and markers on bumwad and torn and sticky-taped paper for 3D sketches and clay models and ink drawings and laser cut acrylic maquettes. You get the picture. Put differently: BIM may be an activity better at home within CAFM [Computer-Aided Facility Management—JL] rather than CAD.

"With poignancy and levity: to the biggest and oldest unanswered question of Computer Aided Design, BIM is an evasive action, and BAM, there you have it, quite simply a BUMmer."

> Volker's "BIM, BAM, BUMmer" is reminiscent of the original title of Martyn Day's letter—"BIM, BAM, BONG"—with its wryly hinted question regarding what I might have been smoking when I argued for replacing CAD with BIM. Most of the commentary I've received in opposition (to adopting BIM as the operative term going forward) falls along this Day/Mueller axis: software vendors have failed to deliver on the much-ballyhooed "D" for "Design" in C-A-D and therefor should not be allowed to add any further value to the processes of documenting and communicating design intent unless and until they fix their deficiencies in design.

> I would argue exactly the opposite: today's AEC CAD tools—despite the "D"—make no serious effort toward or pretense about supporting design in the open-ended, exploratory way that Volker describes, and these tools and vendors have not done so for a long time (if they ever did). Most users are well aware of this and have long since sought their "design" solutions elsewhere—in modeling, rendering and visualization tools such as formZ and Autodesk VIZ, and in traditionally non-AEC solutions such as Maya from Alias|Wavefront, Rhino from Robert McNeel and CATIA from Dassault Systemes. Because even the best among such design-oriented software tools still impose creative constraints and may interpose discontinuities in document production workflow, many designers cling to their cherished "6B pencils and markers on bumwad... torn and sticky-taped paper for 3D sketches... clay models... ink drawings" and so on.

> The recent introduction to the market of newfangled design-capable tools such as SketchUp and Autodesk Architectural Studio also points away from "CAD." If anything, these approaches are closer in spirit to the original (1960s) ideal of "DAC"—Design Automated by Computer*. I suspect it may be a vain hope to expect that any one tool will provide continuous design and documentation workflow from earliest schematic sketches to facility operations and maintenance. Furthermore, if such end-to-end continuity is not a vain hope, I believe it is more likely to come about through the addition of front-end flexibility to BIM-like tools than it will through today's CAD tools suddenly becoming able to carry design information downstream.

John Mullan, an architect in the UK, comments:
> "I was very interested to read your account of the genealogy of CAD modelling (IssueSixteen, "Some other Brics in the Wall"). Our first foray into CAD was with Sonata in 1991—our single workstation cost around $60,000, we trained three people to use it and worked in shifts to try and cover the costs. Great for modelling hotels—but its undoing was a lack of compatibility with DWG and no flexibility to take shortcuts (i.e., cheat the model). I confess that when we switched to AutoCAD four years later, I hadn't the heart to learn such a primitive system. But unlike Sonata, it did spread across the office and drive out our last drawing board within three years. Now we've moved to Autodesk Revit, and it's the first package I've found to reawaken my interest. Whether it will prove so easy and fast that users are prepared to really build the model and stick with it remains to be seen."

As a postscript, John adds:
> "Martyn Day's comments suggest to me that we should drop CAD, AEC, BIM etc. and just use the acronym TLA ["three letter acronym"—JL]—at least until there is enough commonality to warrant a genuine universal tag."

> John makes a telling observation: that previous tides of what we now call BIM have ebbed and flowed while the constant undertow of general-purpose documentation systems such as AutoCAD pull the industry along. While Autodesk Revit may not contain genomic snippets of Reflex code, Revit clearly is spiritual heir to a lineage of BIM "begats"—RUCAPS begat Sonata, Sonata begat Reflex, and Reflex begat Revit. Vendors appear to become (re-)enamored of BIM-like tools on a roughly six or seven-year cycle; as with each previous cycle, it is now up to the user community to decide whether this go 'round is the time to switch away from CAD (Auto- and otherwise) and to a solution such as Revit or the BIM offerings of competitors such as Bentley Systems, Graphisoft and others. We will explore these questions further in future LLetters.
JL

*NOTE: In my earlier retelling (in IssueSixteen), I foolishly relied on an uncorroborated secondary source and mislabeled "DAC" as "Design Augmented by Computer," instead of the historically correct "Design Automated by Computer." Although industry usage subsequently reversed the acronym 180 degrees to CAD, "DAC" has a noble history in industrial/mechanical design world. One of the developers of the mid-1960s DAC-1 system at car builder General Motors was Dr. Patrick Hanratty, who went on to found MCS, a company whose core technologies are widely credited with underpinning some 70% of today's 3D MCAD software tools.

< back