What does an Architect do?

Posted by on Apr 21, 2011 in Common | 4 Comments

I’ve been working with numerous software organisations for years, occasionally where the software is intended to be embedded in hardware… I regularly meet people with the role “Architect”. But I don’t really have a clue what real architects do—they design buildings, basically…

I’ve seen a lot of bad effects caused by inadequate metaphors in software engineering—engineering, for a start. But even worse, in my opinion, is architecture. Architecture has no place in software—and to explain why I feel that to be the case, I need to understand what architects do.

Berlin, Potsdamer Platz, by Nusco

Berlin, Potsdamer Platz, by Nusco

My brother is an architect, so I asked him to explain in reasonable detail…


What (in the process of creating a building) is an architect responsible for? Which types of tasks does she delegate, what kind of decisions must she take himself? What kind of people is she working with and who does she report to?


First job of the architect is to analyse the needs of the client. A good architect will engage the client in intensive dialogue about all important aspects of the building: Costs, energy consumption, number of people to live/work/have fun in the building etc. She needs to pay sufficient attention to detail and to gain a sound understanding of the kind of activities that the clients plans to entertain in the building. Especially for corporate buildings, this requires a quite deep understanding of the client’s business. I was astonished by the similarity of the questions my brother asks a new client to those I use in a first assessment as an agile coach!

Very detailed prescription

The architect “designs” the building on many different levels of detail. Materials for the main structural elements (walls etc) are defined just as well as doorknobs, plugs, and the colour of the carpet. For topics involving technical specialist knowledge, like electricity and network, heating/cooling, machines that need to be built in, the architect involves the relevant specialists. An architect does not have fundamental technical knowledge of all the technologies built into his product!

User interface

Obviously, this is not a term that architects use—but what stunned me was that the elements of the building that its users actually see and touch are those that she spends the most time and energy on. For most projects, these visible details’ design and the resulting user experience is much more important to the architect than the actual “building blocks” constituting the main physical structure of the building. A good architect differentiates herself from a mediocre by her attention to detail.

Planning and Controlling

The role of an architect is different in construction projects in different countries. In Germany, the architect usually is also the project manager of the building project. In other countries, organisation works differently—the architectural design usually is handed over to a builder who manages the actual construction process.


Common layman’s view of work at a building site

Everybody I talk to about building processes and architecture seems to think that most people working at a construction sites are craftsmen—experienced specialists sufficiently equipped with skills and tools to work autonomously on the part of construction they are responsible for. I see this to be the case in software projects (or complex systems development, like cars, airplane, medical device development, for that matter), which seems to support the metaphor of an architect.

Quite long ago, this has in fact been the case for buildings. You might have read “The Pillars of the Earth”, where Tom Builder creates a cathedral with a team of experienced craftsmen. But:

  • This has been in the middle ages (12th century)… And
  • There hasn’t been an architect. That role developed (much) later.

How things are

Today, big construction projects are carried out by construction companies that bring in lots of “assemblymen”—basically untrained people who have the ability to carry out exact instructions to assemble pre-built parts into a greater whole. They are not expected to (and mostly can’t) make any decisions, not even small ones (they might even have instructions in which order to turn the screws).

A common architect’s saying goes, “when the workers begin to think, things start going wrong”…

Most, if not all, parts of the buildings constructed nowadays are industrially produced. There are no carpenters on site anymore who craft doors and frames, all parts are ordered from catalog and delivered on site to be assembled. That basically makes late changes to the detailed design impossible (or at least quite expensive), as small changes lead to parts that don’t fit anymore.

How the architect interacts with workers

This situation enforces the need for detailed designs and prescriptions and leads to the architect’s responsibility for detailed design up front. She needs to control every contribution and constantly check if everything is going according to plan and design… Command and control at its best, frequent shouting generously included.

And Software?

