Building Information Modeling (BIM) has fundamentally changed how buildings are designed. One may argue about the degree of productivity increase brought about by BIM, but it is beyond dispute that the previously unseen wealth of information provided by virtual building models has put designers in a completely different position with their design decisions, ultimately resulting in far better designed buildings. No designer is, however, alone in the design process—not even solo practitioners—so one may wonder if BIM brings added value to the design collaboration of the different disciplines as well.
In my previous article, “Thou Shalt Collaborate…: Interdisciplinary Collaboration Strategies in the Age of BIM,” I discussed the pros and cons of the various collaboration strategies offered by the different BIM vendors. My conclusion was that in a plural world, “open” collaboration strategies are in the best interest of all parties involved. In this article, I continue that thread by elaborating on the implementation questions of “open” design collaboration workflows. My aim is to explore how BIM can bring benefits of a similar scale to interdisciplinary design collaboration, by providing a new level of transparency and integration of design processes for building projects of any type or size.
In order to answer the question of how BIM can possibly improve interdisciplinary collaboration, we first need to understand the ultimate function of collaboration between the various trades. Some may say that for certain project types or sizes, collaboration with the other design disciplines basically ends with information providing so that the other party can complete their part of the job. Collaboration is considered in many cases more an obligation than real added value to the design process. Moreover, tools available thus far haven’t helped facilitate meaningful collaboration of the different disciplines either.
I believe that with the right information flow between the different disciplinary designers, collaboration will actually become a real “co-design” process. Imagine that with the right tools and workflows, the whole design process can be fully transparent for each party involved. It is like extending one’s sight with a new dimension—each discipline working in the context of the other disciplinary work in a much more information-rich environment for better design decisions. This may be nice in theory; however, in practice, it can only work if designers can continue using their long-standing design tools and processes without productivity loss in their core tasks.
The big question is how this seamless information flow between the design disciplines can be achieved. As I noted in my previous article, simple “binary” file compatibility is insufficient in most of the cases. The reason for this can be found in the fundamental differences in the requirements of the different disciplines. The example below in Figure 1 depicts a typical situation where the architect and the structural engineer need to work in parallel on the same structure, but that structure—a column in this case—has a totally different morphology and inner logic for each profession.
The architect needs to model the entire structure of this column, including the veneer and finishes next to the load-bearing core structure. In the “architectural” BIM, it is absolutely fine to model that column with one multi-story element since it will be constructed in a way that the column is poured together with the slab and will continue on the next story without a break. In the “structural” BIM, however, in addition to the elimination of all non-load-bearing elements, this column should actually be modeled as two columns, because in the analytical model the calculations need to be done that way.
We could cite countless similar examples including precast slabs, which are one single element for the architect but a whole system of load-bearing panels for the structural engineer. And this is not only about analysis—structural detailing is very different from architectural detailing as well. Another type of “gap” in the workflows is when architects and MEP engineers work on separate systems that need to be merged for coordination. Here, both parties’ software solutions need to be prepared for integrating each other’s designs. In the example shown in Figure 2 below, an MEP system is being coordinated with the load-bearing structure of the building for collision detection.
From the examples above, it is obvious that such conceptual differences cannot be bridged with simple file compatibility no matter how perfect the interface is. The real solution is to build dynamic round-trip collaboration workflows, where each component of the workflow is specifically prepared to fulfill the different workflow requirements. Let us explore such an “open” IFC-based collaboration workflow between the architect and the structural engineer by discussing the specific requirements for each component.
The design process of buildings usually starts with the architect creating the main design concept, which is then provided to the engineers. Next to sharing the full design “package” with engineers to provide context, engineers need to be delivered specific data that fulfill the following requirements:
The above requirements are not only for visual clarity but each has functional importance too; for instance, exporting only the load-bearing core of structures greatly helps to automatically map the geometries by their center reference line. Traditional methods such as sending the printed documentation or its digital equivalent, PDF files, are obviously not fulfilling any of the above requirements. Not even CAD files or “un-prepared” BIM models provide a full solution. Figure 3 shows an example of a properly “prepared” BIM model for the structural engineer that was created from the architectural model.
In this example, the architect could transform the architectural model into a special model best fit for collaboration with the structural engineers with the help of specific software tools, such as element filtering and classification based on functionality, position, and load-bearing status. The following steps were used, which required minimal extra effort from the architect:
With the help of such processes, the physical and functional characteristics and data-structure of the BIM model can be refined and adjusted to any collaboration workflow, regardless of the name or version of the software solution on the receiving end. In fact, this very step makes the proposed “open” workflow superior to any other connection, even native ones. Such flexibility is not only important for engineering collaboration but also for any BIM data exchange, including those with analysis and model checking solutions.
After providing the initial input for the engineers, the workflow continues with both disciplines elaborating their own version of the BIM model with regular synchronization of the model changes with each other. Due to the differences in the model requirements and also to help facilitate parallel work, the optimal solution is a “reference model” workflow. This is not a new process, but with additional technology to support version tracking and change management, the collaboration can become a truly seamless process between architects and engineers.
For example, Figure 4 shows such a model synchronization being enabled by implementation of IFC model change management. The IFC model received from the structural engineer contains new, modified, as well as deleted elements. The architect can review these elements one by one and can make decisions right in the BIM model context if the proposed changes should be accepted. If so, the architect also has the option to take over elements from the engineer’s “reference model” into the architectural model.
This kind of an intelligent workflow removes the burden of tedious, manual work from coordination, while the IFC link virtually extends real BIM collaboration even beyond the engineering world to many other building-related disciplines. The IFC 2x3 platform has been in use for over five years; all the major software vendors have solidified their 2x3 interfaces, making it the most robust BIM model exchange platform available today. Figure 5 shows some of the tested and proven workflows between a wide array of applications, all using the IFC 2x3 platform.
If you got this far with your reading, our topic probably has high relevance to your practice as well. Still, valid questions may arise whether the above-described workflows can offer enough benefit for all types and sizes of projects, or is it only worth the trouble with larger, more complex projects? Obviously, if a discipline is working solely in 2D and does not create a 3D BIM model for any purpose (design, documentation, quantity take-offs, analysis, etc.) then model-based collaboration with that discipline is out of the picture. At the same time, it is safe to state that the degree of benefit of model-based collaboration has little correlation with project type or size, similar to the implementation of BIM.
This question can be turned into several different ones:
If your answer is “Yes” to any of the above questions, then it is a good idea to consider the switch to BIM-based design workflows. For the most ROI, don’t stop at creating BIM models for your own immediate design and documentation purposes, but go for a holistic approach covering the entire design process, including interdisciplinary collaboration as well.
As I see it, BIM started 20+ years ago with the creation of the first virtual building models, and it has now evolved with design file sharing to provide parallel access to the same BIM model for teams of any size. The next imminent step in this BIM evolution is the ability to integrate design disciplines for the full range of projects. This article has attempted to analyze the challenges and present potential solutions to the integration problem. Since the world is moving towards distributed “open” solutions—just witness the evolution of the Internet—BIM should be moving in this direction as well. If you try and implement the above proposed “open” workflows, you would be taking the first step in this direction.
BIM is now a complete platform made accessible for teams of any size or composition. With regard to the future evolution of BIM, I see two main directions. The first is related to the core functionality of BIM—I see great potential for the continued development of BIM solutions both in terms of richness of forms and the level of intelligence of the models. The second direction is related to the overall development of information technology, where I envision BIM scaling much better to take advantage of the increasing number of processors and size of available physical memory on a computer. In addition, I am quite positive that certain functions of BIM will be available through Web interfaces sooner than many think.
Viktor Várkonyi is the CEO of Graphisoft. He is a seasoned industry professional who has spent almost two decades on the design of workflow solutions for ArchiCAD, a leading BIM solution for architects.
For questions or comments related to this article, you can write to Viktor at: vvarkonyi@graphisoft.com.
AECbytes content should not be reproduced on any other website, blog, print publication, or newsletter without permission.
