Then What Does Make Someone an Architect?
So, allow me to expand on my prior blog entry (Architecture Frameworks Don’t Make Architects) and answer the question, what does make an architect?
To
help structure my query, I went in search of a concrete specification
that defines the difference between and engineer and an architect and
found this http://www.pels.ca.gov/pubs/building_design_auth.pdf
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.
aiapa.org:
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.
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.
- Login or register to post comments
- 1738 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
wmartinez replied on Fri, 2009/07/10 - 5:11pm
Hello JP (You have the same initials as my newborn son, so excuse me if I start baby-talking).
Let's begin by going back in history. The first one coining the "Architect" was Sharp at the NATO conferences in 69-70, using that same building analogy. The analogy of the architecture rapidly felt short, since the software construction (engineering) was not as similar either.
Then, some schools appeared as to what Software Systems's Architecturing is about. I have a pending blog on architecture conceptions, but the most cited is the Architect in the Ivory Tower vrs the DO-it-all architect. Similar to what you point out, the ivory tower concept means the architect knows his stuff, which is an strategical one, and shouts orders to the engineers below, who must obey. The other one is about the architect that codes, coaches, performs reviews and solves problems with her peers. This architect may not know all the details, but it is the one that knows the concept as a whole.
So, engineers do need to know what the architecture is about, and how the piece they are building will fit with the other ones, but they are not responsible for thinking on it. They are in charge of knowing what to do in that door, not the architect. The architect must not know everything, but when they suggest something to be done (add that door there) the engneer may come back and tell him that door has a technical problem if placed there.
The architect, in that case, may go back and check where else can the door be placed, so it still fullfils the requirements. It is a collaborative work, with expert people focusing in different abstraction layers.
Cheers.
William Martinez Pomares.
Architect's Thoughts
mikesogeti replied on Wed, 2009/07/15 - 10:21am
You also cannot "grow" an architect...
- Training helps a very small part of the I.T. population actually gain real experience.
- Corporate America is run by shareholders who want to see profits, not a R&D percentage in the 25s.
- After investing that much in an architect, you run the risk that someone else is going to pay them a much higher salary to pull them away from you.
- Every solution is unique, so it is impossible for an architect to be "certified" as there are no standards to the building of I.T. solutions.
The simple reality is the best architects I have seen have consulting backgrounds. The consulting company oversold the consultant's skill set. The consultant walked into hell and were able to return burned near-death but experienced and able to walk into about any situation and succeed.
Why do we consistently see headlines, such as “SOA Is Dead”, “EAI Is Dead”? It’s simple, because all these things are really complex and you can’t approach them with an assembly line mentality. Forget Henry Ford already, look at Detroit, learn a lesson people! Focus on developing quality, which means selecting those individuals capable of being architects and supporting them through apprenticeship programs. Moreover, support the creation and execution of apprenticeship programs in your organization
As my company is trying to coin the phrase "SOA is Dead", let me just say that complexity and experience is only the tip of a huge iceberg. That iceberg also contains a lot of politics. You need the architect to be a politician. The iceberg contains a lot of different people with different goals. You need the architect to be a salesperson. Restructuring jobs, roles and responsibilities to match the SOA model results in very angry people who hate change, especially if they are losing work. You need the architect to be a miracle worker.
This all being said, I can agree that frameworks are not the right way for a company to go. It is because companies try to use it as a tool rather than as a standard. Software as a service/clouds will likely be a better overall solution, even though it still has some major hurdles to overcome.