Friday, April 11, 2008

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.

7 comments:

wmartinez said...

Hi Paul.
I got your point. I think you got some of mines too. Now let’s see what this new posting light casts.

1.You are actually saying that Architecture follows a Taylor’s view of work. He said people need to be forced to work! Hummm. We need to go a little deeper in that view.

2.I didn’t say “the Agile manifesto as a definitive statement of Agile Values”. The guys that call themselves as Agile need to follow those values, that is all. One guy, just because it is called PM, or Architect, may not loose the right to follow the values. Even more, being named like that does not mean that it is impossible for them to follow those values!

3.About the term, you have some misconceptions there, sorry. It was Shark in the Nato conferences (1969) that brought the examples of operating system 360, which was developed by several teams. Each team did a great job constructing each of the components in the OS, but when they tried to fit it together, it was not so coherent. Then Shark mentioned the need of a higher view that may not sink in the complex engineering, but keep a birds eye to achieved that coherence. There he mentioned the architect to engineers as an analogy. Some other guys like Nicklaus Wirth noted the need of that new level of development conception. It was never though as a level of direction or management.

The term was not totally accepted, and the meaning of architecting has been evolving through the years. Some authors tried to map it to the building industry, but were unsuccessful, as more software intensive oriented approaches came by. The role is still in evolution, and unfortunately many has jumped into the bandwagon making things that are not so good..

So, Why all those guys at Nato conferences were so worried of the actual development discipline? Why did they agree upon the need of a discipline, scientific methodology to development, and coined the Engineering term? I understand that it was because development teams and systems were growing in complexity and were not the type of work for just two guys in a garage.

4.Agree, the underlying principle of Agile does not conform to your architecture view of borrowed building papers. The role of Software System Architecture does, from their beginnings, since it is an evolution from software development (not buildings). So, what it is wrong from all this view is the idea of architecture being management oriented just because the name recalls those things? Let’s play a game then: Let’s forget the role has this unfortunate name, let’s call it “bird developer”, let’s define the actual tasks of the role and then let’s discuss if it really delivers value or not.

“Architect which is essentially a taylorist construct”. I think you need to review that, I totally disagree. First you said Software Architecture is word play, then it is high level technology selection, then big paper generator, and now it is old century/deprecated and flawed management. Your logic is very good, but I’m pointing where you should review your concepts.

Let's eliminate the architect position at all companies. Let's flatten all technical positions to developers. At the end, some one has to make the high level decision, talk to customer and play all the other tasks the guys with the unfortunate name do now. Actually, they are going to be in the company still, but will probably leave shortly. Blame Maslow for that. ;-)

William.

wmartinez said...

What a Coincidence!
I just got the Agile Journal number a few minutes ago.

You can read it at http://www.agilejournal.com/#_edn2 there you have an article on Emergent design/archietcture, another one of envision architecture (Ambler)and also one from Hodgkins about "Software Architecture Challenges and Significance in an Agile World".

Is it then agile community is embracing architecture, and not the other way around? Articles are succinct and may not show strong bases, but it is interesting a large number of them are related to that name... you know...

William.

Paul Beckford said...

Hi William,


Let’s play a game then: Let’s forget the role has this unfortunate name, let’s call it “bird developer”, let’s define the actual tasks of the role and then let’s discuss if it really delivers value or not.


Agreed. Lets talk about the actual role. Labels can be misleading. I look forward to your description of what an Architect actually does.


“Architect which is essentially a taylorist construct”. I think you need to review that, I totally disagree. First you said Software Architecture is word play, then it is high level technology selection, then big paper generator, and now it is old century/deprecated and flawed management. Your logic is very good, but I’m pointing where you should review your concept


What I am saying may sound confused, but you need to extend your understanding of Scientific Management as defined by Taylor. Taylor said more than workers had to be forced to work. He also said that experts at the centre can analyse the process and decide "best practices" to be applied across the company. Ordinary workers are not capable of making such decisions for themselves. This is a belief. The people at the Nato conference believed the same thing too, hence the misinterpretation of Royce's paper and Waterfall development as we know it today. This belief is common in most western organisations which is why it is known as the classical management approach.

The label Architect in my experience (which spans over 18 years) is commonly used in support of a way of working that supports the classical management approach. I am interested in seeing what it is you associate with the label "Architect".

Paul Beckford said...


You can read it at http://www.agilejournal.com/#_edn2 there you have an article on Emergent design/archietcture,


Hi William,

I have no problem with the noun architecture or the activity architecturing, I accept both. What we are discussing is the role Architect.

Creating an architecture is part and parcel of my role as a programmer/developer. I do not need to be an Architect to be concerned with Architecture.

wmartinez said...

"I do not need to be an Architect to be concerned with Architecture".

Exactly! So, architecture matters. What we need to discuss is about the tasks to perform, who, when, how. And those will give us roles to play in the team. Architects you know may have been doing some tasks you don't need, and some tasks the team need may be done by architects I know. Which are those tasks? Who is doing them? should we call that person architect? Those are the questions.

About Taylor, don't worry, my third career (after IT and music) was administration. Not so sure Nato guys were thinking on developers as brainless code builders that need an architect because Taylor was telling so. They were talking about the discipline, not people. I'll reread the Nato notes just in case I missed something.

BTW, the Nato didn't define the role (which is still evolving and not nailed down completely), just identified the need, which I guess was fulfilled during all that time by someone with another title name.

Now, I'll get back to my blog and see if the hosting is working yet...

William Martinez.

Andy said...

Interesting post guys, just to throw in my 2c, I think it would be really useful to focus on what architecture means to you.

To me it has different meanings - there is software, technical, systems, network, enterprise architecture and probably others.

So when you say that architecture matters, can you be a little more specific and perhaps provide some examples of things that would be considered architecture from your perspective.

Paul Beckford said...

Hi William,

"About Taylor, don't worry, my third career (after IT and music) was administration. Not so sure Nato guys were thinking on developers as brainless code builders that need an architect because Taylor was telling so."

This is the thing about culture. You don't need to know where beliefs come from to share those beliefs too. BTW lets be fairer to Taylor. Taylor actually said that workers needed to be incentivised to work. Specifically that people went to work for money. Deming challenged this idea and said that other motivations were more important, like pride in a job well done, freedom to act and make decisions for yourself and a sense of common purpose.

I spent several years in Software Management, so trust me when I say that Organisational Culture plays a BIG part in project successes/failure.

Specifically my post is about the role Architect. The activity of Architecturing can be carried out by anyone who knows how to program in my opinion.

You seem to believe that there is a specific role for an Architect. Lets take Andrews lead and actually define what Architecture is and then perhaps we will be better placed to decide whether the activity of Architecturing can be split into a separate role or whether it is part and parcel of the role of a developer/programmer which is what I believe.

We seem to me arguing around the subject instead of getting to the meat of the matter.