Monthly Archives: August 2012

Repost: Dear architecture school, please tell us it is ok to do this.

August 28, 2012 By in Process Leave a comment

Originally posted on ArchDaily on May 31st, 2011 (Link)

Image source: Treehugger

by Federico Negro

It seems as though a week doesn’t go by these days without someone asking me if I miss design…

Two and a half years ago I made the decision to leave the traditional path, and cross over to the dark side. I became a consultant (cut to dark stormy clouds and lightning). A technology consultant nonetheless… As such, my contributions to Practice 2.0 will focus on the impact of technology on issues of management during the latter stages of building design and construction.

Since then I’ve had the privilege, the luck even, to sit across the table from designers working for some of the biggest names in building design, engineering and construction both in New York and beyond. I’ve reviewed innumerable sets of diligently constructed documents and building models. I’ve crossed paths with many fascinating designers creating real impact through their work. And most importantly, I’ve had the opportunity to work alongside many brilliant young professionals, a few of which will no doubt lead the New York design scene in the coming years…

If there is one thing that I can tell you about me is that I love buildings (noun) and I love building (verb) and I’m entrenched in the process making buildings every day. How will this be built and how can technology help? …are the central questions concerning my daily work.

So why am I still being asked if I miss design? Why did I have a sense of guilt when leaving the architecture office to focus on what I thought would be a challenging and rewarding path? Was I not being true to the ideals that attracted me to the profession to begin with?

