Vous êtes sur la page 1sur 2

The Technology Stakes

By Laurie Barlow, AIA November 10, 2006

I promised one of our Emeritus members that I'd write a preliminary article about technology in
architectural practice that he could understand, a fairly tall order, but here goes! I think the
biggest misunderstanding of "technology" is in terms of the information our profession must work
with and produce. To most people, technology is about gadgets, telephony and software. To
systems engineers, technology is about ISO 9000, Six Sigma, and cost efficiencies in electronic
processes and security of the data, especially over the Web. To business managers (the PSMJ
types), it's about business strategies and models using analytical tools to make the office very
lean and mean, using accounting software and management theology texts.

For architects, technology means simply using the appropriate digital and hardware systems to
achieve the necessary tasks that our profession must do, quickly and effectively. Our profession
stands out among all others in the complexity and massive amounts of information, teamwork and
communication that are required to do the following:

Design concept and sketch analysis


Study models & visual studies
Program analysis & budget development
Project financing and leasing/sales
Project scheduling and work flow
Code analysis & preliminary approvals
Facilitate user groups – client programming
Agency public hearing – EIR & traffic, planning issues
Historic preservation & site context, research
Life cycle comparisons – energy, materials, program efficiencies
Budget analysis & costing data
Project management documentation
LEED Energy analysis/Whole Building
ADA analysis
Constructability analysis – 4D (3D assembly time sequence simulation)
GIS maps and databases (3D topography and site conditions)
Architectural – Plans, sections, details
Architectural – 3D Models (digital and physical)
Architectural – Renderings and photos
Specifications and materials performance – CSI framework
Structural, MPE, Civil and other engineering
Landscape/irrigation, site work
Specialty: Acoustic, Lighting, etc. studies and verifications
Construction phase documentation: reports, photos, RFI's, payment requests
Materials ordering and procurement, CPM analysis
Project closeout documents
Contracts, agreements and letters

I have listed the tasks in bold that involve 3D parametric software, abbreviated as BIM, which is
used by the profession to integrate the building design information into one gigantic visual
computer model that is too cumbersome to actually share in real time with the team throughout
the entire project. Essentially it allows the design and build teams to examine things fairly
realistically and solve problems in an easily manipulated 3D digital model that saves time and
money in the field, since it's very much like a preview journey through a virtual construction of the
actual building, if it's done right. This generally takes a team of CAD people a few weeks to a few
months to do. Each software type also has its own sometimes severe limitations that restrict its
ability to mimic real-world situations, thus limiting the ability to predict all circumstances.

However, one can see right away that there are many things besides BIM involved with producing
the project from start to finish. Almost all of them require some form of digital documentation or
manipulation, from text documents to engineering analysis to graphics. This is what the
"interoperability" issue is about, since the programs don't work with each other directly. The
"scale" of the programs used, according to the project or the firm's needs, is also very important.

This can be circumvented with a central database on a server, which can open specific
documents and their associated programs when a viewing portal is set up that follows our
professional architectural language. Right now, people have to know an entire array of software
programs in order to manipulate all the different kinds of documents, which limits the ability of a
professional to manage and organize the project information as a manager, and tends to isolate
the various groups that work on the project team since they specialize in specific types of
software. For example, contractors are not very good at CAD workstations or even following
directions, but they do real well with digital report forms in the field as well as digital cameras,
especially wireless ones that let them get rid of the paperwork quickly and go have a beer. This
improves efficiency.

Another issue here is that all these programs have different ways of displaying information that
are designed by computer programmers who have no familiarity with architectural processes,
terminology or analytical methods, so it's all sort of jury-rigged together. Many of them resemble
accounting programs in their logic and appearance, but are not that helpful to architects, as
irrefutable as their logic is. One must be a polymath to handle them all. This does not improve
efficiency, the current holy grail of business methodology.

My point is, “technology” is only a means to manage the information, which is what creates the
value of a project. We are at a primitive stage right now, with the architects focused on a very
small section of the digital environment that mostly resembles the old architectural rendering with
engineering notations that used to make up a set of drawings in the early twentieth century. A
preferable model in tune with the current business climate would be able to graphically navigate a
project by information type (like photos, reports or models) so that managers can instantaneously
pull up a project at any point and review any kind of documentation without asking the CAD
manager for the appropriate file set on a monitor. This is the key to allowing a seasoned
architectural or construction professional to be connected to the information instead of separated
from it, and to use their skill and judgment instead of laboring over the keyboard.

A truly expert system will allow a professional to append their ideas, details, photos, videos and
field experiences into a central information bin that is accessible to the entire design team on
future projects. Once this information is tagged by senior professionals, it can always be found
and referenced by a query, so that this information begins to acquire tremendous value in its
ability to support a firm's work process at all team levels. It's not about repeating floor plate
configurations or extruding multiple 3D variations of a building shape (these studies are software-
vendor driven), it's about the value of learned design and building experiences available to all
those who work on the system. Thus it becomes a true collaborative process, which is a hallmark
of successful projects.

Also note that architects are now heavily involved with the IT sector, which has its own unique
costs, liabilities and protocols that design professionals cannot take on. This includes legal issues
raised by importing the digital industry and its IP issues and WWC3 protocols that underlie the
ownership of information and the associated liabilities for sharing this data, as well as the
responsibility for maintaining it. This includes information security, communication protocols, file
corruption issues, hardware/software support and information storage and management. Our
"instrument of service" and its copyright is now produced by digital algorithms owned by others
and used through a license, instead of the rendering and engineering processes formerly done by
an individual's hand. It is urgently and painfully necessary for an industry dialogue to take place,
NOW, on who takes on what responsibilities in this arena, and clarify the overlap of disciplines
and the team's responsibilities that cannot be traced to licensed individuals and specific sources.

© Copyright 2006 - 2008 Laurie Barlow

Vous aimerez peut-être aussi