Technology Overlap and Synthesis in the Architecture and Engineering Disciplines

Earlier this year my university was visited by Bill Baker, Structural and Civil Engineering Partner at Skidmore Owings and Merrill. Baker’s lecture was delivered to an audience of a somewhat rare composition: architecture and engineering students and faculty together in one room, listening intently to the same words. The main theme of the lecture was the relationship between engineering and architecture. One of Baker’s points resonated with me particularly: “Engineers spend careers making things work...the philosophy is wrong. Engineering is about being part of the process so that making it work is integral to the design.”

I teach in an architecture program and my training is wholly architectural, yet my research and teaching specialties frequently involve architectural performance and with it, fragments of engineering. Baker’s assertion about performance and the design process, in consequence, was poignant. In fact, at the same time I was introducing environmental simulation software to architecture students in my environmental systems lecture class emphasizing a similar assertion: the power of such software comes at the beginning, rather than the end of the design process, when critical feedback about early design decisions can feed into the final design outcome. The implication is that the application of the tool, rather than the tools themselves, is critical to integrating performance-related technology in practice. We may have the fanciest, fastest toolsever, yet what matters to our discipline is how these tools are integrated in the larger process of design.

I was intrigued to hear a similar argument from an engineer: a call for the work of engineers to be more integrated in process, rather than isolated at a “step” in the “handing off” approach to problem solving that characterizes much of building today. It seems engineers, enjoying a similar boom of new computer-based tools, are confronted with the same issue of integration. Further, it can be argued that relative to the specific issue of performance, the integration of new tools by architects and engineers actually requires that these disciplines reconsider the working boundaries that have distinguished them as modern professions.

In my own program’s curriculum, and presumably speaking in many other architecture programs, new professional curricular requirements are putting pressure on technology courses—including structures, environmental systems, and construction technology—to reexamine the scope and application of their subject matter. A common mantra in this discussion is that in a school of architecture, the students “don’t need to be trained as engineers,” thus downplaying the necessity to approach these technologies quantitatively.

Yet as our design students use their calculators less and less to “quantify,” developments in computing software have opened a new territory for designers to simulate the performance of architectural designs—specifically in the areas of resource consumption and estimating, structure, and thermal behavior. The paradox here is that while stu- dents are quantifying less, in the older formulaic sense, the computing technology they are increasingly exposed to is quantifying more. The result is that while it is true that they are no longer using calculators like engineers, they are in fact analyzing performance and, in consequence, making decisions like engineers.

Simulation software such as Autodesk’s Ecotect have thus become quite common in architectural schools (although experts, many of them from the engineering community, have debated that particular tool’s accuracy), and many of these tools have been improved after a decade or even more of existence in the software market. Firms such as Foster and Partners have become well known for implementing these advanced tools in their work. Yet it is difficult to find mainstream architectural firms actually using this software in their design process. At a recent meeting of the professional advisory board for my department, these particular software tools were discussed with an audience of firm leaders of whom only one individual (an executive in a facilities planning firm) had known of such software in use within their practice. How can it be that such accessible and valuable tools are not being implemented in design practice? If we recall Baker’s quote, in the context of technology perhaps it is not the tools that are the problem but the working process in which they are applied.

It seems that the disciplines of architecture and engineering, while clearly sharing access to similar technologies for design and analysis, have been groomed to perpetuate the “hand-off” workflow that evolvedwith the modern (and distinct) professions of architecture and engineering. The availability of the tools alone have failed to establish an integrated approach to performance in architecture; architects and engineers seem entirely content to work in separate professional territories using separate (though similar) tools.

Consider Autodesk Ecotect (mentioned earlier), an environmental analysis tool used in the architectural community and less so by engineers, who prefer tools such as EnergyPlus (in the U.S.) that have established correlation to real world performance results and thus are recognized by energy codes, the USGBC, and so on. Engineers are critical of Ecotect for its margin of accuracy: i.e. the software’s results. Architects, on the other hand, are more concerned with the value of design feedback that the software provides in early schematic design. Clearly, there are multiple levels of operations when software is at issue: the software itself and the way in which it is contextualized by the profession.

Paradoxically, the contextualization of these tools by architects and engineers has been very much independent, rather than interdependent. We have already discussed the shifting toolset of the architect from computer-aided drafting and modeling toward performance and analysis. Engineers, on the other end of this process, have had their toolset shift away from raw computation toward modeling. In other words, instead of working with abstract calculations, the newest tools of engineers (finite element analysis, computational fluid dynamics, nonlinear structural analysis, and so on) use three-dimensional models in the analysis and thus allow users to engage issues of form, space, and connection that before were limited to only the most abstract derivations.

To summarize the previous point, architects are moving into the territory of performance while engineers are moving into the territory of form. It would seem that such technologically-driven expansion would lead to spontaneous collaboration between the disciplines. Yet what is arguably more common is that the professions are conflating: architects and engineers are creeping into one another’s territory of practice as a result of new technologies. With performance and analysis available to architects, and modeling-based workflows available to engineers, a degree of overlap and ambiguity is born between each disciplinary sphere. Bottom-up collaboration could certainly result from this overlap, but the persistence of the “hand-off” workflow results instead in mere ambiguity. Architects play in the engineer’s sandbox and vice versa; rather than defining a process of working together via new technologies, the disciplines are merely conflating over their boundaries indiscreetly.

I see in my own research work a tendency toward conflation and the problem it creates. At times I am confronted with performance related problems that my architectural training leaves me unprepared to understand, and thus I constantly push against my knowledge limits in order to interpret what I am doing. This is the Achilles’ heel of an architect running a computer simulation: the need to interpret results that to some extent require advanced knowledge of mechanics, physics, and so on. Such limits on interpretation would certainly raise a flag in practice; integrating such advance tools suggests or even requires collaboration in order to best utilize them in the context of practice.

Engineers tend toward a similar conflation. Advanced, model-based tools require engineers to develop, with significant detail, the three-dimensional characteristics of the thingto be analyzed. How, when, and by whom is this subject of analysis defined? Designers and, in the case of buildings, architects, must be involved in this definition in order to provide the proper context for this physical form. The issue of physical context becomes greater when optimization is considered: how can the physical “thing” be meaningfully improved without a clear understanding of what it has been designed for? While not everything in the world requires invention by a designer, it is true that many engineered things at some point involve the intervention of a designer to unite technical, humanistic, and economic imperatives.

In summary of these points, it is clear that in light of new advanced technology and the demand for higher performing buildings, the disciplines of architecture and engineering must do better than simply conflate their respective roles.The alternative to conflation is collaboration; more specifically, addressing performance and deploying technology early in the design process with integrated insight from the two disciplines in a bottom-up approach.

Approaching performance collaborative, from the ground up, is a better deployment of new technology because the tools can be applied in a more appropriate and effective context; performance and modeling can benefit from the knowledge of both disciplines from the beginning of the working process. Simulation in the architectural design process benefits from the engineer’s interpretation while the models of the engineer’s analyses and optimizations benefit from the flexibility of design intuition and intent. The latter point is important, as engineers are seldom offered the ability to influence the design context and are still more often than not problem solvers. Could the discipline become more involved in framing design problems? This is exactly the power of new technologies from a collaborative perspective. Design problems can be adjusted on the fly, new design trajectories initiated with few barriers, and so on. This is the thinking, perhaps, that was behind Bill Baker’s call for engineers to integrate their work in the design process. Fully engaging performance, in conclusion, is no longer limited by the capabilities of new technologies or tools. It is a challenge that must be overcome through collaboration and ultimately by rethinking the profession and working processes of architects and engineers.