Phil Bernstein on the Changing Role of the 21st Century Architect—The Interview (Part 2)

We continue our second part of this exciting interview discussion with Phil Bernstein, FAIA, RIBA, Yale professor of architecture and Autodesk VP of Strategic Industry Relations. Click here for Part 1.

Part 2—On Contracts, Revit’s Brain, Coding, and Architecture School

(Architosh:) So how do you see the contract situation evolving given where architecture practice needs to go in the 21st century?

(Bernstein:) Well, let me answer that question as a former chair of the AIA Contract Documents—which means I spent eleven years writing standard form agreements with my colleagues. I would observe two things. One is this basic principle which is: it is important for architects not to conflate contracts with practice standards. The contract is the last artifact in the change in a project standard. We have a habit in our profession for waiting for someone to write a contract to describe the way we should do things and that is completely inverted. We need to decide what we want to do and then write contracts to make that happen, rather than waiting for the AIA or someone to dispense a contract writ whole.

Having said that, I think what we are seeing right now is a new reality that mediates between [design] intent and [building] execution, and it is starting to percolate through various types of project delivery methods. And so we see overlays between the various standard contracts, episodic moments of collaboration…created by individual opportunities. So even on a hard bid job, for example, there might be an addendum to the general conditions that says the architect can provide X amount of digital information to the selected contractor.

There are these collaboration and integration “flavorings” that are happening on top of all of the different types of contract models. But I think ultimately what we will see is the evolution of a delivery strategy that looks very similar to what today we are calling IDP. (see image 01)

Integrated Project Delivery.

Yes. In other words, where a design and construction team are in concert responsible for a series of project outcomes related to the project. And the contract will be about how they cooperate and make that happen, and how the owner rewards them when it does happen and punishes them when it doesn’t happen. You are going to see the DNA of basic contract structures [in AEC] starting to mutate a little bit. But there will also be disruptive models out there.

In my practice world, which is the high-end residential world, for the most part, we make the argument with clients that the sooner we can get a builder involved the sooner we can collaborate with them. And that [collaboration] affords multiple benefits. But at the same time the clients are, usually, interested in getting the best possible price in the end.

Right. They want pricing tension in the system.

So there is this balancing act…between the clear and present opportunity for collaboration and the oppositional-based leverage of competitive pricing in the “design-bid-build delivery” model. I think it is clear in this industry that collaboration, in the end, wins. So relative to your role at Autodesk, how is your company responding to this reality both at the technology and product strategy level?

Well, I can answer that a couple of different ways. If you look at the research we are doing at, say Pier 9, in San Francisco—which is all about understanding the deeper implications of the maker-movement and first-line manufacturing. And we are also building a similar space, with a different focus but on the AEC industry, in Boston right now. So by May, we will have opened up a research laboratory whose specific purpose in life is to explore this question of the relationship between digital technology and the physical construction of buildings. So we are out there doing that kind of research.

I think from a product perspective, we pretty much acknowledge the lengthy biorhythms of the building industry. The building industry moves slowly and that is partly because it is made up of a highly diverse network of loosely integrated collaborators. So that’s number one. And secondly, it just takes a long time to build buildings, right?

Yes, of course.

The building cycle is not quick. Having said that, we know that we need to continue to nurture what we call the era of optimization, modeling strategies that are out there. Using 3D models, using building information models (BIM), looking at areas of the building and optimizing it. But what we know is that we need to move into a new frame of reference, where optimization begins to give way to a sort of connected view of all the different performative and descriptive aspects of a project.

So in terms of the next generation…and what we are looking at? It is how to make that happen.

Can you get more specific? What is the view around Revit for example?

Well, continuing from what I just said: what does that mean for the design process…for generative design…for machine learning? What is the definition of project collaboration? Is it just pushing files around? Or is it something new and different?

So, we are looking at how to put the project data at the center of the process…and all the tools that use it at the perimeter. That is the inverse of what we have now, where applications are at the center.

That means that right now a given job might be a Revit-based project. And the Revit files are the center of the universe. So more and more, as time goes on, that is not going to be the case. You may still need Revit’s brain to organize all that information, so there is a coherent topology of it—so you know where it goes and how to reference it—but you may be using data from 40 or 50 applications applying to that project. How does all that stuff get glued together?

So where are you with that?

So what we are working on now is trying to figure out what are the most advanced definitions of design and construction in that context.

So for the first time since I have been with the company [Autodesk] we have been treating the design process and the build process as a single problem, instead of a discreet set of work issues that are connected to what architects do, what engineers do, and what contractors do. That’s a very long term view of the kinds of things Autodesk is working on right now.

So, as practice moves to ever greater levels of precision, as architects gain the ability to fabricate themselves or be collaborators in the build-process—then of course there is this whole thing about robots coming into construction, et cetera—and we have evidence-based design, big data impacting design…what I see is this opportunity—maybe mandate—for architectural practice to start tackling this knowledge management problem; because unlike medicine, for example, where we track efficacy of drugs, outcomes of measures and procedures…in architecture we have never really tracked anything.

Yes, that is absolutely true. And you know that’s a whole separate interview, right? That’s a whole separate discussion. But when you were describing that scenario of the high-end residential client trying to decide, whether to get the builder involved early…that whole decision, as “The Car Guys” would say, is unencumbered by the facts.

If you could put something in front of the client where you could say: “here is research from 50 projects similar to the one we now have, and here is what we have learned: 18 percent of the hard bid jobs were 30 percent more over budget.” But there is no knowledge infra-structure of that type in our industry, even though a trillion dollars a year gets spent, roughly speaking, on construction in the United States. It’s amazing to me. It is absolutely an opportunity.

When I look at the MacLeamy Curve and look back over the years, I see a predominance of activity, investment, and build-out of solutions that solve problems on the backend [of the MacLeamy Curve] and not so much at the front end. Architects are most valued and impactful in the beginning, and I think the early stage of the process is ripe for rethinking about how it works.

Well, I guess the question is—and this is a philosophical question we are struggling with—do the kind of tools that might help the front end of the curve, are they also not applicable to the back end of the curve, just as much? Say, you are talking about some generative, design optimization stuff where you parameterize everything and run alternatives…why isn’t that tool equally applicable at the back end of the MacLeamy Curve? (see image 02)

It has to be, right?

I would think so…not sure.

I’m trying to get my head around these questions and issues. The design problems and their solutions often stretch out over time into the operation of the building. These tools have to be much more generalizable across a broad spectrum of problems. We can’t just build a tool that optimizes space adjacencies of a hospital floor. That tool just sits there by itself. What is the generalizable tool that comes from that? That’s where we [Autodesk] are going. And I have no idea how long it’s going to take to get there but that is definitely where we are going.

I kind of see both fronts being very meaningful and impactful. I can see tools with great specificity having value—and maybe the healthcare market is one specific sector where that would be meaningful—but also see the importance of generalizing tools. Do you see value in things working out that way?

Yes, absolutely. I think there are a couple dimensions to that. Architects building their own bespoke tools and sharing. And the other is the whole role of “coding” as a design skill. We should be able to build these sidebars; it shouldn’t take a PhD in computer science to build a lightweight tool that solves a very specific problem. (see image 03) But if it’s an interesting problem that yields an interesting answer, why not share it?

HKS research group, in Dallas, is a non-profit actually, and they are trying to follow that model. If we solve a problem for a healthcare client and we do it under the aegis of a non-profit, then maybe we can share that information more broadly and follow its history.

Should architects be exposed to coding and software development, at least at the design level, in architecture school? What are your thoughts about that?

Well, I’m torn. As a technologist, perhaps because every kid out of architecture school these days is a Grasshopper jockey anyway, it is kind of happening. On the other hand, putting on my other hat as a teacher, an educator, I don’t want to jump too quickly to that idea because the pressure on the architectural curriculum right now is enormous because we have to teach so much material. And until we rethink things in a fundamental way, I’m extremely hesitant to add something else that is required to the curriculum.

A group of colleagues and I just published a short manifesto on some of these topics, that you can get for eleven bucks on Amazon called the “Goat Rodeo: Practicing Built Environments.” It’s a series of very short essays on the essential questions of architectural education. You will find a few thoughts on this front there.

Yes, I would love to read that…and I’m sure readers also. Last year I was at an event for the new president of the BAC (Boston Architectural College) and there was a roundtable and he [Glen S. LeRoy FAIA, FAICP] described three dominant types of architecture schools. And one is the big state school that has multiple bespoke research components that impact the architectural program…

And also likely legislative requirements to crank out a number of architect graduates every year.

Yeah that too, I suppose. So, that is the “research oriented” schol. And then there is the other type of architecture school which is the kind of “design school,” the RISD kind of model; and then the third type, which he—Glen LeRoy—felt the BAC squarely fit, which is the “practice oriented” school, where they produce very competent generalist. And I can see that…these three types of schools. But honestly I don’t know if these models are as helpful as we imagine for where architects need to be in the 21st century…not in the context of the issues we are describing here. Should we be inventing an entirely new model that we apply to every single architecture school?

Well, these are excellent questions. And if you look at how other professionals are educated—for example, if I want to be a tax lawyer I have to do three things. I have to go get a college degree somewhere, then I have to go to law school, and then I go get special training in tax law. Now, if I don’t want to be a tax lawyer, I just want to be a generalist lawyer, I can skip the tax piece. And if I want to practice medicine, that route is required too. I have to go to four year college, I have to go to medical school, and then I have to do a residency in whatever practice area that I’m going to be specializing in. It’s a lengthy time-line, but it’s a very elegant structure; it works very well and produces very well educated—and I think people would argue—very competent practitioners.

What we have done in architecture is we have these “multiple routes” through the thicket, but through licensing and accreditation we just keep trying to stuff more things into the same bag. And it doesn’t work as well as it might, as we argue in the [book] “Goat Rodeo.”

I tend to agree. And actually, when you mentioned law and medicine, one thing you didn’t mention is that these professionals are socially valued and are compensated rather well, given the length of their professional educations. And so, you are right, I’d hate to see architects be required of even more and then come out [of school] and still have the same relationship to society and end value.

I actually wrote a journal article on this exact topic. Yale has this theory journal called “Perspecta,” I am sure the BAC library has a copy of it…

Yes, I am familiar with it.

In “Perspecta 47,” titled “Money,” the first essay is mine and it talks about this exact same question. It just so happens that the law school, the medical school, and the architecture school, here at Yale, are all on the same street. It makes for an interesting comparison.

That’s interesting. Didn’t know that. And with that I think we’ll end this talk and hopefully pickup another time. This was most interesting and I appreciate Autodesk reaching out for the conversation. So thank you very much. 

You are very welcome. Thanks again.

Conversation Recap

What we learn in this extended conversation with Phil Bernstein is that one viable way of looking at the distress some detect in the architecture field within AEC is that the field is facing a multitude of new pressures and isn’t particularly well prepared for them. On a cultural and legal level, as we learned in Part 1, the field must now ask honestly what role it wants to play? It must take more command and initiative—perhaps playing the disruptor or at least the entrepreneur model—with respect to how architects form themselves and their activities as businesses and within contractual obligations.

What we learn in this talk is that, with or without the aegis or blessings of the AIA, or RIBA in the UK, or any other similar organization, Autodesk, as a global software leader in AEC is going to rethink the entire enterprise of how things are designed and made. Through innovation in digital technologies, the A, the E and the C groups in AEC are going to respond. It is not a question of if…it’s a question of how?

Astute readers may have detected the increasing Autodesk “tone” change by Bernstein that has largely begun in just the past couple years where the company wants to be seen as a more cooperative player and partner within the larger AEC industry. Noting that today many times the Revit files are the center of the universe, Bernstein states, “…more and more, as times goes on, that is not going to be the case.” He states that folks may still use “Revit’s brain” to organize information but projects may involve up to 40-50 applications.

Increasingly, in our conversations with Autodesk, the company is acknowledging that firms want to use the best applications in specific sections of their workflows, and many times those tools are not made by Autodesk. It is hard for someone in the market to take seriously rhetoric about inefficiency in AEC—which is true by the way—if the entity yielding the rhetoric isn’t doing something about not contributing to the problem. In other words: make all your tools talk well with other companies’ tools.

Bernstein, as a Yale professor, is largely at the forefront of the educational vanguard in computation and coding in architecture schools. Yet, while acknowledging that it is hard to advocate to push one more skill set onto young architects as part of pedagogy, there exists an inherent obviousness to these new skills being shown by the “algorithmic movement.” If this wasn’t important, why have four major entities expanded upon this domain? I’m talking about two of Autodesk’s key existing competitors in Graphisoft and Vectorworks, the latter creating its own Grasshopper rival tool, while Google’s own Flux.io pivoted awhile back and has focused its efforts in these areas as well.

The next time you hear or watch an IBM Watson ad on the tele, recall that architects have been tardy, much to their detriment, several times now. After the call for CAD and then BIM, will architects miss the boat on computation and coding and let “others” tread further upon their already weakening domain?

Finally, Bernstein doesn’t quite answer the question if there should be a new “type” of formulation for architecture schools in the 21st century. This isn’t necessarily the question that got away—the “Goat Rodeo: Practicing Built Environments” tackles this as its essential mission.