How Digital Advancements and a Spirit of Collaboration have Continued to Fuel New Design Ideas.

Before there was AutoCAD, SOM simply built its own design software. Why? A glimpse of the firm’s recent and not-so-recent history demonstrates an enduring culture of creativity and collaboration that fueled its early technological explorations and has led to some of today’s most advanced buildings.

---

Article Originally Published on Medium

---

For an article published in The Changing Shape of Architecture: Further Cases of Integrating Research and Design in Practice, SOM’s Neil Katz and Daniel Cashen reflect on the history of the firm and its output in the context of its technological advancements and social collaborations. Both bring their own, distinct experiences to the story. Katz, an associate director who joined in 1985, helped expand the use of computers across the firm through his participation in SOM’s Computer Group and later, the Digital Design Group. Cashen, an associate director who joined in 2010, has been immersed in some of the firm’s more recent, structurally dynamic projects, including the Guiyang Cultural Plaza Tower, the Wangchao Center in Hangzhou, and the Burj Jumeira tower in Dubai.

They recently sat down to discuss their experiences within SOM’s cross-disciplinary environment, how technology keeps shifting designers’ expectations for the tools they use, and how client demands are changing along the way.

How did the introduction of computers change the way SOM approached its work?

Neil Katz: When we started using computers as part of our design process, there was no CAD [computer-aided design] software available. We had to invent it, come up with the rules, and create the process.

Was there any internal pushback?

Neil: Not really. It’s not like all the partners said, “Let’s do this!” but there were a few who really thought it could be useful, even powerful.

Did it seem radical at the time to be investing in this? In the broader industry, what was the feeling?

Neil: That would have been before I started, but I’m sure people saw it as something that was coming. When I came here to the New York office in 1985 most of the development was being done in Chicago. That’s where the engineers who really started this effort were located. It was architects and engineers who created the tools — they had an interest in writing software and learning the languages they needed to use it.

Dan Cashen: The introduction of computers into the profession and the industry was the big disruption. But we’ve seen many other disruptions over the last three decades. The introduction of Grasshopper [a visual programming language] starting around 2007 was a game-changer. It was the first time that students in design school could create parametric models with ease — to be able to iterate what Neil was trying to do in the ’80s with CAD tools.

There have been other big disruptions, like the reliance on Revit models [architectural design and documentation software] for project delivery and the frequent use of VR for client communication and design. More than ever before, we’re making spatial simulations in VR rather than two-dimension abstract drawings.

Neil: Disruption wasn’t a goal or even necessarily thought of as a good thing when we started using these tools. But looking back today, it was exactly that, and in the most positive way possible. The CAD tools we were using — initially our own, and then others as they were starting to become available and popular — were simple by today’s standards, and powerful. DRAFT and AES — collaborative, SOM-proprietary tools — had simple scripting languages which enabled iterative modeling. AutoCAD was so different from how we were using DRAFT and AES—it was initially designed for a person to work on one model or drawing at a time, without regard for other people or other models. We customized AutoCAD to match our workflow, yet still allow people to use the AutoCAD interface and commands. AutoCAD also has a scripting component, which allows for iterative (parametric, algorithmic) modeling, but it’s slightly more difficult to learn and master that the previous tools. Some aspects of these scripting techniques allowed us to model in ways which are somewhat challenging with today’s tools. Recursive modeling, for example, is easy with the scripting tools in AutoCAD, but much more challenging with Grasshopper.

So when a client wants to experience a project, are you literally handing them a VR headset?

Dan: Yeah. Product delivery terms are changing, and clients are expecting a higher level of representation — they want to feel the space. Architectural representation as a communication tool, such as VR, is creating a greater immediacy in the feedback loop with our clients. They can inhabit the space from day one. In school, we were all taught to make physical models because they help you immerse yourself in the space, but now you don’t even have to do that — you can actually be inside the digital model with the click of a button. VR has been around since the ’80s, but what’s actually new is the prevalence of low-budget hardware and the ease of use that’s changing the process.

Which SOM project best exemplifies computer technology improving the firm’s capabilities or outcomes?

Neil: The John Hancock Center, for engineering analysis. Also the Hajj Terminal, for formal exploration.

And today?

Dan: The Wangchao Center in Hangzhou. Grasshopper and parametric technologies were fundamental to actually achieving a uniquely shaped tall building design that is structurally efficient, and economically viable.

Neil: I would include the design for Lotte Super Tower in Seoul, which has similar parametric control, but it was before Grasshopper in 2007. Back then, there were only a few people willing to do the hard work of coding in order to explore the design in a way that was as fluid as most people can achieve now.

We worked to optimize a diagrid structural system in response to many constraints. One was the angles of the support members; we wanted them to become more horizontal at the top while addressing gravity near the base and the wind loads at the top. We also had very specific requirements for the building program, which helped determine the floorplate size. The larger floorplates at the bottom are better able to accommodate some of the functions there — offices and retail. The residential and hotel components are located at the top, where the floorplates get smaller. The diagrid members had to meet each other at a floorplate, so that also constrained the shape of the diagonal members. All of those things combined didn’t lock the building in place, but they gave us a lot of variables that we needed to consider throughout the process.

Dan: A magnified version of that structural system is the eccentric diagrid for the Wangchao Center. The floor plates are shifted to create variations through the tower, making it appealing for companies of different sizes. But beyond the somewhat scientific, parametric process, we wanted to create a building that would be a landmark.

An iterative design process has always been an inherent part of architecture. But in this case, the parametric tools allow us to arrive at the solution much faster, because manual aspects of the process are no longer necessary. With the computer figuring out those aspects, we can focus on more big-picture moves.

What was the Computer Group and how did it function within the firm?

Neil: The Computer Group was the people responsible for creating and teaching our proprietary software. It taught architects and engineers how to use these new tools. It also worked on projects to provide specialized or complex task expertise, and developing tools to make it easier for the teams. Specific tools for a particular task could then be generalized for others to use as well.

Most of the core development was done in Chicago, and the Computer Group there was a substantial size. But we also did some development in the New York office, where I joined as part of the group. In New York, an office of about 500 people, there were about a dozen people in the Computer Group. There were about a dozen computer terminals scattered throughout the office that project team members were using to work on projects and the number of people wanting to do this was constantly increasing.

Dan: The Computer Group fits into an idea from the firm’s early days: the need to cut through hierarchy and empower people, especially younger members of the firm, to emerge as leaders. SOM is an 80-year-plus experiment that keeps on going, and it does that because we are constantly reinventing ourselves. When we reinvent ourselves we continue to innovate, and that is rooted in our use of technology. So if you go back and think about the Computer Group and what happened there — it was the partners empowering these people to form this group, they were making these tools, and that helped people like Fazlur Khan and Bruce Graham produce designs like Hajj Terminal and Hancock Tower. We’re still very much in that loop. It’s tapped into that culture of innovation rooted in our use of technology.

How has the approach to technological innovation evolved within the firm since the early days of digital design?

Neil: There were about a dozen of us in the Computer Group and a dozen outside the group using computers — we had different functions. Now there’s an IT department that deals with hardware and installing software, and the Digital Design Group, which I’m in now, that deals with actually using the tools. The Digital Design Group specializes in the tools architects and engineers use, and works with them. When I started in the ’80s I was already using the computer to create drawings and models. People who weren’t would see how I was using it and realize it could be useful for them. It sort of spread that way.

Dan: It’s also one of those intrinsic qualities of SOM as an integrated practice: working with engineers hand-in-hand, being on the same team, working with technology leaders as a unified team. That allows you to reinvent, innovate, and find new uses for technology.

Advancements in engineering and tech are typically associated with structural complexity and building heights. What about sustainability? How does this technology change the firm’s sustainability targets, or help it achieve those targets?

Neil: We’ve used analysis tools for a long time, but they’ve become easier to use — and so now we use them on every project. For instance, we would do a solar analysis to understand how to optimize daylighting. Now there’s a direction, across the industry but especially here, to make sure every building is environmentally responsible.

Dan: That’s something that has changed since the early 2000s. Architecture students are now armed with new parametric tools that are easily accessible. For example, a new generation of architects joining SOM is accustomed to being able to run daylight simulations because they’ve already done this in an academic setting. Today’s designers have so much power at their fingertips. For one of our projects, P.S. 62, the first net-zero energy school in New York City, the simulations were first done in-house, using DIVA. Over the years, we’ve standardized this process with assembled toolkits, templates, and presets that are easy to use, allowing us to quickly run these simulations.

How does artificial intelligence (AI) affect new work here?

Neil: Machine-learning and AI is something we’re starting to get into. There are a couple of people in the San Francisco office who are spearheading that effort. It’s very data-intensive, so if we have data we learn from it and adjust. One example is in construction administration: we’re taking photographs of rebar, of the structural elements as they’re put in place, and then comparing those photos to our models and seeing where they differ, highlighting them in photographs or in the model where something doesn’t match, and identifying places we need to take a closer look. A team of people from SOM went to Mexico and Alaska after their recent earthquakes. Using photography of damaged buildings, they were able to teach a machine how to read those photos, and look for what’s causing problems in the structures, or be able to locate areas of concern that might otherwise not be detectable.

We’re thinking of using similar technology as part of the design process. On building cores — the layout of stairs, elevators, and other elements — we’re trying to see how you can use some of these techniques to inform the design process and learn from previous, successful cores we’ve done.

I think the most insulting thing an architect can say to an engineer is “make it work.” We don’t do that here.

Dan: There’s a team here dabbling with AI as a planning tool, to determine the best configuration for a building. Processing all these constraints, the tool would iterate something a client might not have expected.

One of the most compelling conversations taking place now among colleagues is about predictive modeling. We’re in a new reality in which we can now make a 3D model while inhabiting it, simulating the design at a real-world scale.

