Thoughts on the World

Who Are The Architects?

There's a perennial discussion in architecture forums like the WWISA about the role of the architect, and the discussion regularly degenerates into a debate between the broad and narrow views of what the architect does.

But I'm not sure that's the key question. I think the right question is "who are the architects?" Somehow, a number of tasks must be discharged, but how varies from project to project.

An architect can do any of three things in a development, whether that development is software or building construction:

  1. Synthesise the requirements and constraints to produce the "big idea" design for the solution. If the clients don't yet exist, or are unsure of their requirements, this involves acting as a "proxy" for them. In many cases, this involves "selling" the design to clients and formal approvers.
  2. Formally document the design to a level of detail which can be approved by technical review authorities, and handed off to the builders. This usually involves adding structural detail beyond that required in the first step.
  3. Act as a "technical go between" throughout the development, helping to resolve technical problems between the clients, builders and project managers.

Somehow, the set of "architects" on a development have to cover off all three activities. However, the "set of architects" can include "client thinking about architecture", "builder thinking about architecture" and "architect who works for someone else".

In the last year I've had a modest building project which tells an interesting story about how different people contribute to "the architecture".

In any area with high property prices (such as the South East of England) it's common for buildings to expand over time, progressively extracting more "value" from a given site. Over 50 years something like our bungalow can easily double in size - these are major changes at the structural layer of Stuart Brand's model. (Over a slightly longer period the site layer changes as well, typically as sites get divided.) Buildings change just as radically as software, only usually over a much longer time.

So we had our loft converted into new rooms. We did it in two stages - the front a few years ago, followed by the rear and new staircase.

The front was designed by a professional architect (with letters after his name). He produced the design, got planning approval, contracted a structural engineer, got building regulations approval and wrote the formal spec for the builders. We then found a builder and project managed the build. The result was fine, and does a great job of hiding the house behind a deceptively small and quaint front aspect, almost like the TARDIS.

However, when it came to the second stage, we took a different route. I didn't want another small room full of odd angles, as proposed by the original architect, and realised that a small change to the roofline would give us a large clear room, and about another 100 square feet.

Having sold the idea to the sanctioning authority (my wife), I then prepared new high level plans, mainly by Photoshopping the old ones, and these were adequate to get planning approval.

Building regulations approval requires more formality, so we engaged the structural engineer directly to calculate beam sizes etc., and create a set of formal, detailed plans. The structural engineer made his own architectural suggestions. One, to move the new internal walls slightly and create more space, we happily accepted. Another, repositioning the bathroom, we rejected as it would have spoiled the architectural integrity of our new space.

The build mainly followed the plans. However the builder persuaded us to change the materials for one wall, and increased the specification of some beams to allow for my weightlifting equipment. An intrusive buttress from the first stage was a problem, and he and I jointly designed a way to redirect the loads so it could be removed. Thus refactoring happens in building construction just as it does in iterative software development.

As in software, there's a challenge to maintain and ideally improve the architectural purity in the face of change. We still have a bungalow with 45 degree roof pitch and within the building line of the adjacent properties. But we've also managed to get rid of the flat roof over the lounge added in the 1970s.

All this resonates with my experience as a software architect. Good solution ideas come from many different players, and the true architect must combine these into an attractive, coherent vision. Parts of the architecture may be delegated to others, particularly specialists in a particular technology or process. And others will contribute to the architecture's evolution over time.

So who are the architects? Many people contribute to an architecture. You could say they are all architects. "The Architect", if there is one, is the person who guides these contributions into the whole.


If you'd like to comment on this article, with ideas, examples, or just to praise it to the skies then I'd love to hear from you.

Comment on this article

Please share: All Addthis servicesTweet thisFacebook thisLink thisYam thisShare on Google

© Questa Computing Ltd. 2005
Page last updated 14 May, 2015 13:35

Questa Computing Ltd. is registered in England and Wales number:2889117.
Registered office: Ember House, 35-37 Creek Road, East Molesey, KT8 9BE UK
For credits, copyright details and cookie policy, see here.

Search my Sites:

Share this page:

Share |


Favourite/Major Articles
All Articles by Category
All Articles by Title
Review Index

Site Map:

Welcome / Home Page
Contact Me
Search the Site
Thoughts on the World
Consultancy Services
An introduction
Key Skills
Career Summary
Case Studies
IT Knowledge/Education
Customer Profiles
Training Courses
Previous Experience
Download Full CV
National Grid Group Plc
British Energy Power and Energy Trading
Legal Marketing Services Ltd.
Marks and Spencer Plc
Faith Footwear Ltd.
Barclays Sales Financing Ltd.
Oracle Corporation UK Ltd.
Livingston Rental Group Ltd.
National Power Plc.
Agile Development
Coding Projects & Thoughts
General Thoughts
Products and Projects
Reviews: Books, Music & Films
Website Announcements
Full Index
Publications and Papers
A Hacker's Guide to Project Management
Conference Papers
Agile Architecture
Practical Enterprise Integration
Modelling an Enterprise Data Architecture
Strategies for Flexibility
Getting Sizing Right
Muzzling the Alligators
Evolution of a Test Method
Photography Articles & Discussion
Photo Gallery
Projects and Products
RelQuest - Reliability Modelling Tool
ConQuest - Container Yard Management System
Full Index
Biography and Personal Endeavour
Construction & Civil Engineering
Human-Computer Interaction
Mathematics & Statistics
Military & 20th Century History
Modelling & Analysis
Photography & Photographers
Physics & Cosmology
Project & People Management
Psychology & Human Behaviour
Science, General

Contact Me

Email me

Feeds and Tweets

Follow me on Twitter


Thoughts on the World
(main feed)

Feedburner XML
RSS Version XML (direct)

How many subscribers?

Other Feeds

Professional Blog
Photo Blog
Photo Album
Review Pages

About my feeds

Google Blog Search

References to
References to

Sister Sites: