Revit, It is all about relationships
It shouldn’t have been surprising, really. However, at the end of the Summer 2011 Revit class, the feedback from students was overwhelming on the nature of collaboration – between students, teammates, and members of the building profession. What surprised me was that this wasn’t an explicit goal for the course, but a natural consensus among the students, presumably facilitated by the fundamental (and unavoidable) nature of BIM. Building Information Modeling (known as BIM) is catalyzing a dramatic leap in the way the building profession designs, documents, and constructs buildings – where in theory, all players work collaboratively on the same model, contributing layers of imbedded information, and ultimately share the risk and reward of the final product.
The parametric nature of the software is built around relationships, from the algorithms calculating behind the scenes, to the aptly named core components – called “families”. In lieu of drawing in the traditional sense, you assemble (as you would construct) objects with encoded behavior defined by parameters. Unlike other software, you can’t fake what the geometry represents, because the model is built on linked relationships of unique design intent (a door is fundamentally different than a wall. These relationships are defined through a series of dynamic references – as the design changes, the model updates to maintain the original intent. This results in a frontloaded design process, followed by lots of information management – i.e. cleanup. Revit wants to know answers – thus the user has the option to embed intelligence (or stupidity) into the model as well as the choice to design from the kit of pre-made elements or to fully customize the design. The drawing (still a dominate mode of communication) is simply an artifact of model – created by extracting controlled information at different scales.
The students had a taste of the benefits and woes of this fundamental shift, working in teams on their class projects, while simultaneously hearing from real world professionals about the issues at hand – providing a context for the software they were learning. For many, this was their first venture into professional practice, or their first collaboration on a design project, but it certainly won’t be their last.
I wholly endorse a context-based approach for learning software. Students are sophisticated consumers of technology, adapting to a rapidly evolving world of communication and self-expression. Learning software has become simply a matter of technological literacy – where fluency is often achieved through immersion rather than vocabulary alone. The vocabulary in this case, is the “picks and clicks” – an understanding of the tools. However due to the very nature of collaboration on a single model from design through construction, and beyond – it is imperative to gain an appreciation of not only what the tools can do, but their relationships to other players, and their implications downstream for the project at large.
As with any technological leap – now more than ever – is the mandate of the role of the academy to train further generations, while holding on to the essential elements of architectural education. At the core of this debate is the very relationship of the Architect to the future of the building profession: one as facilitator, tastemaker, collaborator, or master builder…? Regardless of the Architect’s role, the ability to trouble-shoot, design, and improvise within the technology gives one the agility necessary to be prepared not only for the next inevitable version, but the next big innovation yet to come. Learning Revit (or BIM of any sort) is not simply about 3D parametric modeling, but how to collaborate with others toward a common vision and extract useful and elegant information from the model to ultimately communicate ideas effectively – an ideal that hasn’t really changed, after all.
Below are examples of the work of some of the students: