Architects - Who needs them?

William as responded to my post on "Me too Agile" and his response made me think that my post required further explanation. An Architect as a software development role is a relatively new idea, appearing in the mid 90's along with the boom in 'OO' technologies and middle ware.

Before this the only architects I was aware of produced paper drawings for buildings. The architect would design, and builders would construct. The term Architect is borrowed from the building trade. Its roots in the building industry are quite revealing I believe and say a lot about the assumptions, philosophy and organisational cultures that led to its use in Software development.

It seems strange to have to say this, but in the early days of software development, there wasn't roles like Project Manager, Business Analyst, Systems Analyst, Architect, Test Manager etc. There was usually a couple of guys who sat down and decided that they wanted to write a computer program. When Thompson and Ritchie decided that they wanted to write the Unix Operating System they didn't have an Architect. They did the design and wrote the code themselves. They even went as far as producing their own programming language, so they created their own tools too. As a team they were self reliant, with a single focus the creation of a working program.

The purpose of my post was to question the relevance of the role of architect in an organisation that subscribes to Agile values. William in response quoted the Agile manifesto as a definitive statement of Agile Values. Well before the term Agile was coined, the category of software development methodologies we now call Agile went under the name light weight processes. What all these methodologies had in common was a rejection of an high ceremony approach to software development. Approaches like OMT, Objectory, RUP (which now coincidently claims to be (me too) Agile :)) that prescribe a number of distinct development phases with a number of distinct roles, handing off work to each other through a number of concrete intermediate work products. 'Light weight' meant getting rid of as much of this as possible and getting back to a way of working that would be more familiar to Thompson and Ritchie.

This view of the world, builds on a management philosophy that says that decision making should be delegated to the lowest level possible within an organisation. In short the people who do the work are best placed to make the right decisions. This idea of worker empowerment builds on the work of Edward Deming, and reaches a pinnacle in the Toyota Production System as described in the writings of Taiichi Ohno.

In keeping with this philosophy, the Japanese have developed a number of approaches to new product development, which we commonly refer to as Lean, Just-in-Time, Agile, etc. One of these approaches is deferring design decisions to the last responsible moment. The reason for this is to allow concurrent design. Toyota do not have Architects. They have a chief Engineer who champions the project and as an overall vision, but he does not make design decisions or tooling decisions. These decisions are delegated to the design teams who are autonomous. These teams try to keep their options open avoiding looking themselves into decisions which are not easily reversed later. The reason why they do this is because they do not own the whole design. For example the boot design team may need to change their design late into the development cycle. If the team responsible for the interior space of the car decide that people in the back really need an extra inch legroom to compete with the latest competing models in their target market segment. Then the boot design team need to be in a position to respond quickly, by changing their design reducing the boot space to accommodate the larger interior. This agility is why they defer irreversible design decisions.

Simon's paper on architecture, although it doesn't use the word "Agile" explicitly, makes much play of this Agile principle. The point I was making is that this principle is part of a wider philosophy, and that philosophy is not consistent with the idea of Architects and Architecture as borrowed from the building industry.

Taiichi Ohno would not recognise the use of deferred decision making in a context where the architect was the technical authority yet not responsible for doing the actual work. What we have here is a mix of two separate belief systems. The belief system that says that decision making should be centralised stems from the Management teaching of Fredrick Winslow Taylor and his idea of Scientific Management. A good example of this philosophy in practice was Henry Ford and the Ford Company. The Japanese came to the US after WWII and looked at the Ford production System and largely rejected it as inefficient and wasteful.

The point I'm making is that these are two separate contradicting belief systems, based on different values. We can question the relative merits of each, but cherry picking practices from one belief system and applying them out of context into an environment with the opposite belief system is not likely to produce the intended results. The beliefs come first and the organisational structure stems from those beliefs.

So whilst it is true that Simon did not appropriate the label Agile, he did attempt to reconcile the role of Architect which is essentially a taylorist construct, with the principles of Agile product Development which stem from the beliefs of Deming.

This is the background to the point I was trying to make.