Summary of the BIM Symposium at the University of Minnesota

There was a time when a person who missed a symposium was out of luck. He could ask for first hand accounts of what was said, or if the discussion was broadly appealing, a book might come of the papers delivered to profit from the endeavor and document who was on that cutting edge. In yet another way the web is changing the dissemination of information, the symposiums that don't get books may still enjoy a healthy afterlife. The work Lachmi Khemaini has done at AECbytes to document the recent BIM symposium at the University of Minnesota is an excellent example of this.

Not only is the article a great primer for professionals or offices considering BIM implementation for their own work, but also the document is the first in a while to raise pedagogical concerns for the new technology. By just dedicating ten minutes to this piece and skimming the 2004 AB roundtable about architectural technologies, one can get a healthly overview of the genuine paradigm shift occurring with architecture's "deliverables." (The kind of paradigm shift Thomas Kuhn wrote about in The Structure of Scientific Revolution, not the abused term so many snake-oil salesmen are quick to use.) From the "Panel Discussion and Conclusions" section of Mr. Khemaini's article...

"It was generally agreed that BIM is going to bring about many changes in the architectural profession. It calls for new learning, the application of new processes, the development of new workflows, and better knowledge of other building disciplines. The position of draftsperson will certainly be eliminated. What is not clear is if it will be replaced by a new "modeler" position with the same disconnect between designer and modeler as there currently is between the draftsperson and the designer. This also relates to the question of how to best educate students for a professional future in which BIM will play an important role. How much of BIM should be taught in schools? Even with CAD, there was always the fear of "students getting lost in the computer," which made many studio instructors prohibit their students from using CAD on projects. Will this be the same with BIM? Or is BIM so fundamentally different from CAD that it could prove of tremendous value in core architectural education, in helping students understand how a building goes together?"

... and from the AB roundtable in the November / December 2004 issue intitled "Blur"...

[Phillip Bernstein] Nicholas Negroponte — the founder of the MIT Media Lab — talks about the phases of technology adoption. In the initial phase, you use the technology to replicate the ways you’ve always done things — so for architects, it’s the replacement of hand drafting. Then there’s the intermediate step of integration, where the relationship gets changed. And then ultimately the technology enables a way of pproaching the problem that’s fundamentally different. Technology is an underlayment that creates a degree of fluidity that didn’t exist before. And that fluidity combines with some other external factors that have to do with widespread dissatisfaction with the way current processes work. The reason your clients today say, “We don’t care what your role is” is that they are desperate for a good idea; they don’t care about the source. In many ways, the disintegration of old processes and old structures has to happen before things re-form into new, clear approaches.

[Mikyoung Kim] Technology is also an enabler for this kind of collaborative dialogue.When you can send a drawing back and forth so quickly between all the different parties, it allows a dialogue through the drawing that didn’t happen with hand drawings.

[Phillip Bernstein] And with certain kinds of technologies, you don’t just send a drawing any more. You can send insight. It’s not like a better fax machine — it’s something more. You can transmit intent and relationships and other kinds of metadata that create a whole different dynamic around the design process. What we haven’t yet developed are clear business processes that respond to what this means. For example, the owner says, “Why don’t you just do this and send this thing over to this other guy?” and the architect says, “Well, I didn’t get paid to make the data. I’m not going to take the risk of sending the data over there.”

[Jeffrey Inaba] It strikes me that “metadata” and “data” seem now to be the same thing, in the sense that meta-information, like intention or insight, is as much a part of the scope of architectural work as, say, dimensions on a drawing. We are responsible for having both the intention and insight in hand, as well as very specific descriptive bits of information.

[Phillip Bernstein] There’s still a useful distinction between “data” and “metadata.” Data is the information that’s transacted as part of traditional processes. You send me a drawing; I send you data that indicates the boundary of your landscape work. But the metadata is the stuff that, at least in traditional transactions, rides on top — non-graphic stuff like area calculations, quantities, or key relationships between components. It’s now possible to communicate both kinds of information. But unfortunately, there are no well-understood protocols for how to do all this.