Right now the hardware is a little clumsy. It’s fatiguing to continuously model in VR with a set of wands. But if we foresee the promise of predictive modeling as an overlay of AI onto Rhino, we could imagine the viability of modeling in real time, in VR. Fatigue will be mitigated with AI modeling assistance that has learned your behaviors and can auto-fill what you’re intending to do. Voice commands don’t seem too far off either.

Neil: Sometimes when I’m in Rhino I think it already knows what command I’m about to type! We’ve been discussing using VR as a modeling interface, and interacting with the model with gestures instead of traditional commands. AI might play a part in this type of interaction between human and machine as well.

For a global firm organized like SOM, we hear about the shift toward a 24-hour-office. What does that mean, and how does information gets shared with colleagues in other time zones?

Neil: The simple answer is that information is now on the cloud, when it used to be on a server in the office. If we were working with someone in San Francisco or China who wanted to access information, it would take a while. Now it’s in the cloud, so anyone at any time can access a model and be able to interact with it — even simultaneously. With AutoCAD you open a file and then it locks it so no one else can use it, but with Revit it’s like a Google app where a bunch of people can access it at the same time.

Dan: For the Hangzhou tower project, we were a 24-hour team. We’d wake up, get on a call, talk about what our team in the Shanghai office did, then pick-up where they left off. At night we’d call them again as they were coming into the office and hand off our part of the work. That was possible because the architectural model is in the cloud now. Also because we’re working around the world and have clients that aren’t able to always be with us, we can send things on the cloud to them, like simulations of a 3D model or a VR experience. With the prevalence of advanced mobile hardware, increased network bandwidth and the sophistication of these cloud-based platforms, we can be connected to our clients like no other time because we can send this information for feedback and get an immediate response.

Some of these tools have enabled us to create geometry so much quicker, with nimble teams, and with less effort. Because the manual parts of the process have been minimized, we can create a lot more. One could question if creating a lot more at a higher speed is making us perhaps less critical about what we’re designing. Just because we can model it in 3D doesn’t mean we should.

When I first started, it took a long time to render something. You would press a button and check on the rendering three hours later to see whether or not it failed. That process of waiting was basically the same as hand-rendering, albeit a lot less labor intensive, because you still had to stipple and shade things by hand for hours. Now, with real-time rendering engines, you can press a button and it’s visualized immediately.

Neil: And you can visualize it so beautifully.

Created with Grasshopper and Rhino, this video documents the different workflows and tools that were custom-made to control the Wangchao Center’s parametric design. Video © SOM

How does all of this change the role of the designer? If you’re liberated from the more mundane parts of the work thanks to new tools, what does that mean for the profession?

Neil: The most important thing I do when I’m working on a project is to develop a strategy for how the tools can be used, both in general and for a particular project. If there’s a project that needs to be constrained within a set of rules, then you want to figure out how to develop and articulate that set of rules in the environment you’re using to create the model.

Dan: With our the new set of parametric tools, we can efficiently solve for a series of constraints and scientifically answer all the structural, mechanical and planning issues for projects of all scales. Perhaps an AI model could, eventually, do that on its own as well. But architects have always been deeply involved with social and cultural issues, and understand the implications of an architectural design which speaks to the site and the client. As we reduce the amount of mundane tasks, designers can increase their scope of understanding and the implications of what it means to build something in a particular place.

Neil: We’re doing a project out of the Chicago office for a Chinese city that was along the Silk Road. The client wanted to somehow use that as an inspiration for the design. How do you define that constraint into a computer? Maybe there’s a way, but I don’t know what it is.

Do other firms have a similar culture?

Dan: No. We’re a team of architects and engineers — not the only one in the world like that, but the combination of our scale, legacy, and projects has created a unique culture of collaboration and a use of technology that distinguishes us from our competitors. You don’t see one person’s name on the door, you see “SOM” — it’s a collective.

Neil: Anywhere an architect is sitting in a studio, there’s an engineer in the next aisle. And it happens at all levels. The partners in Chicago, Scott Duncan and Bill Baker, have offices right next to each other, and they’re always talking about their projects. And historically, Fazlur Khan and Bruce Graham would collaborate. There’s a famous picture of the model of the Hancock Tower with Bruce and Faz standing right next to it, equal partners. We’re all considered designers — architectural designs and structural designers. Many of our engineers have degrees in both architecture and engineering.

Dan: I think that picture says a lot. The decision factor is ingrained in that picture — the way they look at the building together, the way they worked together, their back-and-forth dynamic. When we worked on the Hangzhou project with Gary Haney [design partner] and Chuck Besjak [structural engineering director], we were sitting at a table and sketching together. Other firms have a hierarchy between architecture and engineering, while we’re all at the same table.

Neil: I think the most insulting thing an architect can say to an engineer is “make it work.” We don’t do that here.

---

Download the full article from The Changing Shape of Architecture: Further Cases of Integrating Research and Design in Practice here.

Originally Published on Medium

---

Article courtesy of SOM