Google’s BIM-busting App for Design and Construction

flux-1%20cityscape

By Randy Deutsch AIA LEED AP

Tom Preston-Werner, co-founder of Github, believes there will only be two types of jobs in the future: people who code computers, and people who get bossed around by computers.

“In the future there’s potentially two types of jobs: where you tell a machine what to do, programming a computer, or a machine is going to tell you what to do,” says Preston-Werner.

“You’re either the one that creates the automation or you’re getting automated.”

Remember the “Google[x] to revolutionize the construction industry” headlines from this time last year?

Google technology could halve construction costs

Google’s secret development unit has developed a technology that could earn the company $120 billion a year, and,

Is Google planning a BIM-busting app for construction?

Google_X

Google’s secret is secret no more

Flux, a 25 person, 2 year old company, the first — and so far only — startup to spin off of the semi-secret Google[x] research moonshot lab and incubator at Google dedicated to projects such as the driverless car and Google glass, has set out to automate the AEC industry.

It’s about time we take notice – and sides.

Google[x] is the company’s main initiative to diversify its sources of income.

With the global construction market estimated at $5 trillion a year, why not enter our turf?

First, a little background.

The Google X engineers initially called the development of the invention Genie (after the genie in Aladdin in “1001 Nights”). Genie, the development team told Google’s management, was a platform with online-based planning applications to help architects and engineers in the design process, especially for skyscrapers and large buildings. The platform includes planning tools of expert architects and engineers and advance analytics and simulation tools. Genie standardizes and automates the design and construction processes with unlimited design options, enabling an architect to preserve the building’s uniqueness in the urban environment.

In the report, the Google X team estimated that Genie could save 30-50% in prevailing construction costs and shorten the time from the start of planning to market by 30-60%. The Genie team estimated that the platform had the potential of generating $120 billion a year for Google, and so Flux was born.

michelle-kaufmannflux304xx592-395-0-3

Former Gehry Partners architect, Michelle Kaufmann, co-founded Flux with ex-Google software engineers Nick Chim (who is also CEO), Augusto Roman and Jen Carlile.

Flux says they are in business to address urban population growth.

In short: we’re going to increase our urban population in the next 35 years by 3.3B people – which nearly doubles our urban population from right now – and, depending on the size of the building, will require between 6.6 million and 33 million new apartment buildings by 2050 to house them all.

And so the need to see buildings not as one-offs, built from scratch, but from seeds.

tumblr_inline_naxjhgtW6q1sl6q34

Buildings as Mother Nature would want them to be

From a talk Jen Carlile, Co-Founder of Flux, gave in October 2014 at KeenCon,

Using Data to Improve the Built Environment:

Today we build individual buildings as though Mother Nature built each one from scratch, rather from seeds.

Flux asks: What if we were to build buildings from seeds? Seeds that took on different forms and characteristics depending upon where they were planted?

The thinking goes, if we designed this way, we could leverage data and design and build buildings by the thousands in the time it currently takes to design one.

flux%20austin

Tool #1: Coded within the building app are all the rules that the building needs to grow or auto-generate: the structural system, HVAC, façade, etc. It knows, for example, that it needs external sunscreens on the west elevation to reduce late afternoon heat gain. These rules are all encoded into the building seed. (See the video within the video that starts at 8:30.)

They use the analogy of the Monterey Cypress tree, which takes on a different shape based on where it is planted, the prevailing winds and conditions of its location and site.

cypress

In the same way that if you plant three separate Monterey Cypress seeds in three separate locations you’ll get three separate trees; if you place three separate building “seeds” in three separate locations you’ll get three separate buildings.

In other words, the building takes on different forms based on the different sites it is placed on.

The software “designs” all of the bathrooms, fire stairs, ducts. Because all of the rules are encoded within the building seed, you can make changes to the building. When you do that, the building regrows.

MontCypressSeedsHandRS

The seeds of change

To address the urban population crisis, says Jen Carlile, we need to stop designing individual buildings and start designing building seeds.

The time it takes to design and build needs to dramatically decrease.

Slide1

Tool #2: Another tool Flux built helps with organizing data, making it more actionable and more universally accessible. Think of it as a feasibility study algorithm that, once you identify a site or sites, instantaneously assesses entitlements, massing, building program, building performance, leasable area and overall project budget.

Simon Rees, Associate Principal / Structural Group Leader at Arup in Los Angeles, in a talk he gave in late October 2014 about a data-driven, integrated project named P12 that involved input from ARUP, Flux, Gensler, Cupertino Electric, Turner Construction, among others, calls this Wrangling Geometry from the data.

Slide2

Embracing the full complexity of the design and construction process, grounded in real estate data, P12’s goal was to reduce the design and construction of a large-scaled building to a 12 month cycle: 3 months for design, one for permitting, and 8 for construction.

They use the example of zoning codes that dictate what can be built on a site.

Slide3

The tool pulls in data from neighboring lots, buildings, vegetation. It looks at overlay zones, view corridors. Then it looks at the building code, generating the buildable envelope for a site.

Using downtown Austin, TX as an example, Flux’s software Metro purports to provide a better way to visualize Austin’s development code by

  • aggregating multiple data sources in one place: data from cities, tax assessors, and third-party sources, so you quickly understand the parameters for a land parcel;
  • helping developers and land owners to visualize their parcels by situating proposed projects into the surrounding landscape;
  • showing only the development codes that are applicable, including conditional overlays and uses; providing a quick assessment of project potential. “If and when you are ready to go deeper,” says the website, they’ll “provide helpful reference links to deeds, entitlement history, and permitting history.”
  • taking a snapshot of the project and share with anyone, getting stakeholders aligned around a common vision
  • rendering zoning incentive and building usage impacts on the parcel and massing.

Slide4

They make the process transparent so you can see where all of the data is coming from. So up on you monitor, as part of the tool, side by side with the building massing is the building or zoning code and all of the rules that can be derived from it.

