Architectural Cultural Assumptions

An interesting angle on the SoftwareArchitect - ChiefArchitect - ArchitectsDontCreateArchitectures debate is the sometimes apparent different practice of Architecture between UK and US Architects. (I may have written part of this on Wiki back in March but I couldn't find it so I'll carry on!)

In the UK it is common for Architects' Practices to be involved at all stages of a building project and at all levels of design. This extends from initial concepts to completion and handover on site (and beyond to defects and teething troubles) and from overall 'grand ideas' to minute details eg ironmongery choice, paint colours, details of trims and plasterwork etc.

This approach is very much a product of 19th Century ideas about Art, Architecture, Production etc, partly typified by the 'Arts & Crafts Movement' and partly by the writings of Pugin, Ruskin & Morris. (Frank Lloyd Wright, thought of himself for a time as 'The Ruskin of the Mid-West')

By contrast, my understanding is that in the US Architectural Practice is sometimes (often?) divided between the design-oriented practices who draw up the main ideas and 'Executive Architects' who see the project through from detailing to completion. (This sometimes happens in UK practice but is generally less common.)

I may be wrong but perhaps some aspects of US Architectural practice colours Software folks' views (positive and negative) on the Architect's role/Status.

An interesting example of US practice, I believe, is located in PortlandOregon: the City Hall annex between 4th and 5th Avenues, aka the PortlandBuilding, designed by the famous US Architect Michael Graves around 1980. This building was the subject of an Architectural Competition which Graves won amidst some controversy, chiefly over his ('post-modernist') use of sculpture and other classical references in his design ('Temple-Style Public Office Building Controversy').

Like most of Graves's work several sketch studies were produced for the elevations in his flowing, attractive hand style. However, as completed the building lacks much of the 3-D vitality promised by the sketch designs and this may be partly due to the separate roles of Design and Executive Architects with the latter possibly not able or intesrested enough in keeping faith with the full original design intent. Whatever the reason the final product seems rather flat compared with the work-up ideas.

-- MartinNoutch

In How Buildings Learn by StewartBrand, there is a discussion of the problems involved in the lack of connection between the different stages of a contemporary commercial building's construction: Architect, Contractor, and frequently an insurance company or pension fund as the actual seller to the initial occupant. The occupant is left with no one to really turn to for help with any problems. Any echoes of waterfall processes are purely coincidental -- RobertField

I'm not sure I understand. In most US software companies I've worked for, the Systems Architect not only sticks around for the whole system life-cycle, but often does much of the programming and defect fixing him/herself. Additionally, the architect must be involved in all detailed design meetings to make sure the detailed design (subsystem and implementation design/spec) does not change or adversly impact the architectural design or its ConceptualIntegrity. However, where I've worked may not be a good indication of how things are generally done in the US - it only reflects how I've been trained and how I work. Often, this lifecycle will include multiple releases, sometimes someone else takes over after the 2nd or 3rd release. It's usually considered bailing-out to not continue for at least a 2nd release. However, in building architects, I've often heard of bringing in one architect to design an addition to the building that another architected originally designed. Oh yeah, and in my travels in Software Development, I have never heard of having both a System Architect and an Executive Architect. What you are calling an executive architect sounds more like what we call a Technical Lead or Project Manager. However, they usually work with an architect (or they are the architect), they don't usually replace the architect role. --RobertDiFalco

In my situation, the managers suggested the idea that an architect would work in the early phases of a project and leave it as it went to coding. I was very interested in establishing the role of an architect so I didn't say anything at the time (98). That whole concept (bailing out) had never occurred to me and I knew intuitively that it was a bad idea but the managers I worked with at the time seemed to think of this as well-known practice. I went with it. It turned out not to be a good idea. We have now built up a team of architects so some value was demonstrated. Now the managers are asking that the architects be involved in the whole life-cycle of the project. I think this will be much better because it matches more closely with positive experiences I had in the past. I should also mention that I require the architects to be jack of all trades people who not only design but code and who develop expertise in a large number of tools and languages. --MikeCorum

I agree with those who are suspicious of "diagram only" architects. I consider architecture to occur at the interfaces between logical design and physical implementation. To do one without informing the other implies either omniscience or denial. I haven't met the former situation yet.