KAConnect round up

Over two days this past week I attended Knowledge Architecture's KAConnect conference. The primary theme of this annual event is knowledge and information management for the AEC industries (I was there for the "information management"-themed content).

The event was well-organized, with a good mix of content: a few in-depth presentations, a high volume of fast-paced pecha kucha talks, panel discussions, and unstructured discussion time. A high proportion of attendees presented at some point, which encourages thoughtful conversation. Speakers were grouped into four sub-themes: teaching, methodology, tools, and culture. Within each, the overlap was usually just enough to create the friction that starts good discussions.

Attendees, though diverse, skewed a bit older than tech conferences I'm used to, and was management-heavy. so the discourse was often in MBA-speak, complete with an abundance of platitudes, boosterism, and Peter Drucker quotations.  As far as I'm concerned, most of what needs to be said about this sort of management theory has been said by Matthew Stewart, so I'll refrain from further comment, except perhaps in the most Dilbert-esque cases ("generational diversity training," "making project management cool").

Here's a quick summary of some of the more provocative presentations:

Ed Friedrichs of ZweigWhite started off the conference with an engaging, humorous and personal take on disseminating knowledge that was grounded in a few basic ideas: knowledge management is an attitude, not a repository; people will talk happily and freely about what they're interested in, so get people to share their passions; knowledge flows through an organization when the organization nurtures diversity in its social networks; a social network is successful when it leads to dialog. Friedrich followed up with practices that are reassuringly simple and humanist--frequent social interactions and lots of mentoring--without espousing any technology as central to knowledge management. (Their simplicity is illusory; the devil's in the details, as the rest of the conference made clear at various points.) This stake in the ground was the starting point for the rest of the knowledge management discussions.

Friedrichs also set the tone for the conference in another way, by expressing uncertainty about the ability of groups to effectively share knowledge by any means other than in-person interaction. Though there was evidence of effective, technology-mediated, geographically-distributed teamwork in the conference presentations, there was also much hand-wringing and skepticism. As generally happens with significant cultural shifts in work practices, management has the greatest difficulty understanding and internalizing the changes.

Arup's primary means of knowledge-sharing, as described by Steve Burrows in another talk, echoed Friedrich's: compile and publish a list of everyone's domains of expertise, then encourage people to call upon others, in any of Arup's offices, whenever they have a question. If it works, I appreciate its simplicity.

John Peterson of Public Architecture talked about Public Architecture's primary project, The 1%, which aims to get all professional designers to commit 1% of their time to pro bono work. The size of this potential workforce is enormous--equivalent to a 10,000-person firm--but of course it's efficacy is limited, in part by barriers to sharing knowledge and information. Peterson spoke a bit about 'the power of the knowledge broker' under these conditions, where, often, collaborators' connections are loose and commitment is transitory. The talk didn't provide much in the way of specific tactics for operating under these conditions, but illustrated well what's at stake with getting it right.

Dave Fano of Case gave a brief summary of some quick and dirty research into new models for education and learning using social media, new web services, online networks, etc. His typology of teaching activities (structured, social, interest-based, speedy, guided, active) was insightful, and acted as a great de facto introduction to later presentations by aecKnowledge, Mark English, Michael Woods of RTKL, and others who are already using or creating teaching tools on their own. Hopefully more people in the audience will also be inspired to appropriate these ideas and make them work (better) for architects.

It's notable (and a little disheartening) that the most clueful management presentation was given by someone from a software company rather than an AEC firm. I detected an air of incredulity in the room after Chris Brandt's six-minute take on running a company by a mix of autonomy, self-determination theory, and agile development methodology. Brandt's company, Conject, claims no delegation, no 'kingdoms,' no titles, and no departments. Work is organized as projects, in which participants pick (rather than are assigned) the work they do. They do pair programming, so knowledge sharing happens as a matter of course. Rather than use the org chart as the primary tool for framing the relationships among employees, leadership is mapped in five dimensions, of which only one is based on who reports to whom (he didn't enumerate the other four). Given the number and type of questions that followed, the audience was unfamiliar with, but very interested in, these ideas. I've seen much of this in practice, working in software (though not so rigorously and thoroughly executed), but I was mostly unaware of the theoretical underpinnings (e.g. Deci). There's more to look into here.