As Simon Rees put it, browser-based exploration democratizes access to otherwise industry-specific information such as zoning codes and building models.

9v4MNCJl

Calling BF Skinner

After using the tool for a while, says Carlile, you can develop an intuition as to why the buildings are shaped the way they are. “What we often think of as artistic license is really just the manifestation of a rule set.” This represents one of the exciting ways that the data feedback loop can inform – and over time, improve – one’s intuition.

In the spirit of openly sharing technology in the software industry, making the design and construction process not only more transparent but more efficient, and reduce the time it takes to design and build buildings, Flux asks: What if there was a standard library where people could build upon the work of others, as opposed to solving the same problems over and over again?

We already have that technology: it’s called the human mind and memory.

I think the population growth storyline and Mother Nature metaphor don’t mask the underlying opportunity to best greedy developers at their own game by charging for this software as a service (SaaS.)

i.e. Free test-drive on 10 parcels $100 per additional parcel (introductory price.)

33 million buildings will be needed by 2050. That’s 33 million rules-based, design-by-constraints, deterministic, GMO seeds.

Constructors will be needed who know how to componentize, commoditize, and put the buildings together quickly.

The technology raises questions such as: Should humans be performing modeling tasks that a computer can perform?

I did feasibility studies for building developers most of my career and on most days I felt like I had the best, most creative job in the world.

Perhaps the biggest misunderstanding is that code searches aren’t drudgery that needs to be performed by computers. While the most cursory first looks can be made by computers, any building designer knows that interpreting the code – whether zoning or building – can be every bit as creative a task as designing the building itself. I have myself doubled the size of the allowable square footage of a project without seeking a variance based on nothing more than creative interpretation of the code. A computer can read a code, but it can’t read between the lines of a code book: only humans can.

The tools appear to be quite sophisticated. But a structural- nor software-engineer shouldn’t be touting the upside of these services or technologies. In the two presentations I have seen on the software, each look at a comprehensive, integrated system from their own narrow perspectives.

Flux needs someone as a spokesperson who sees the big picture. Someone who orchestrates large teams and knows the complete assemblage of building design and construction – not just from their silo, domain or point of view.

Something Jen said in the Q & A after her talk in particular hits home:

I think of it like APIs. You can have an API for a structural system. If you can connect your structural API to your fabrication machine, you no longer have to have humans involved.

For the foreseeable future, Flux’s Metro and other tools require the input of designers and other experts – in other words, human input. I wonder how team members such as Arup and Turner Construction would feel hearing that what they are contributing to may soon put them out of business?

More on where Flux is headed with all of this here.

Not building in Austin’s Central Business District? Subscribe to Flux’s mailing list to find out when they launch in your city. https://flux.io/metro/

Watch Jen Carlile, Co-Founder of Flux.

Read: Google X spin-out Flux is harnessing data to make designing buildings better.

Images: Flux

15 Comments

Filed under Uncategorized

The 7 Convergences in Contemporary Practice

by Randy Deutsch AIA LEED AP

Slide1Last summer over early morning coffee in Cambridge, Phil Bernstein – whom the past couple summers has joined me on the second day – asked me what I covered on the first day of my two-day Harvard GSD BIM leadership seminar.

So I gave him the run down. BIM as a database, interoperability, the seven convergences…

Wait. Again?

In all the times I’ve spoken with Phil, he had never before asked me to repeat myself.

So I listed them for him.

Oh those, he said distractedly – and returned to whatever he was doing.

It was then I knew I was onto something.

Background

The convergences in question have both practical and emergent antecedents.

Since the downturn in the economy in 2008, architects and other design professionals have been expected to design and construct in a manner that uses fewer resources, while still innovating, adding value and reducing waste.

Deliverables have to take less time, cost less money to produce, while not compromising on quality: expectations that are unrealistic at best, often resulting in a negative impact on outcomes, working relationships and experiences.

Old paradigms such as “Quality, Speed, & Price: pick any two”- no longer apply. Owners expect all three – Perfect, Now and Free – on almost every project. Traditional linear thinking no longer works in this converged upon world.

At the same time, emergent forces and technologies have come together in the second decade of the twenty-first century that have developed to the point where they make real-time integration of all facets of the design and construction process possible.

An unstructured, as of now unnamed group of twenty- and thirty-somethings have met the challenges and opportunities of this moment with skill, verve and aplomb (you know who you are.)

Closing Gaps vs. the Eternal Now

The metaphor of closing gaps is based on linear thinking: two events occurring in succession or transition are brought together or bridged.

With increasing demands to make decisions in real time, design professionals are moving beyond the linearity metaphor and thinking in terms of simultaneity, super-integration and convergence.

Emergent tools, work processes and the cloud make real-time convergence today a reality.

Those in academia, the design professions and industry are experiencing a tectonic shift approaching a real-time/right-time meeting point marked by multidisciplinary integration, intersections, interactions – and daresay collisions.

Because areas of professional expertise are converging on transdisciplinary teams increasingly made up of data scientists, computer scientists, mathematicians, sociologists, statisticians, strategists, scripters, and economists working alongside design professionals – it is no longer adequate for students of architecture, engineering and construction management, or for design and industry professionals, to strive to learn and master individualized skills.

Being proficient in any one domain – whether skill, technology or tool – is no longer sufficient. As I’ve written elsewhere, being proficient is no longer sufficient.

Adapting to the new world of work requires learning to think simultaneously on several fronts, and from several points of view.

This is the world of convergence thinking.

There are seven convergences in contemporary design practice that occur at the meeting of two seemingly opposite forces:

  • Virtual and Physical World
  • Data and Intuition
  • Parametrics and Computation
  • Visualization and Model
  • Design and Fabrication
  • Conception and Construction
  • The Practical and Ineffable

As this is a blog post, not a dissertation, here they are in capsule one at a time:

  1. Virtual and Physical World

Real-time tools enabling man-machine interaction in design and construction are being developed on the UIUC campus. Augmented Reality and Virtual Reality is entering the construction space with implications for how buildings are designed. Software now provides intuitive, real-time answers to wickedly complicated questions, which in turn enables much better decisions.

How can students of design and engineering, and their educators, work together to help leverage these tools throughout the building lifecycle?

  1. Data and Intuition

In lieu of buildings as buildings, or buildings as documents, we’re now seeing a convergence of buildings as data. Design firms are already leveraging data to make better decisions, bring about better insights, and make better buildings.

Where do employees who can do this – understand buildings as databases – come from? How are they learning to effectively and creatively accomplish this? Is this something that can be introduced in school or in practice?

Working with data and analytics not only informs, challenges and validates intuition, but over time changes (i.e. improves) intuition. Convergences such as the data/intuition feedback loop are quickly changing the way design professionals work, the way they think, communicate and interact with one another, and thus have implications for the way they learn, train, and practice.

  1. Parametrics and Computation

Existing BIM tools are in the process of becoming more computationally aware.

Converging parametrics and computational tools. We are now able to compare alternative building designs on the fly – in real time – assuring teams that they are on the right track, meeting the owner’s and building inhabitant’s criteria, comfort and needs from the start.

Converging processes and people. Using Grasshopper plug-ins like Platypus – developed by firm employees, not corporations, disseminated freely on Twitter, not via software resellers – individuals are now able to communicate and collaborate on the design of buildings in real time.

Are architects going to sit side by side with hackers, computer scientists and algorithm builders? Right now, several offices already have architects sitting side by side with hackers, computer scientists and algorithm builders. The future, in other words, is already here. Are we preparing our students for this future? Who will lead this effort? Who, in other words, will be the glue?

  1. Visualization and Model

Tools are currently being developed where visualization reacts directly to analysis, in the 3D model, without the need of producing additional reports.

What impact will this have on the way we currently teach structures, and the daylighting and energy analysis of buildings?

  1. Design and Fabrication

Convergence of design and fabrication. University, not trade school, students today learn to operate robotic arm fabrication equipment directly from their CAD and BIM software.

What are the implications for not only education and practice, but for the trades and industry?

  1. Conception and Construction

After winning the international design competition, it took Jørn Utzon 6 years to figure out how to build the Sydney Opera House shell structures, and by that time he was no longer on speaking terms with the client or the contractor.

Flash forward 50 years: Nathan Miller as the lead computational designer, and later Andrew Heumann, leader of NBBJ’s design computational group, designed, fabricated and all but constructed the Hangzhou Stadium from their laptops.

How are the boundaries between two historically separate entities, design and construction, converging? What are the implications for the way we learn? For the way we practice?

  1. The Practical and Ineffable

As David Ross Scheer has discovered design professionals are increasingly challenged to realize meaning and agency within the constraints of computational tools.

Who are the individuals that are succeeding at this need for the transference and making of meaning brought about by increasing convergence of technology, tools and processes?

Implications for education

The seven convergences have implications for both education and practice.

Convergence requires multidisciplinary participation, merging STEM subjects with those in design and the arts.

We need to educate designers to work compatibly and effectively with those from across different domains and fields.

Like it or not, this is where design practice is heading: we need to understand the implications for education and training, research and development.

Implications for practice

Architecture is a complex undertaking requiring the input of many individuals with varying interests, backgrounds and expertise. This has not – and will not – change.

What is changing is the way these individuals are working, communicating and collaborating. Their individual contributions are converging. In response, they are integrating their efforts – not multitasking. To meet today’s demands for speed, affordability and quality – they are taking and making smart cuts, not shortcuts.

They are currently learning to do this at conferences, at informal meet-ups, in online forums, via gaming, and in social media.

If you aren’t in the Grasshopper forum, or follow them on Twitter, a whole epoch might pass you by.

The linear design process transforms – and increasingly tightens – as a result of the introduction of convergences in contemporary design practice workflows.

A new book

There is a need to clarify and concretize what is happening at this moment in time for those who aren’t following.

Books – whether physical, digital or audio – are seen by some as antiquated technology. But in the middle of the second decade of the third millennium, they are still the best means we have for synthesizing moments and movements, giving them a name, and as importantly, a language that can be understood, shared and discussed by others.

The seven convergences will be explored in a new book I will be writing in 2015.

For those keeping score, convergence is the next natural succession in the research from my previous two books on building information modeling (BIM,) and data analytics in the AEC industry.

Specifically, the practice-based research for this new book aligns with, grows out of, and builds on my current research on the collaborative leveraging of data in design that has led to my in-progress book, “Data Driven Design and Construction: Strategies for Capturing, Analyzing and Applying Building Data,” (John Wiley & Sons, 2015) a +400 pp. publication providing practical information, useful strategies and technical guidance to practitioners, educators and students who are looking to leverage data throughout the building lifecycle.

As a meditation on the impact of technology on the education and making of design professionals, this new book – Convergence – can go a long way to help explain what is happening now in the world of design, as well as to discuss the implications for the future of practice.

I would love to hear from you. Anyone

  • for whom this topic strikes a chord, rings true, captures the zeitgeist
  • who works in any of these areas, or knows someone who does
  • who thinks there are too many listed, or sees something missing
  • who has something to say on this topic.

Email me at rdeutsch@illinois.edu or let me know by leaving a comment below.

1 Comment

Filed under Uncategorized

Design Smart. Build Smart. Live well.

stepsNote: Today’s posts are by guest blogger Elijah Gregory, a high school senior interested in all things BIM. If Elijah represents the future of our industry, we’ll be in good hands.

The Purpose of BIM: IPD to Life Cycle Management

