STRUCTURAL ENGINEERS may design any building of any type.
CIVIL ENGINEERS may design any building of any type EXCEPT public schools and hospitals.
ARCHITECTS may design any building of any type EXCEPT the structural portion of a hospital.

Whoa! Stop the presses! In the State of California the STRUCTURAL ENGINEER has no limitations on what they may design, but the architect cannot design portions of a hospital. Interesting, but this didn’t really fit what I was looking for in an explanation. I found the following on Google Answers and I believe it does an excellent job of qualifying the term, and title, architect across all vocations.

“Historically, the architect has been the coordinator of all other disciplines involved in the building process. According to training and licensing exams, architects must be able to integrate all building disciplines to protect the overall health, safety, and welfare of a project. We are responsible for not only this integration and the accessibility of structures and their surroundings for human use and habitation, but also for the end result in terms of use, quality, composition, and appearance; engineers are responsible for the application of mathematical and physical sciences, within an area of expertise, and the related health, safety, and welfare. While architects are tested in engineering systems [structures, electrical, mechanical, and site design], building construction materials and methods, codes, contracts, programming, spatial relations, history, and theory, engineers are tested only for specific systems and disciplines. Engineers have a narrow focus; architects bridge the gap between the systems [what engineers design] and what the community needs.”

source: aiapa.org,

So, based on his explanation the engineer is responsible for the design of an entity, typically to the exclusion of the environment in which the entity will exist. The architect is responsible for ensuring that the entity also serves and does not negatively impact the environment in which the entity will exist. Hence, the architect needs to fully understand and be a master engineer, but also have experienced how past engineering projects have impacted an environment once it was introduced.

I guess, a good question on an interview for an architect might be, “in a past system in which you led the systems engineering design, how have you had to change the design once the system was put into production?” I would follow up to this question with, “what factors led you to know what changes were required?” I believe my final question might be, “on your next system design what factors you anticipated to limit the requirement to make changes once placed into production?”

Thus, architects need to think strategically about the use of end product, whereas engineers tend to focus solely on the end product. This begs the question, “do engineers need to fully understand the big picture, or just focus on building the building?” This is an interesting area onto itself. For example, what if the architect didn’t think of everything? What if an engineer is familiar with problems with using a particular material on a job that the architect recommends?

To fall back on a structural building analogy, it seems that it could be very disruptive to have an engineer focused on whether the placement of the front door is placed optimally for access from the parking lot. At some point, the engineer has to trust the architecture and the architect has to trust the engineer. However, this is the focus on a whole other blog entry. To complete the thought, I am on the side of separation of concerns, but an engineer who is bright enough to consider the optimal placement situation should be a target for apprenticeship to become an architect.

One thought on “Then What Does Make Someone an Architect?”

There is one more piece of the puzzle as far as what an architect must be able to do. The architect must be able to translate user requirements into an entity that will staisfy those requirements, thus the architect also serves as the interface between the user and the engineer.

The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by Perficient and does not necessarily reflect the views and opinions of Perficient nor does it constitute any official communication of Perficient.