I must admit this role description, as sketchy as it is, fits even less into my view of software development than I had thought. I’ll address the comparison of these findings in a later post. Until then, I’d like to know:

  • Do you know of duties of an architect or details of her work that would complete this description?
  • What do you think about the usage of the architect metaphor in software?
  • What other metaphor would you recommend to use instead?



  1. Hans
    April 27, 2011

    Well, it is said that an (SW) architect is responsible for the transformation of requirements into a solution or better solution approach. My problem is this: for me, an real architect is inevitable coupled with the term aesthetic. An (building) architect is one which fulfls the requirements in a way which touches the full human being, its senses, its feelings, all aspects of living. Therefore, architecture as a broad and extensive nature, it covers much more than functionality.
    Then we have other terms: designer, constructor. In German, “Konstrukteur” (constructor) is often used in the sense of technical originator of a device. But today, this term is not used very often, it is replaced by “designer”. All is designed today. Bacteria, buildings, cars, food. It is an very empty term for me today. The German term “Entwurf” has a little bit different character than “design”.
    So what’s about software ? For me, software is constructed or engineered. It may have architecture if it is more than a small software to implement some little requirements.. A big muli tier solution may have architecture, an embedded controller has not. In fact, elegance in the technical solution, like maintenability, extensibility, error tolerance, what ever, is required and honored not very much. So architecture.
    That’s my spontaneous thoughts, based on 17 years experience with software, software architects and all my unfullfilled wishes how software
    in industry should be

    – Hans

  2. Olaf
    May 3, 2011

    I’m not sure you got my point…
    I’m talking about wording, phrasing, about using metaphors that help to add understanding to conversations and those that don’t.
    Construction, Engineering, Architecture… They all have their place, their meaning, their right-to-be. I just don’t see why we should use them in software.
    Software is not engineered.
    Software is not constructed.
    Software does not have architecture in the sense that buildings have…

    There is something in software development which obviously reminds people of construction, engineering, architecture… And I see what that is, don’t get me wrong. I value the work of software developers very highly that do these things… (and I did, too)

    But I’d like to see different words for that. Gardening, farming… Words that take the evolving and growing nature of software (and its development process) into account—and clearly shows the differences to manufacturing, construction and building.


  3. Kurt
    May 3, 2011

    There are different ways of thinking about software development that map to the building metaphor differently.

    Most software today is still built in traditional phases, with separate design and implementation phases. This reflects the Taylorist division between thinking managers, and doing workers, and tries to realize a vision of better utilization of “valuable” software designers, and less valuable, interchangeable programmers.

    The concept of Software Architect matches this vision fairly well, with architects “designing” the software, and producing a sort of software blueprint, for handing off to the programmers to be merely converted into source code and typed in, as if it were a mechanical, repeatable process.

    In a lot of software development, especially in the enterprise area, this model fits somewhat, as programmers really doing not much more than plugging libraries together, or filling out standard templates.

    Jack Reeves pointed out in the meantime, in his Code as Design essay, that the analogy to construction was incorrectly applied. The “blueprints” were less useful to the programmers than the designers thought. The programmers actually had to more thinking, and turned out to be more valuable than the designers. The source code was not the finished product, it IS the design. The programmer IS the designer. The closest thing to the finished building, constructed by workers according to the blueprint, is the finished executable, quickly produced by the compiler according to the source code.

    I think for typical enterprise software development, analogies like construction, engineering, and architecture are relevant, but you have to apply them carefully.

    My favorite analogy is however the fashion business, as it emphasizes how quickly things have to be bought to market, how important individual personalities are, how matters of taste are far more important than whether things are “correct” or not, and the emphasis on passion, relationships and creativity.

    But this seems to describe development as found in the open source, consumer product, game, web, startup, academic, areas a lot better than enterprise development.

    But we have to learn to communicate without analogies too. Software development has been around a while now, most people doing it know software development better than gardening, farming, or construction.

    Lets try communicating with our own words where possible, and only resorting to analogy when we have to.

  4. Hans
    May 16, 2011

    Hi Olaf,

    since Aristoteles we know that there is no “just wording”. The wording and the thinking is connected. And yes, mostly, Software is not engineered. But it should be. I don’t see why Software should be different than using physical or chemical (not mathematical!) laws in order to arrange cause – effect chains manifesting in buildings or mechanical machines. The Problem is, that we obviously not know what the corresponding laws would be for Software.

    The older I get, the more I think that all the software craftsmanship an agile techniques just cover the fact that we have not these laws to engineer software. Of course, from a human point of view agile is great. And agile is not the opposite if engineering. Lean principles created a very successful airplane at Honda, where we have a lot of engineering, My point is this: I see the danger in stressing agile methods too much so that we give up to search for these laws too early.

    So in fact we have the choice: using terms like engineering and architecture because we have not the right techniques, understanding this terms as motivation or agenda for the future, or to avoid them because the situation is as it is. I would prefer the first option 🙂

    @Kurt Which role does the word “design” play in software industry is a very very hard question for me. One root of the problem for me is the difference between “design” and “Entwurf” and “Design” in German usage.




Leave a Reply