Modeling, Part 1: Building Information and Geometry

Modeling is one of the core disciplines of both architecture and software engineering, though each uses the term in different ways. In architecture, changes to prevalent modeling techniques are at the root of BIM and related emerging practices. As such, modeling is fundamental to what I want to discuss here, so it's worth talking about models and the act of modeling.

At the risk of rehashing material covered thoroughly elsewhere and already familiar to architects and BIM users, in this first part, I'll start with the basic ideas of geometric models and building information models. In the second, I'll talk about ontologies, object models, and software modeling (again rehashing basic material, this time from the software side). In part three I'll discuss about ways designers can use, or create, modeling tools in the design process.

The definition of BIM is slippery. Its meaning is contested, and it's notable that the fields of architecture, construction, engineering, facilities management, and property development all seem engaged in the process of defining BIM and are each invested in its impact. There is as yet no consensus on what the acronym even stands for. 'Building Information Model,' 'Building Information Modeling', and 'Building Information Management' are all discussed. Numerous minor variants (PIM, for one) intended to emphasize some particular aspect over another have also been proposed, usually by someone trying to create a business around that particular aspect. Discussion forums for BIM typically include attempts to define it, with widely varying input and disparate results. Definitions are commonly constructed in terms of some combination of methodology and technology, eventually landing on something about the use of digital models to communicate about buildings.

In all the noise and debate, a few fundamentals of BIM tend to get lost. The fundamental characteristic that distinguishes BIM is that it operates on information specific to buildings. In other words, at the risk of stating the obvious, building information models contain, primarily, building information. In contrast, earlier, and still prevalent, CAD systems (like AutoCAD, or Rhino) operate using digital models that primarily contain geometry, along with groups or assemblies of geometry, bits of text, layers, and other similar features that organize or augment geometry.

There is little domain-specific information inherent in the earlier models. Information related to any specific domain (e.g. architecture, or an engineering discipline) must be interpreted by examining the content of the model. To determine whether a NURBS surface in a model represents a wall, a layer contains windows, or a label identifies a door, somebody must inspect the model and interpret it based on drafting or modeling conventions (heuristic analysis is possible, and can be automated, but isn't robust enough to rely on). One exception is dimensions and tolerances, which are commonly included, and do capture information used in manufacturing and construction, represented according to the conventions of those fields.

With BIM, the core information in a model comes from the domain of architecture and construction. BIM models contain doors or windows or beams, and these objects are classified as such in the model (rather than as, perhaps, rectangular prisms, or lines, or NURBS surfaces). In addition to having this inherent 'type' that classifies each element, the model elements also encapsulate other data: they have properties like cost or fire rating. Importantly, geometry is part of the ontologies commonly used; it is, after all, core to the architectural domain. A 3D geometric representation is, however, just one of many attributes that a building element might have. Once an object is created in a model, these properties can be assigned and are carried with the object, and are not merely labels but inherent characteristics.

BIM models (and the 3D geometric models in some CAD systems) are not organized by the layers or groups familiar to AutoCAD users, but by graphs. Modelers based on graphs usually display this graph as a tree, allowing users to easily navigate a hierarchy of elements. A typical BIM model's tree structure might consist of a site, containing one or more buildings, each composed of multiple stories, themselves containing building elements like walls or columns. The graph displayed to the user often only represents a simplified view of the information that really structures the model: additional hidden nodes and relationships capture, for example, placement of objects relative to each other or to absolute reference points.

Though strictly optional, BIM systems universally rely heavily on interactive 3D environments, since they provide a peerless interface for many important use cases: spatial navigation, object inquiry, authoring of new elements, and, using color and animation, visualization of non-geometric properties. Though useful, 3D modeling, while it goes hand-in-hand with BIM, is neither necessary (one can work with data directly) nor sufficient (many 3D modelers are purely geometric) for BIM.

In addition to working with a model via a geometric representation or assembly graph, BIM systems often support other idioms for working with non-geometric information. These operate on the domain-specific data inherent in the model, providing tables, schedules, and reports based on users' queries and interactions. A simple data view might show all the properties of a selected element in a simple table, displaying the name and value of each property. More powerful data views can be generated by the execution of logic or performance of computation in software. Such tools might generate a window schedule, produce a "clash report" identifying all the pairs of objects with intersecting geometry in a model, or test building code compliance.  

People perceive significant value in the ability to change the workflows associated with activities such as cost estimation, quantity surveying, collision detection, and code checking when working with BIM models. These workflows have largely been manual when supported by geometric models and 2D drawings. With BIM models, the logic, analysis and computation associated with these tasks can be handled by software tools. Computing the total cost of all windows in a model, or identifying all the doors with fire ratings over 2 hours, is a job that can be captured in a short program.

This fundamental feature defines BIM at a basic level: it operates primarily on building information, rather than geometric representations. While this may imply or suggest many things--such as the use of software tools that can create or work with BIM models, or the modification of project delivery practices based on the ability to share the information thus modeled--these are separate from the core concern. This will be of considerable importance in part 2, where I'll talk about ontologies, the act of modeling, and software in greater depth.

The unspoken goal of BIM

1. Design your 3D model.
2. Click 'print'. 
3. Watch while swarms of universal nanoassemblers flock to the site and materialize your structure.

The Little Girl Rant

The importance of the seemingly banal practicalities of architectural practice were first made clear to me by Frank Gehry in spring of 2005. Mark Wigley had set up a nearly two hour, early morning Q&A session with Gehry and the first-year M. Arch. students at Columbia's GSAPP, and at some point I asked a question of Gehry that I no longer remember. 

Whatever it was, it touched off a ten-minute response about the state of practice. When recounting the experience later, someone who has worked closely with Gehry for years recognized quickly where this was going and said 'yeah, the Little Girl rant.'  Indeed. It went something like this: 

The AIA, with the best of intentions, has been working for the last 50 years to protect architects from exposure to excessive risk through the limitation of legal liability in the standard AIA contracts and the promotion of the standard architect-owner-contractor triangle of contractual relationships.  Though this has helped protect practices from lawsuits, it has also reduced the power that architects have. During the design phase, architects have control over the process, but once the design it complete it's out of their hands. The contracts give architects little or no opportunity to ensure that designs are realized according to their intent, no tools to counter the ravages of value engineering. If problems arise during construction, the architect is treated like 'a little girl' (Gehry's words). '"There, there," the owners and GCs say, "it'll be all right, just let us big boys figure it out."' And while the architect is blamed, ignored, or both, they take the project into their own hands.  

