Integrated Project Delivery (IPD), a recent initiative in the building industry, is a de-facto call to action for collaboration. However, collaboration is not new to the building industry, or even to humanity—being capable of effective collaboration is one of the foundation stones of human society. Arguably, the largest collaborative effort of mankind was building the Great Pyramids in ancient Egypt, and since then, the building industry has not stopped to exemplify great collaborative projects as illustrated by the skyscrapers of the modern age.
Yet, design collaboration is a relatively new phenomenon to the building industry. To achieve the best outcome and utilization of a building, architects and engineers have to work together. But as buildings become increasingly more complex, so do these design professionals become increasingly specialized; and the reality is that while these design disciplines work on the same building, they are using their own sets of tools and practices. Therefore, it is no surprise that design collaboration is riddled with communication and coordination issues.
In this article, I aim to discuss the different strategies software vendors pursue to provide design collaboration solutions for their customers. I will also cover some of the most important issues that I believe we should find the answer to.
First, in the flat CAD era, collaboration of the different disciplines was limited to the lowest common denominator: 2D information exchanged through DWG files. This simple workflow merely replaced what went before: exchanging paper drawings to “show” the design intent. While there was limited benefit in this workflow, it did offer great flexibility to the different disciplines, as there was little or no dependency on using each other’s work—just the most basic information was used for reference.
With the advent of building information modeling (BIM), a new opportunity emerged: communicate with the other party at a model level to exploit the value of all the information that was already in the model. But this also raised new issues—one of the most significant ones being that the different modeling applications had proprietary file formats and, perhaps more importantly, unique data models.
In response to this, we can identify three primary strategies the major software suppliers have adopted to address this huge hurdle. Let me spend a few moments explaining each of them:
Common language
The International Alliance for Interoperability (IAI) was formed by CAD vendors to develop the Industry Foundation Classes (IFC)—an open and “non-proprietary” model format to provide a universal communication platform for model-based collaboration.
Now an ISO standard, the core of IFC is a built-in dictionary of intelligent building elements that serve as a “map” to convert models between applications that can read/write an IFC file. With the capability of saving/opening “generic” IFC files, users get the immediate benefit of communicating their models to solutions being used by other specialists.
Direct interfaces
An alternative solution is for software vendors to implement specialized links between their specific solutions. Sometimes, this approach is only undertaken by one of the parties, utilizing the API (Application Programming Interface) of the other solution. Of course, a much higher customer value can be achieved when the vendors develop a long-term relationship in which the focus is not just on how their solutions can exchange data but also on how to implement the most optimal workflow for their users.
Single platform
A fundamentally different strategy is where a software vendor aims to develop competence in each AEC segment and tries to supply the whole spectrum of needs with their own design solutions. Obviously in this case, the proprietary file format dimension of data exchange is likely to be a non-issue between the different applications in a “common” product family. Communication in the “native” language of the applications should achieve seamless and efficient collaboration.
Discussions on the different strategies described above usually result in interesting arguments about issues of standardization, workflow support, etc. However these arguments are no more than just that—interesting! I believe the real question for software vendors pursuing any of these strategies is: How can your solution maximize value for the customer?
In the following paragraphs I will explore those issues, which I believe are the most important ones to find answers to.
Diverse world
There is no question that a single platform solution has advantages, but the environment we are designing in is a rather diverse world. Can designers and engineers really afford to limit their collaboration to only partner companies that have the tools of the very same product family?
Except for large A/E design firms where all the disciplines are “in-house,” the answer is probably no for the vast majority of architectural practices since they need to collaborate with a range of specialists, across a range of projects, each of whom will use a design solution matched to their specific needs.
On the other hand, such a diverse collaboration matrix does offer additional advantages as well. Most importantly, it allows the local, “best-in-class” solutions to evolve in an organic way and stay connected to the BIM workflow. In this case, professionals using solutions that provide proven results according to local standards can continue to work seamlessly in the environment they trust and are used to.
So, the BIG question is: how can you combine the benefits of a single platform strategy with the benefits of access to the huge vertical pool of expertise in this diverse world?
Expectations from IFC
Despite being an ISO standard, can we really expect IFC to be a fully-fledged solution that provides, in addition to a high quality data conversion, a seamless collaboration workflow as well?
The most often expressed opinion is that an IFC based workflow is just an 80% solution—meaning it is fine as a general solution, but we shouldn’t rely upon it to work in every single context as well.
I have to admit that there is some justification for such a critical view but I also think this might be partly the result of false expectations. The IFC data scheme is far richer than the scope of any single BIM application, which is concerned only with a small subset of the building data, and has no “expertise” to deal with the rest.
There are many great examples of collaboration workflows based on IFC exchange. But were these achieved merely by exporting the building model data “as IFC” (for a general purpose) without any knowledge on how the receiving party intended to use the model?
Think about the workflow
Ultimately, the primary process interest of the designer or specialist is not the exported data itself, but the establishment of an effective and seamless workflow with a given software application.
For this very reason, generic IFC viewers promote the wrong perception: IFC data on its own (without context and interpretation) is the end of the story. In reality, this is of limited, if any, value!
For really meaningful collaboration, we have to think about a roundtrip workflow, where specific responsibilities are assigned to the parties, and where iterative processes enable changes to be managed and completed by the appropriate discipline.
So the essence of the “workflow” should be about matching the business logic of the two disciplines. Recognizing this, it becomes quite obvious that the method we use to hand over the data should be just a secondary issue—it can be IFC, API, or a proprietary file.
Acceptance of this then leads us to the conclusion that, with some optimization, IFC can be an ideal solution. A great example of this approach is the IFC connection between ArchiCAD and Revit Structure. Taking into account the special communication requirements of Revit Structure, ArchiCAD creates just the streamlined “clean” set of data that is necessary for the structural engineer to work with. In practice, this solution provides a seamless workflow between the architect and the structural engineer using the IFC platform.
Standardized protocol?
The approach mentioned above has further potential for companies that cooperate beyond the standard IFC interface. Agreeing on a “bilateral” communication offers the reality of a textbook solution to both architectural and engineering disciplines. You might conclude that in this diverse world, it is not viable if every single connection workflow has to be defined from scratch.
However, I take a rather different view! The fundamentals of these workflows are quite similar and once the workflow logic is implemented for one solution, the infrastructure is very quick and easy to adapt to other solutions as well. Below is the workflow diagram for the ArchiCAD – Tekla Structures connection, which was developed in this manner.
My purpose in this article has been to provide a conceptual overview of collaboration workflow issues and to initiate debate about how the level of collaboration between the architecture and engineering disciplines should advance. I have tried to show that the real question about BIM collaboration is how software vendors can deliver on combining the benefits of a single platform strategy with the benefits of access to the huge pool of vertical expertise in our diverse world.
It is evident that the best workflow solutions are those that follow the business logic of the inter-connected design disciplines. One viable, and already working, answer to this is intelligent workflow solutions that are based on the IFC platform. I believe it is in our common interest that we don’t lose the “bio-diversity” of our planet in any sense, including our collaboration strategies.
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.