In her upcoming article for Harvard Design Magazine, GSD Prof. Danielle Etzler stipulates that “If our best and our brightest recent graduates applied themselves to the project of building not only through the offices of architects but also through employment with our government, clients, construction managers, and consultants, in a single generation we would increase the quality of our built environment and instill values that establish architecture as an irreplaceable cultural currency. […] If we can imagine that we wouldn’t stop being architects by taking jobs wherever we can influence decisions related to buildings, our influence would grow exponentially.” (Danielle Etzler, Harvard Design Magazine #34, Spring 2011)

Considering the challenges facing the built environment in the coming years and decades then, it seems logical that good, high-level spatial thinkers and managers be in demand to fill positions of influence alongside building scientists, urban planners, etc… But the range of specialized knowledge needed to tackle problems like building performance and process inefficiency is vast and often misunderstood.

We must then, be excited about the possibilities of such pursuits and encourage young architects to pursue them without remorse if we are to impact the built environment at a large scale (as it is needed). What’s more, the construction industry has failed to keep up with increased productivity of other industrial sectors over the past five decades (Link, link, and link). Though there are many reasons for this, our industry’s relationship with technology is singled out as one of the main causes. Why have we been so quick to dismiss it?

This should scream out to us as professionals and to the academy as an immense opportunity, considering the technological advances of other industries over the same period (PCs, the internet, and Quadrocopters). So, while some focus on ‘regaining’ some romantic notion of control, we should instead realize that architects already have incredible power. The power to determine a vision, to set a path, to influence, to build teams, to specify, to solve problems, to lead.. We just need to be shown that not only is it ok to pursue these opportunities, it is also our responsibility.

In addition, those who focus on building information, energy, systems integration, constructability, simulation and other model-based fields should continue to see high demand (even in the midst of continued bad billings news). Architects with these skills are uniquely positioned to lead teams of experts that will not only work alongside those in traditional roles, but will also no doubt create a new class of building industry entrepreneurs unbound by traditional rules of practice.

So no, I don’t miss design. I don’t miss it because I don’t believe I ever left it. Segregating the processes that go into getting something built from what seems to be the commonplace definition of design will only continue to produce un-integrated buildings. These will do little to give architects their much deserved voice amongst those who will define the future of our built environment.

If you have examples of schools, people, companies, or communities that are creating new opportunities and expanding our business reach while providing a much needed service / product and are using technology to do so, please let us know – we’d love to hear it…

Level of Development (LOD) is updated in E203

August 21, 2012 By in Building Information, Process Tags: , , , 3 Comments

In the past few months, I’ve been involved in several conversations on projects that want to move forward with model based delivery, but are having a hard time understanding the legal implications. What does LOD mean to us? Does everything have to be in the model? What if is wrong? Mostly, people are consistently nervous about having an external definition to their instruments of service.

The reality is that the LOD system is not meant to be a prescription, but instead a framework. Unfortunately, it is also very vague, and has failed to guide people in its implementation. This has led to general confusion and even dilution of the effort as some have even come up with their own interpretations, many of them just plain wrong.

I recently came across James Vandezande’s most recent post on this and found his explanation to be most in line with the realities of those who are implementing this stuff on non-IPD projects. Probably the most useful aspect of the post is that he swiftly debunks the incorrect definition of LOD in the E202 context as being ‘Level of Detail’ (to be fair it does mean that if you’re thinking of the computer graphics term, which only adds to the confusion). What I like is that he provides a clear explanation as to why it is incorrect and even misleading. He states:

DETAIL = INPUT

DEVELOPMENT = RELIABILITY

This is probably the clearest distinction I’ve seen out there on the issue of LOD. What is most compelling about it, is the fact that it brings the conversation back into the realm of actual project delivery. We are not talking about abstract modeling concepts anymore. We are talking about the documents, or artifacts, that are used to actually design and build. This is very important because it places the focus back on the intent behind the model and elevates the status of the model from somewhere above a physical model (usually only a visual aid), to somewhere just below the actual drawings. It grounds a model back within the realm of process.

The Louisiana State Museum and Sports Hall of Fame LOD400 model

An update to the E202 with E203

Coincidentally, at the end of last week the AIA also published their updated Digital Practice Documents E203 – 2012, G2012 – 2012 and G202 – 2012 for public review. In it, there are a lot of improvements, but off the bat, one caught my eye. Section 1.4 of the E203 document lists the definitions and there are many more this time around that in the E202. There are some that were there before too, but have now been updated. One of these is LOD.

The new version, the E203 (2012) defines LOD as:

The Level of Development (LOD) describes the minimum dimensional, spatial, quantitaive, qualitative, and other data included in a Model Element to support the Authorized Uses associated with such LOD”.

Versus the old version, the E202 (2008) which defines LOD as:

The Level(s) of Development (LOD) describes the level of completeness to which a Model Element is developed.”

The new version refers to two other terms, Model Element and Authorized Uses, whereas the old version only refers to Model Element. Authorized Uses was actually not part of the E202 document at all. Authorized Uses is defined as:

The term “Authorized Uses” refers to the permitted uses of Digital Data authorized in the Digital Data and / or Building Information Modeling protocols established pursuant to the terms of this Exhibit”

The new version more clearly defines LOD as the minimum information needed to support the authorized uses. This new definition clearly speaks to James’ definition and I’m glad it’s made its way into the new documents. The prior definition was definitely misleading in that it seems to imply a geometric completeness over its intended use. It is a very clear directive to tell someone not only that they can use a model for a particular purpose, but that they may rely on it for that purpose.

We’ll see how people take to it…

All models are purpose-built, even when they’re not

August 15, 2012 By in Process Tags: , , , Leave a comment

The reality is that most models out in the wild today are built for one purpose: documentation. Yes, there are plenty of examples of models built for other reasons, but let’s just say the vast majority are out there trying to meet deadlines and if they have to throw in some drafting then so be it. In this case then, documentation was the intended use for the model, regardless of what your friendly neighborhood marketing department tells the rest of us.

Along the path of pointing out things that cause friction with design technology processes, mis-understanding the concept behind purpose built models is high up on the list. A purpose-built model is one that is built with an intended use (or uses) in mind. An example of an intended use may be something like ‘fabrication’, ‘documentation’, ‘engineering analysis’, ‘coordination’, and many others. The key consideration then, is that each of these uses requires slightly different geometry and / or model information.

Defining the intended use of the model gives clear direction to other users. Together with a defined level of granularity, or resolution, it is a powerful tool in understanding what information should and should not be in it. For this reason, many of the more thorough BIM specifications or BEP templates publicly available make reference to model uses.

The newly published New York Department of Design and Construction’s BIM Guidelines lists the following intended uses for their projects:

  1. Existing Conditions Modeling
  2. Site Analysis
  3. Programming
  4. Engineering Analysis
  5. Design Authoring
  6. Sustainability (LEED) Evaluation
  7. Design Review
  8. Code Validation
  9. Clash Detection
  10. Cost Estimation
  11. Construction System Design
  12. Phase Planning
  13. Digital Fabrication
  14. Record Modeling
  15. Asset Management

The VA, on the other hand, calls them ‘BIM Applications‘ and lists the following as a minimum:

  1. Space and Medical Equipment Validation
  2. Architecture – Spatial and Material Design Models
  3. Energy Analysis
  4. Design Visualization for Communication, Functional Analysis, and Constructability
  5. Building System Models – Sturctural, MEPF, and Interiors
  6. Masterplan Space Scheduling and Sequencing – 4D
  7. Communication of Construction Scheduling and Sequencing – 4D
  8. COBIE / Commissioning
  9. Clash Detection / Coordination
  10. Virtual Testing and Balancing

The GSA goes even further and has released individual guides for each of their sought after uses:

  1. Spatial Program Validation
  2. 3D Laser Scanning
  3. 4D Phasing
  4. Energy Performance and Operations
  5. Circulation and Security Validation
  6. Building Elements
  7. Facility Management

Some of these may seem a bit vague, but they all intend to direct a particular end use for a model. Each of these describes how the model will be used for each task, and what information should be included in the model in order to achieve said task. Notice how three large ‘owners’ that require BIM processes all are focusing on distinctly different things. They each care about different aspects of their facilities more. Be it security concerns for the GSA, equipment management for VA, or energy analysis for the DDC, each has implemented a process and frameworks to support their end goals. I’d like to hear how these are performing in real life…

In any case, this advice is not only for those consuming BIM. Those authoring and promising BIM to downstream users would do well to explain exactly what the model was built for. This will help frame expectations for the next user in line and many of the frustrations or mis-aligned expectations about what should or should not be in the model will be minimized.