When envisioning the future through the eyes of an early 2000’s film, we see men dressed in sharp, all-black suits, women in sleek, all-black dresses, and almost all business processes completed virtually. Phone calls are made through technological-emulated telepathy, balance sheets are brought up and thrown around a corporate board room on a series of screens mirroring a Tony Stark creation, and we see security officers responding to seeing breeches in a building through a hologram. The hologram always struck me: how could the security officers see through the entire building and manipulate the model? How did they know where the attackers were? Of course, the concept, Hollywood animation at the time, is encroaching upon reality. The future of BIM lies in life cycle management.

Currently BIM acts just as the acronym implies, for modeling of a building and information extraction from the model. The system works from the Integrated Project Delivery (IPD) process of construction which ties together architects, engineers, construction companies and owners. Through BIM, all stakeholders in the construction of a building can contribute.

Architects typically rely on the modeling aspect of BIM. Through the software, architects can create the drawings of the building, a model of the building (of course), a virtual walkthrough of the building for the client, as well as a vast array of visual aspects to the overall design of the building. The modeling aspect of BIM currently contributes the majority of the current use of the software. Of course, the information derived from models produced by BIM still plays an incredibly important role—and arguably the most important role, depending on which stakeholder you are in the process. The information is used to create estimates and schedules, decide on critical points in the construction of the building, and ultimately to sell the building to the owner and make a profit for the CM firm.

The current state of BIM is incredible: over the last two decades, construction has changed more than in the last two millennia, and largely due to the adoption of the software. BIM has always been about streamlining data and communications from a construction aspect, but the future of BIM takes streamlining one step further—to interoperability from the erectors, to owners, maintenance men, and end users of the building.

Life cycle management through BIM allows the model and information to be leveraged throughout the entire life of the building. From the software, owners could schedule maintenance and users could plan additions or analyze energy usage for sustainability. Of course, for the simple interoperability to occur, BIM must be simplified immensely to a substantially more user-friendly level–a feat not easily conquered. Although seemingly far-off, the conceptual days of holographic building manipulation via the streamlined usage from IPD to life cycle management through BIM are quickly approaching.

On the Horizon of BIM

All too often I find myself nearly completed with a project in Revit and I realize my lack of adding information into the model. I need summaries of costs associated with the materials in the building, cost per square foot, panel schedules, optimizations of the model, energy analysis and a whole host of information-driven items, which all too often I cannot create quickly due to my lack of using the tool to the full potential.

Of course, all the information discrepancy lies in the lack of identity data for the various components in my building design. From there, a breakdown of room costs, overall building costs, energy analysis, and all other comparative and analysis functions Revit can do, Revit then can do.

As a high school senior with limited experience and education with the data associated with the intricacies of flow rates for MEP systems, cost data, or Uniformat, I am highly unable to create information for the components which Revit requires to analyze. And although I am in no regards a professional architect, I suspect architects and common users of Revit know all of the needed information either.

The design of a building alone stands as nothing less than a masterpiece. All the information associated with the design can stand as much more: smart.

Currently, very limited standards exist for BIM software. Such a lack creates inequalities in depth of design for both the building and more prominently the components within the building.

In an attempt to create a community workspace for BIM operators in which to share families and components, Autodesk created Autodesk Seek.

Although the components from the online warehouse can serve the purpose of design or layout, more often than not, the models come very generically information wise if drawn by Autodesk or loaded with intricate, unexplainable parameters, poor constraints, and a lack of cost data if drawn by a manufacturer.

Needless to say, the two very different levels of information causes some issues down the road in the design to delivery cycle.

The future of design lies in an operation-to-drawing-board approach. The user comes first. Inasmuch, a standard upon which to design from BIM-wise sees all the more calling as the future draws near.

With the rivalries for market share never ending, I cannot imagine a full-tilt, industry-wide warehouse upon which components for the various BIM software may arise in the near future. But with Autodesk’s innovative nature and record, a calling for standards of acceptance to Seek does not appear out of line.

The cliché proves timeless: we are on the cusp of something great. Hopefully, with the trend of BIM acceptance and implementation, standards do not live so far in the distance. Design smart. Build smart. Live great.

Thank you Elijah Gregory for your dedication to BIM and collaboration, and for writing these great posts! You can read more of Elijah’s writing on all things BIM at Sean D Burke’s blog Paradigm Shift http://www.seandburke.com/blog/2014/09/02/the-vdc-cycle-leveraging-the-i-in-bim/

5 Comments

Filed under Uncategorized

IPD: The Missing Manual

Missing ManualMy first impression after reading The Owners’ Guide to Starting Integrated Building Projects by Oscia Wilson is that it is much more than a guide for building owners. This easy to read handbook will guide anyone interested in either pursuing this important and still little used collaborative project delivery approach – integrated project delivery or (IPD) – as well as those interested in gaining a better understanding of its methodology, to be better informed and prepared to explain it to others.
The book has its roots in social media, in that it originated as a LinkedIn discussion, with many expert voices adding their two cents to the discussion. It soon became apparent that what was needed was an IPD users manual, and after some toil, as the discussion grew and grew, this must-have book was born.
San Francisco architect Oscia Wilson envisioned turning the outcome of that very valuable online discussion onto a much needed owner’s guide, several integrated project delivery experts volunteered to contribute, and what ensued – the book I hold in my hand – turned out to be much more than the sum of its parts.

While Oscia’s name is the only one that appears on the cover of the book, in true IPD spirit, the inspiration for the book was crowdsourced – integrating the expert advice, experience, knowledge, colorful anecdotes, judgment, and hard-won wisdom – of several excellent, big-name building industry contributors (all listed and acknowledged inside the front cover.)

