THIS ARTICLE LOOKS BACK at a 2013 ABX Boston presentation the author made as part of a panel and session called, “Scrubbing the paperwork: New standards in construction administration.”
Within the context of the recent CDE (Common Data Environment) feature articles and compilation lists of CDE tools, it is valuable to add another key dimension to the discussion.
Why It Is Difficult Being An Architect
Over the years cocktail party talk may invoke the question, typically from a complete outsider, “is being an architect very difficult, what do you need to be good at?” Often the inquirer may assume that what architects do is a lot of math, at which time I promptly explain that while we may train in college around advanced math, nearly all of us do very little of it as part of practice.
MORE: A Primer on CDEs (Common Data Environments) for Architects
I then explain that according to some of our own architectural institutes and societies, there are actually two dimensions of complexities that challenge professional architects at their craft at the highest overview level. (see image 01).
01 – New Zealand Institute of Architects, Five Classes of Complexity in a document defining fee ranges for architect services.
Some British Commonwealth Countries’ institutes for architects, like the New Zealand Institute of Architects, have even put out explainer documents to the public touching on this, as in the image above. (image 01) In a 2006 “Guide to Architects Charges” document, the NZIA defines five classes of complexity and thus, five anticipated levels of possible fee ranges for architects.
Architects address challenges in practice along two axes in this chart. The Y-axis defines the measure of the complexity of the building itself, roughly based on building typology and particular complexity introduced to that typology example. Notice the chart’s reference to the following:
- Degree of Complexity — Envelope design
- Degree of Complexity — Plan formation
- Degree of Complexity — Building services
In reference to a CDE (Common Data Environment) tool, we may begin to think along these Y-axis issues and ask the question, “what features in this CDE help me solve these particular challenges?”
At the same time, the X-axis is defined in the chart above as complexity of client brief (architectural program). This particular measure has two distinct inter-related metrics. The first is the complexity of the client brief in absolute terms (eg: space and room requirements as defined, number of unique requirements) and the second is frequency measure of contact with the client. (click on the chart, image 01, to read it more clearly).
On the one hand, the architect’s mind must contend in absolute terms with tackling complex “problem sets” regarding complexity scales in “plan,” “envelope” and building “services.” Additionally, she must contend, mentally, with client input streams that range from “minimal/intermittent” exchanges to “intensive/near continuous” exchanges.
Thus, based on this document and chart, an architect engaged in a building type with a complicated brief and intensive client contact, designing a structure with complex envelope systems, complex services, and complex plan forms, would be tackling a Class 5 architectural project in terms of complexity.
The Two Hemispheres of Challenge for Architects
Another way to break down the New Zealand Institute of Architects’ guide to architects fees chart was to create a graphic that imagined the architect’s mind as contending with two hemispheres of mental challenges based on these two distinct types of complexities. (image 02)
On the one hand, the architect’s mind must contend in absolute terms with tackling complex “problem sets” regarding complexity scales in “plan,” “envelope” and building “services.” Additionally, she must contend, mentally, with client input streams that range from “minimal/intermittent” exchanges to “intensive/near continuous” exchanges. (image 02)
02 – Dual hemispheres of mental complexity in the practice of architecture.
The main point of my talk at the 2013 ABX event session was to get architects to realize that the solutions for project collaboration and document management on the market (early forms of Common Data Environments) may want to be evaluated on the basis of how well each solution addresses challenges architects contend with based on these two distinct sets of complexities.
One realm demands intense focus, both solitary and collaborative in nature, driven towards innovation and creative ideation. The other realm demands textual information processing and organization, and written and verbal communication skills among others.
Defining X-Axis Challenges
Input challenges descending from the client brief evolve over time throughout the project. Project typology will determine a range of complexity with the brief (a hospital project versus a motel project) but so too will the client’s own make-up and nature of doing business. There are certain building types that tend to come with more disorganized clients. Organized and low-intermittent client communication around the brief provides the architect with a more controllable workflow around client-driven data input. The intensive and near continuous communicating client challenges the architect to deliver that same control over data.
In the 2013 ABX talk this next slide broke down the Input side into four distinct challenges regarding client-driven input.
- organizing client-brief input
- tracking client input
- recording client input
- sharing client input
The slide below asks the question, with reference to choosing a CDE, “where are we more challenged?” For my firm, the answer was on the input side. Input challenges dwarfed Solution challenges. (more on those in a moment.
03 – Detailed challenges under each complexity in the practice of architecture.
The talk argued that “input challenged firms” should look for a CDE (common data environment) solution that masters message delivery and management. In today’s world, ongoing client communication is often by email, a very poor system for handling this type of c0mplexity. Client-sided inputs alter the building client brief over the duration of the design and build phases. When this complexity rises it does so because of the intensity and continuous nature of the inputs.
Defining Y-Axis Challenges
Y-axis challenges for the architect center on the complexity of the building itself, as defined in the design challenges related to plan, envelope, and building services (MEP, FP, etc.). Today’s large skyscrapers possess increasingly sophisticated building envelope systems where structure meshes with multiple layers of glass and other materials all designed to address thermal requirements, daylighting and occupant comfort.
Hospitals and science buildings place complex demands on building services, as do other building types. And large multi-use or multi-occupancy structures demand complex planning.
How does a given CDE (common data environment) system help the architect address these types of challenges?
In the chart (image 03) we note a few examples of how cloud-based CDE’s like Trimble Connect and others address such challenges. Features in the system include:
- data exchange
- viewing and markup
- recording
- sharing
CDE’s that can exchange data between architect and consultants in ways that aid collaborative problem solving better suit architects who are challenged on the solution side of the challenges question. Viewing and markup tools in a CDE—particularly those that can markup and annotate 3D data from BIM models—facilitate iterative review and validation cycles between disciplines. Systems that can record and organize these cycles deliver an auditable history of decision-making which becomes a searchable database for firms when they face future challenges of like natures. And CDE’s that are capable of sharing all forms of useful design data—including the exchange and transfer of analytics and computational data—between CAD, BIM, CAE and CAM systems promote a delivery pipeline that accelerates solution generation.
CDE’s that can exchange data between architect and consultants in ways that aid collaborative problem solving better suit architects who are challenged on the solution side of the challenges question.
A very good example of this last point was conveyed to me in a private meeting with Autodesk in Boston when they showed me Project Quantum last year.
Closing Thoughts
The complexity of building versus complexity of brief chart serves to illustrate the two major dimensions of challenges architects face in the delivery of their services.
If CDEs are collaborative environments meant to aid the architect’s ability to communicate, re-use, and share data efficiently and without loss, contradiction, or misinformation, then we must acknowledge that “data” exists in two forms in the project: (1) data from the client brief and (2) data generated during design and construction as a by-product of the delivery system. These two spools of data intertwine and cross-reference each other at multiple points along the process. Complexity in structures generates reams of data on its own, compounding the challenges. This is your Class 5 architectural building type and the largest challenge modern CDEs must address.
Reader Comments
Comments for this story are closed