There was a lot more to it than that, and much more vigorously expressed, but that's the idea as accurately as I can recall. His office, he said, uses their own contracts, and he advocated for the profession to change the role it plays in the industry.  Even with my limited knowledge of professional practice, it struck me immediately as dead right. Over the next couple of years the same message was reiterated (though never as succinctly or completely) by Thom Mayne, Keith Kaseman, Dawn Finley and others. 

It also instilled a deep suspicion of the idea, repeated (AFAIK) in every school's professional practice curriculum, that the AIA is the architect's friend, and if you follow typical standards of practice things will be OK.  

In the last five years some things have changed, either through work dedicated to addressing the problems (the development of Integrated Project Delivery, the broader use of Special Purpose Entities, etc) or through circumstance (the economic crisis leading young architects to explore alternative forms of practice).  The crisis in the profession still remains, though, and new forms of practice, and new tools to deploy in their support (my particular area of interest) are still needed. 

On The Architecture Machine

I am starting a new blog.  I'm eight or ten years late to the game, I suppose, but then people still write books (and I still read them). So.  

What is the architecture machine? This blog takes its name in part from Negroponte's book of the same name (which has been the subject of study by Kazys and Molly lately), and I'm sure I'll be writing about computers, interfaces, AI, computational design, and other topics of that book. But the name is also used in other senses: political machines, abstract parametric design systems, CAD and BIM applications, computational infrastructure in the urban environment, etc. 

More to the point, the Architecture Machine is a blog for observations on the mechanics of architectural production: the discipline of architecture; architects' tools; the strictures of professionalism; education, training, licensure, and other rituals of transmission of architecture culture. It's about how architects make things, and how the discipline as a whole operates. 

This blog isn't primarily about buildings as architecture, technologies of shelter, or software product information. If you want criticism of recent architecture, info on new building materials, or tutorials on organizing object families in Revit, that's pretty well covered by some other great sites. 

At least that's the intention here at the beginning. We'll see where it goes from here.