Wilson wisely kept the length of the book down – it can easily be read in one or two sittings. Owners are busy people, and they want to get to the goods, the facts, sooner than later, so keeping the book slim was probably a wise choice. That said, the book maybe could have used more of a preface or introduction, to provide a little background – explaining, for example, why there’s a need for an owner’s guide (owners most often decide on the project delivery method for a project) and why not an architect’s guide or contractor’s guide. Also, for all of the rich content and comprehensive covering of topics, I was surprised that there wasn’t a mention of the several hybrid approaches to IPD that many firms have taken-up when IPD itself is not an option, including the so-called IPD-ish and IPD-lite workarounds which are pulled out when one can’t pursue IPD for legal or insurance (or just plain risk-aversion) reasons. Perhaps the author didn’t want to give Owners the option to duck out of using IPD pure and proper? That said, the book does have an excellent section on What To Do If You Can’t Do IPD which offers some excellent alternative approaches and tactics.

If, like owners, the goods are what you are after, the book is chock full of excellent collaboration-related tips, techniques, talking-points and step-by-step processes. More than an owner’s manual, this book could be thought of as an IPD Users Guide which should appeal to a much wider readership. This easy-on-the-eyes book is itself a beautiful object – well worth owning for its considerable contents as it is for the attractive cover, the clear and well-illustrated color graphics, and the closing invitation to add to the continuing conversation. Everyone in the building industry will benefit from reading – and rereading – The Owners’ Guide to Starting Integrated Building Projects.

You can find Oscia Wilson’s five-star book here on Amazon http://www.amazon.com/Owners-Starting-Integrated-Building-Projects/dp/1499627327

3 Comments

Filed under Uncategorized

The Death of the Death of the Death of Drawing

death drawingDrawing is far from over. It’s not even close to dead. Not by a long shot.

Just to make sure, I just tweeted: ‘Is drawing dead?’

Death of Drawing anyone?

‏‪Case Inc’s @davidfano immediately tweeted back: no :)

‪@JayZallan Agreed: no. Next.

‪Chicago architect-in-the-making @joshuamings tweeted: nope. I’m heading out the door to sketch Alfred Caldwell’s Lily Pool and maybe Studio Gang’s pavilion in Lincoln Park.

Mexico City’s ‪@Rodrigo_Medina replied: Drawing will always have its practical applications, thinking it is enough is where I see the real problem.

‪@Parthenon1 Silly question?

‪The serially successful “Ignore Everybody: and 39 Other Keys to Creativity” author @gapingvoid tweeted: I would say that was an extremely silly question. But I’m old school :D

You get the idea.

Readers may recall the 2012 NYTimes article by architect Michael Graves “Architecture and the Lost Art of Drawing” which declared:

“It has become fashionable in many architectural circles to declare the death of drawing.”

And then asked:

“What has happened to our profession, and our art, to cause the supposed end of our most powerful means of conceptualizing and representing architecture?”

Says Graves,

“The computer, of course.”

David Ross Scheer, in his new book The Death of Drawing, also answers this question in terms of technology.

Only his answer is book-length, well-illustrated, and extremely relevant for our age.

And I recommend that you purchase a copy, read and discuss it (with only one reservation, which I’ll get to in a moment.)

One look at the six chapter titles in the book’s Table of Contents will speak to the book’s immediacy and relevance, and should help you determine whether this book is for you.

I suspect many of my blog readers and Twitter followers will find these chapter headings both pertinent and compelling:

1 Representation and Simulation 19

2 Drawing and Architecture 49

3 Building Information Modeling 101

4 Computational Design 129

5 Simulation and Architecture 165

6 Simulation and Ideation 193

Earlier drafts of the book’s chapters, the author tells us, were reviewed by Chuck Eastman, Ole Fischer, Daniel Friedman, and Michael Sorkin, a formidable group of scholars and speaks to the author’s pedigree.

Thesis, Purpose, Goal, and Central Argument? Oh my.

Scheer’s thesis will be self-apparent to those who are living it, anxiety-inducing for others:

“I believe that we are in the midst of a transformation that will ultimately reshape architecture to an extent not seen in over 500 years.”

He goes on to explain the book’s purpose:

“These changes reflect the incorporation of architecture and the building industry as a whole into a pervasive social and cultural movement towards virtualization and predictive control through digital simulation. Architects need to understand why this is happening and its effects on how we think and work if we want to continue shape the design of the built environment. This, in a nutshell, is the purpose of this book.”

Elsewhere, Scheer asks:

If architecture loses the idea of representation, how will buildings acquire meaning?

Architects have infused their designs with meaning for ages. But drawing is not the only means by which meaning is actualized. In fact, as with all communication, meaning is a two-way street: the building user and the public at large have some say in the matter. And the meaning they interpret may not be the meaning the architect intended (just think of Venturi’s Princeton Biology Building nicknamed the Purina building for the building’s elaborate brick pattern recalling the Ralston Purina checkerboard logo.)

A great deal of a building’s meaning is acquired not through any effort on the architect’s part, but on the building’s immediate context.

How does the architect know that the meaning they implied was received as intended? What role does genus loci – the spirit of the place in which the building is built, inform the building’s meaning? Is it naïve to think that buildings acquire meaning from the architect’s skill at drawing or from the drawing alone?

Society looks to architects’ buildings to be somehow significant even as it diminishes their ability to do so

Early in the book, Scheer says that he “believes” that BIM and computational design “will ultimately replace drawing as the medium of architecture and the construction industry.”

There’s no reason to “believe” this. It is 2014 and this has already happened. At least in terms of deliverables and documentation, if not – per the tweets above – in terms of how architects converse with themselves.

A few pages later, Scheer states that “this book’s goal is to stimulate debate about the future of the discipline of architecture and inform decisions about its direction.”

One expects that The Death of Drawing will inevitably lead to such discussion – in the studio, in coffeehouses, in schools and in the office.

Simulation and The Author’s Discontents

Scheer next states:

“My central argument is that the relationship between design and reality is undergoing a shift from representation to simulation and that this shift has many profound implications for architecture.”

My one gripe with Scheer’s book is its lack of context. Why is this shift happening? One would expect to find a mention of 9/11 and the subsequent reality hunger that ensued in the arts and service professions? Or a reference to the 2008 economic downturn that perhaps might have led to the need for firms to increasingly simulate in order to differentiate themselves and provide themselves with a competitive advantage?

