Define Architect

I wonder if some of the 'software architects' (or others) might attempt a definition of the use of the term 'architect' within the software/computer community....MartinNoutch

ArchitectAsKeeperOfTheFlame is one of my favorite Wiki pages. -- CliffordAdams

See http://c2.com/cgi/wiki?search=Architect for several relevant pages.

"Architecture" = 'global decisions' "Architect" = 'person who makes global decisions'

I agree with Cliff that ArchitectAsKeeperOfTheFlame is a great page. But I would add that PaulDyson is a very young person to be defining the word Architect and a very enlightened one, as are most or all of the people that comment on that page.

I have also seen the term software architect (especially ChiefArchitect) being used in much less enlightened ways in most of my twenty years of commercial experience. One of the issues for me is that the term has never had as clear a definition in software as in building and the HumptyDumpty principle has applied far too much. A couple of the many interesting points that came up for me at the interactive session at OtNinetyNine with JimCoplien and MartineDevos on this subject:

the "real architect" is never going to spend his highly paid time "laying bricks", which would perhaps be analogous to GlennVanderburg and at least some other software architects who want to stay in hands-on touch with coding (which I applaud). There is much more expertise required in coding than in bricklaying, in other words, and this is one of the many factors that should have limited greatly the use we made of this analogy in software
the practical role of software architect has, in many situations in my own experience, been to limit the creativity of the programmers - by laying down standard tools, libraries and run-time environments for example - often based on very pragmatic commercial considerations. There may be some parallels with the physical architect's relationship to the builder here. But there has seldom been any real parallel with the very important aesthetic role and responsibility of the physical architect. Even the false aspiration here has done major damage in my view. Perhaps only code can be beautiful in our game - and the problem is that it seldom has been. At least XP's aspirations - if not beauty then at least reduction in ugliness of code through refactoring - can in my view only do good. But the analogy with physical building has surely broken down completely at this point?

-- RichardDrake

Lots to say on these points but just a few brief comments here: -Instead of 'laying bricks' the comparison should be with 'preparing drawings', quite a different activity, but possibly quite analogous to the coded instructions of programming. (Drawings are to an extent 'coded' and comprise 'instructions' to the builder.)

The drawing remains the key communication tool of the Architect, whether to staff, clients or builders. Most of recognized world class architects continued to prepare drawings themselves right to the end of their careers.

-On a slightly different tack, many senior Architects do (or did) get involved with the actual craft side of the process, sometimes actually 'laying bricks' to show a tradesman exactly what is required. The ability of Architects to do such things was often an expression of their knowledge and mastery of the materials they were requiring tradesman to work with.

-'Highly Paid Time' - well some architects do think like that, but these are generally the types who are managers and not producers. As noted above, most recognized great architects don't think of their work as primarily about the money thing. In fact it is amazing how much uneconomic work most architects are willing to engage in in order to craft/hone/refine the thing they are designing.

-- MartinNoutch

Hmm, thanks, very helpful on the details of the discipline on the "other side". But I'm still not convinced about the analogies drawn. I accept that I need to modify my statements and I do so with due respect for physical architects, for whom it seems pride in the results of their work and the reputation of their profession can rise above mere commercial considerations. I may be unfair but I'm not sure that happens so much with software architects.

You say instead of "laying bricks" the comparison should be with "preparing drawings". The most fundamental difference between preparing drawings for builders and coding in software is that the instructions in the first are to people, whereas the second are testable instructions to a formal computer. These are hugely different.

There are also important differences, in my view, between "laying bricks" as an example to the brickies on a building site and a software architect coding. The two-way skills transfer (keeping the architect in touch, giving good examples to the craftsmen) is indeed much to be commended in both disciplines and I have no problem with the analogy here. But the software case remains more abstruse. One of the issues that FredBrooks deals with well in NoSilverBullet is the variety and complexity of the materials with which we're building in software. It is much greater, which is one big reason we mess up our projects more often.

The devil is in the detail in software, even more than in physical building. One of the key consequences, as I see it (though this is still I guess hotly disputed by what is called the CASE tool community), is that our drawings of a proposed software system are, on average, far less useful than the drawings of a competent physical architect for a proposed building. See DesignDiagramsArentEvil for perhaps the most positive case that can be made.

I accept that there are some helpful analogies between the physical and the software architect. But there is nothing like the seven years training that we have in the UK for the real architect, nothing like the well defined interface with "lower level" tasks and roles. The excellent "intermediate products" or drawings that justly earn the competent physical architect their fees and kudos have nothing approaching a consistent parallel in the diagrams of the software architect.

-- RichardDrake

The devil is in the detail....

At the schools of Architecture we often remind ourselves that 'God is in the details', ie the details are really important.

That aside I'm conscious of another factor in the comparison between Software & building Architects.

In the UK and indeed most of Europe, I believe, individual Architects (& firms) generally carry out work on a project from conception through to completion on site & handover to the client. My understanding (correct me folks if I am wrong) is that in the States for the larger projects there may be 2 firms of Architects involved: the first, more of a design/concept Architect, the second the 'executive Architect' who gets the job done from construction detailing to site completion.

In this latter approach there is a separation between the 'High Priests'/Prima Donna types and the 'Footsoldiers'. In the UK there is generally a strong tradition of the Architect having a deep understanding of construction/technique as well as ideas going back at least to William Morris, Ruskin & Pugin. this is greatly demonstrated today in the work of the 'Hi-Tech' Architects like Foster & Rogers.

Of course, 'Technique' can become an end in itself, and a pretty arid one at that, if the essential poetry & humanity of the architectural endeavour is forgotten.

-- MartinNoutch

This is from TheSourceCodeIsTheDesign:

: The manufacturing team for software is your compiler or interpreter. The source is the only complete specification of what the software will do.

This would seem to relate to Richard's comment

: You say instead of "laying bricks" the comparison should be with "preparing drawings". The most fundamental difference between preparing drawings for builders and coding in software is that the instructions in the first are to people, whereas the second are testable instructions to a formal computer. These are hugely different.

Has Martin has recognized an infelicity in the manufacturing analogy explained on TheSourceCodeIsTheDesign (although he probably hasn't seen that page)?

This is interesting for me, since I found TheSourceCodeIsTheDesign a revelation, although I'm not sure I agree with what seems to be the orthodox interpretation of that page. -- KeithBraithwaite

So, please give us the orthodox and the neo-orthodox interpretations Keith...(briefly, you're in the company of a real architect remember)

The WorldWideInstituteOfSoftwareArchitects has a definition: http://www.wwisa.org/wwisamain/role.htm -- KevinLewis

An architect is responsible for architecting. The form is defined by the function :). -- RichardHenderson.

See CommitteesLeadToHalfFinishedWork for another interpretation of "architect"