The fact that nonfiction, these days, trumps fiction every time. And that the architect of representation practiced a refined form of fiction.

Until the fiction is objectified, justified or otherwise backed up with data.

This lack of reference to the outside world – especially given the book’s topics of BIM, computational design and simulation, is disconcerting.

Especially considering we’re living in an Age of Context.

Subjective statements – as well as Theses, Purposes, Goals, and Central Arguments – remain subjective until placed into a larger context.

As with buildings, without that context for reference, they lose meaning.

A book’s argument – any research actually – is a claim backed by reasons based on evidence.

With its thesis, purpose, goal, central argument, this book is not short of claims.

And the reasons – however personal – are there as well.

But the book, despite its wealth of beautiful images, lacks evidence. All we have is the author’s word and a veritable cornucopia of drawings to enjoy.

Due to the lack of evidence backing up the author’s claims, the book almost reads at times like it is a museum exhibition catalogue.

Scheer’s book doesn’t, for example, reference Grave’s article mentioned in the opening of this post, nor any of the other online arguments that spawned from it.

Nor does the book reference the 2012 Yale symposium entitled, of all things, ‘Is Drawing Dead?’

The fact that David Ross Scheer received his Master of Architecture degree from Yale University – it’s mentioned on page 1 – is not lost on the reader or reviewer.

It doesn’t reference MIT’s former Architecture Department Chairman, William J. Mitchell “The Death of Drawing” in the UCLA Architecture Journal 2 (1989)

Nor does it dip into social media. Forget Twitter. See for example, Lee Castili’s thoughtful post What is the drawing’s purpose?

Scheer, for example, states that “Skill in drawing has been the hallmark of the profession.”

But as with so much that is said in the book, we have to take the author’s word for it.

It doesn’t pass the otherwiseness test: What about other hallmarks of the profession, such as problem defining and solving, seeing the big picture, understanding how local decisions have global impacts, or envisioning what others can’t see? Don’t these count?

Simulation is the Enemy

Every good story has a protagonist and antagonist. Scheer’s real war in the book is with simulation. Simulation, he explains, that exists to anticipate building performance.

“Drawing and simulation entail vastly different attitudes on the part of the architect. In fact, the shift in attitude is more important for architecture than the actual uses of a given simulation. Once an architect decides to work in simulation, the values implicit in drawing no longer apply.”

The architect Scheer describes comes across as “as a wielder of information rather than a creator of form.”

He elsewhere writes “computational design is directly concerned with the generation of form.”

Except for when it is concerned with building performance or human performance.

But whether building geometry, building performance or human performance data and information are equally data. In other words, information and form are not separate activities, but integrated and interdependent.

Design integration doesn’t fare well in the book either:

“With all information in a readily transmissible form, there are great incentives to share it more freely, resulting in a leveling of the design team and a consequent redefinition of the architect’s role within it.”

This explanation of integrated design is exactly backwards. Designers aren’t encouraged to share because their work is in a form that is sharable. They share because the other – analogue, drawing – methods didn’t work.

They share information because clients require them to do so. They share information to avoid clashes in the field, cost and schedule overruns, tension in the field, finger pointing and poor relations between team members.

The earlier methods – however good they look in galleries, museums, and books such as this – led to a loss of productivity in the profession and industry. So bad, that many other fields have popped up vying for the opportunity to outdo designers and contractors at their own game.

Watching Michael Graves sketch on bumwad was a lot more fun.

But it didn’t work.

An Elegy for the Architectural Drawing?

There is a romantic notion throughout the book of the lost halcyon days of paper architecture, hand sketching, and perhaps even drafting.

And from what I recall from my 30-year career as a building designer, form-for-form’s-sake wasn’t an especially strong argument for justifying one’s course of design action.

Scheer is all for representation. He states emphatically, “Representation and simulation are incompatible modes of experience.”

In fact, firms like Thornton Tomasetti and their research arm, CORE Studio, have created software and apps, such as TTX, that serve simultaneously as both representational and simulation tools.

Scheer anticipates this when, later in the book, he writes “simulation is as much an orientation towards experience as it is a process. The same simulation can be taken at face value by some and regarded as representation by others.”

He next writes “An architectural simulation behaves like a building—it gives the same results as a building when tested in specified ways.”

If only that were the case. There have been many instances where LEED did not predict energy savings outcomes in the built building.

Again, the book here is weak on context. Surprisingly, Sherry Turkle’s seminal Simulation and Its Discontents is listed under Bibliography and Further Reading but not referenced in the book.

About a third of the way into the book Scheer asks, however rhetorically:

Is representation good and simulation bad?

His answer, perhaps more than anything else in the book, states his case:

The question, he says, makes no sense.

David Ross Scheer’s The Death of Drawing comes out in July, 2014 and can be found here

The Death of Drawing Website and blog http://deathofdrawing.com

4 Comments

Filed under Uncategorized

Too Complex and Fast? Slow Down, But Don’t Oversimplify

oversimplifyTo lead our collaborative future, architects need to decentralize or risk being further marginalized.

Architects know that they need to collaborate to succeed. But how will they go about doing it? How, in other words, will they make collaboration happen? As importantly, how will architects make the changes necessary to become not only more collaborative, but leaders of this effort, amidst disruptive change?

AEC leaders already do a great deal to encourage collaboration amongst their teams, providing vision, collaboration-conducive work environments, collaboration technology, and by removing obstacles – including themselves –when necessary, gladly getting out of everyone’s way. They encourage diversity, discussion – even disagreements – as a basis for moving the project forward. By telling their collaboration stories, leaders paint a picture of what collaboration looks like when it is done well. Most importantly, AEC leaders make sure every team member is making the same project. But AEC leaders cannot assure this happens in every meeting on every project. Who, then, on the team will lead the day-to-day collaboration challenge?

Barriers to Collaboration

We know collaboration is hard and takes time — to build relationships, to clear-up misunderstandings, to listen and to get things done. Past experience can hold teams back, and one of the barriers to collaboration remains organizational silos.

Brand erosion is also an impediment to collaboration. For a designer whose singular voice is her expression through her work, collaboration is equated with joint authorship, to some the antithesis of creative expression, muddying the message of the work, dispersing and diluting the voice and design intent of the creator. This thinking is of course mistaken, as leaders need to make clear. One only needs to compare a Beatles tune with any of the band member’s solo efforts to recognize that teams make better decisions – and importantly, results – than individuals. The real fear in collaborating is that we – and our work – will be mediocre, a race toward the lowest common denominator, and with it, irrelevance: we will be seen as just one more designer among designers.

The truth, of course, is by not collaborating architects become marginalized. Not knowing how to effectively collaborate will lead to their irrelevance.

Complexity and Speed

Of the trends impacting our new world of work – including digital tools, collaborative work processes with attendant blurring of roles and responsibilities, working remotely and together earlier – two trends have made all the others a necessity: complexity and speed. Our technology has an impact on the anticipated speed of decision-making. When still hand-drafting, while facing a construction-related question or dilemma, architects would say: We’ll work it out in the field. This was the architect’s go-to VIF: where the contractor on the architect’s behalf would be expected to Verify In Field. Later, working in CAD, architects would say: We’ll work it out in shop drawings. With little bim: We’ll work it out in CDs. And today, with social BIM, We need to work it out NOW!

In the face of increased project speed, we will be tempted to slow down. And we are well advised to do so. Studies show to make decisions that stick, we’re better off delaying choices for as long as practically possible. According to Frank Partnoy in Wait: The Art and Science of Delay, the best professionals understand how long they have available to make a decision, and then, given that time frame, they wait as long as they possibly can: “we are hard-wired to react quickly. Yet we are often better off resisting both biology and technology.” Since our current technology and integrated work process does not accommodate our waiting – in fact, it discourages it – leaders need to make it safe for their teams to make assured, unrushed decisions.

Likewise, despite construction being wickedly complicated, we should not be tempted to oversimplify. We need to take the complex and make it seem simple – without oversimplifying – resisting the temptation to treat a complex task as simpler than it is, potentially leading to oversights and mistakes.

Decentralize or be Marginalized

Architects continue to see themselves as central to decision-making, whether at the top of the project pyramid or a prominent point of the team triangle. Contracts notwithstanding, architects are not the point. For collaboration to work, architects need to get off the pyramid and go wherever and whenever they are needed.

Decentralization implies the transfer of authority from central to local offshoots who represent the firm and serve as its public face, whether as project manager, project architect or project designer – sometimes any two, or all three. These offshoots – like starfish arms – contain the complete DNA and trust of the organization.

Although collaboration requires the architect to decentralize, it has to start at the top, where firm leaders entrust employees to lead teams. What will it take for architects to decentralize? Successful collaboration requires facilitative leadership. For the architect to take on this role, they must play the part of process facilitators over content creators, becoming in essence co-creators. When each teammate contributes as a co-creator, no single person has to carry the load, including the leader. Decentralization allows architects to join the project – and be immediately effective – midstream. Ideally, the architect is called in before the owner even considers undertaking a building project, but the reality is – due in no small part to their own making – the architect is often called upon when the project is already well underway.

Given the collaborative nature of today’s project teams, consideration needs to be given to the firm representative’s leadership and communication style. As proxy stand-ins for the firm, each team leader needs to be able to communicate effectively at all times, with all in the room. Architects’ often-unconscious communication habits will be increasingly scrutinized and decreasingly tolerated in these tight-knit groups. Architects, working more closely with others from every facet of practice, will need to become more familiar with their communication style, paying particular attention to the ability to adjust one’s style to those of others from other work cultures and walks of life.

FOCI: Multiple-centered – not centerless – leadership

Architects – seeing that others have helped narrow their options significantly – narrow them further by opting to see themselves as single purpose entities. One example of this is described in Victoria Beach’s salvo in the newly published 15th edition of the Architect’s Handbook of Professional Practice where she asks architects to see themselves more as design-focused celebrity chefs and less as engineers assuring the health, safety and welfare of the public. For architects, it’s a both/and, not either/or, proposition.

In fact, architects in the coming years will be needed less as content providers of design intent than as facilitators, orchestrators, collaborators and integrators (or FOCI) of this information and process. Architects will have an opportunity to lead this process if they can learn to become better listeners, aggregators and refiners of the information that arises during the various stages of design and construction.

With the blurring of roles brought about by working collaboratively on integrated teams, the architect’s job is to keep decisions – often multiple decisions – in play. Collaboration and digital practice require a formwork on which to base multi-faceted decisions on increasingly complex projects. One such formwork is that of the rubric FOCI: in lieu of a singular central focus of the center, think of the multiple centers of the ellipse. A redefinition of decision-making that takes digital technology and collaboration into consideration creates such a formwork that will help the architect to communicate effectively with multi-disciplinary teams. To move from a circular to an elliptical model, the architect needs to decentralize.

To decentralize, architects also need to move away from the spotlight where they are the central focus. Many architects are introverts and would gladly succumb the spotlight to others. Architects don’t need to be the loudest one in the room to lead, just the one who listens best. To accomplish this, architects need to focus less, and FOCI more, by serving as project facilitators, orchestrators, collaborators and integrators. By decentralizing, the architect is no longer decision-maker so much as facilitator of project information and decision-making process. As facilitative leaders, architects can become experts in knowing how to find information as opposed to what the information is. When collaborating, it is not about how much any one person happens to know: projects today are too complex for any one person to know everything. Knowing from whom – and where – on the team to find information is more important than one’s ability to store and retrieve it. Architects will also serve as strategic orchestrators of large teams from the earliest stages, often made up with primary, secondary and even tertiary players. The C in FOCI is in flux: the C can represent collaborators or creators or controllers or coordinators. Architects, of course, are component and system integrators.

This post is an excerpt from Randy Deutsch’s article How We Can Make Collaboration Work: How architects can decentralize rather than be marginalized in the Jan-Feb 2014 Trends issue of DesignIntelligence journal.

Read and visit DesignIntelligence.

2 Comments

Filed under collaboration, construction industry, design professionals, people, process

6 Qualities That Make Architects Ideally Suited to Lead Collaborative Integrated Teams

leadersIn order to effectively lead collaborative teams, architects would do well to downplay possessing specialized knowledge. Knowledge acquired in school and practice should be thought of as the price of admission, not their “Advance to GO” card, as so many on the team in this connected age have access to and share this same knowledge. Along with specialized knowledge, as a professional duty of practice, architects will also need to reevaluate the role of professional judgment, design intent, responsible control, direct supervision, and serving as the hander-down of rulings in the shape-shifting required from working simultaneously on collaborative teams.

Recognizing that nothing incites a non-architect’s derision, ridicule and ire swifter than to start a sentence “The architect is uniquely qualified to…” here are six qualities that make architects ideally suited to lead collaborative, integrated teams:

1. Architects can lead collaborative teams by tapping into their ability to maintain two or more opposing thoughts until an amenable solution arises. Roger Martin’s The Opposable Mind, on the problem-solving power of integrative thinking, describes the human brain’s ability “to hold two conflicting ideas in constructive tension.” Like F. Scott Fitzgerald’s test of a first-rate intelligence as “the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function,” architects need to become even more comfortable working with and maintaining two or more opposing thoughts earlier in their careers. Architects famously can simultaneously maintain two lines of thought – e.g. their own and their client’s; their client’s and that of the public-at-large; the paying client and the non-paying client; the 99% and the 1%; the circumstantial and the ideal; science and art; reason and intuition; evidence and the ineffable; HSW and aesthetics; practical and dreamer. In an interview with the author, Phil Bernstein described the difference between young designers and older designers as the ability to manage an increasingly larger set of variables: “When I was working for Cesar Pelli, that was one of the amazing things about him – he could keep so many things in his head and he could balance them and weigh one against the other, and he could edit out what he called the systematic generation of useless alternatives. He would prevent us from going down that avenue.”

2. Architects are problem identifiers. Not only problem solvers, architects recognize that identifying the right problem to solve is often 80% of the solution. Frequently, the problem assigned is not the one that truly requires addressing. Architects work to make sure that everyone is focused on the most pressing, pertinent problem.

3. Architects see the big picture. Solution-oriented engineers sometimes have a difficult time seeing the forest from the trees. Malcolm Gladwell in Blink called this ability to see information in its wider context coup d’oeilcourt sense or “giss,” the power of the glance, the ability to immediately make sense of situations. Architects, by the end of their formal training, have begun to develop this ability, by thinking laterally and simultaneously – not linearly. Neither exclusively right- nor left- – architects are whole-brain thinkers. In the midst of prolonged analysis, architects can help to keep things whole.

4. Architects draw by hand, mouse and wand. Creatively ambidextrous, flexible and agile, architects are not stuck on any one means of communication or delivery. Architects make the best use of available technology to get the point across. Because architects envision what is not there, they help bring nascent ideas to life. Today, we cannot talk of leadership without the technology. We lead from the technology and the tools we use. In this way, architects lead collaboration from the middle by leading from the model.

5. Architects can lead collaborative teams by thinking like other team members, anticipating their concerns and questions before they arise. Architects see through other’s eyes, empathize and understand what is important to others. They have both deep skills and wide wingspan breadth. Architects are the only entity who serve not only the paying but non-paying client (society-at-large.) In trying to predict the consequences for any course of action, the architect needs to anticipate the responses of each of the integrated team members. To do this, an architect must know enough about each discipline to negotiate and synthesize competing demands.

6. Architects don’t lead collaborative teams because of their specialized skills, technology know-how, or privileged knowledge, but rather because of their comfort with ambiguity and uncertainty. Architects are best suited to lead collaborative teams by being able to extrapolate from incomplete information, and won’t let the lack of complete information stop them from moving forward.

The architect leading collaborative teams has implications for education in that independently trained professionals are inclined to remain independent in practice. According to NCARB’s contribution to the NAAB 2013 Accreditation Review Conference (ARC), over 80% of architects rated “collaboration with stakeholders” as important/critical, yet only 31.5% of interns and recently licensed architects indicated they had performed collaboratively prior to completion of their education program. This would need to change.

Let the Team be the Architect

The single most important issue confronting AEC leadership is, as Michael Schrage asked, how to pose problems and opportunities in forms that will elicit and inspire a collaborative response. Consultant Ed Friedrichs describes this as the ability “to inspire an entire team of participants to collaborate, to contribute the best they have to offer, in order to bring value to a client.”

Concerning collaborative teams, leaders need to ask of themselves – as well as prospective hires – are you the glue or the solvent? If architects are to be respected as leaders, their challenge is to communicate with their collaborators as equal partners in design.

In his book Architecture by Team, CRS’s William Caudill wrote: “The so called ‘great man’ approach must give way to the great team approach. From now on the great architects will be on great interdisciplinary teams.”

That was written in 1971. Buried on page 288 is the title of Chapter 109:

“Let the team – designers, manufacturers and builders – be the architect.”

So let the team be the architect, and the architect be the facilitative leader. And act soon, for we may not have another 40 years to see this out.

This post is an excerpt from Randy Deutsch’s article How We Can Make Collaboration Work: How architects can decentralize rather than be marginalized in the Jan-Feb 2014 Trends issue of DesignIntelligence journal.

Read and visit DesignIntelligence.

4 Comments

Filed under collaboration, construction industry, design professionals, education, Integrated Design, Integrated Project Delivery, IPD, people, process