top of page
Articles: Blog2

There Can Be Only One?

I was reading Fred Brooks's book, The Design of Design. He discusses the role of the system architect and the design of systems. One of the things that occurred to me was that in many of the teams I had been involved with lately it wasn’t clear exactly who the designer of the system was.

You see these teams had one or more roles that shared the responsibility of system design. For example, the role of an architect can have the responsibility of technical design. The role of product owner can have more of a product design responsibility. Add a QA Lead and you might have someone who is ostensibly responsible for test design.

After reading Brooks' book, it started to occur to me that this artificial separation of roles is really quite insane. You can’t separate technology from user experience or even worse, separate quality from technology. By doing so, you just create needless competition and waste.

Don’t believe me? The architect points at the product owner and claims that they don’t understand the technology, therefore they suck (and architects should run the show). Or product points at architecture and says they can’t deliver, therefore they suck (and product should run the show). Or QA says…wait…nobody actually listens to QA. Sorry.

Brooks would say that there should be a chief architect - not named as such. They might be a project manager (heaven forbid), or they might be a manager (oh dear), or a developer. One person who will be the single accountable soul when it comes to the design of the system. In scrum, that’s the product owner. That means this person better have some serious technical chops. They can’t just be a freshly minted MBA. They need to be pretty seriously experienced in multiple domains. There is no such role as an architect on a scrum team. Why? Because it would undermine the product owner.

Fundamentally, Brooks maintains that ownership of a significant design can't be distributed. It must lie in one person. Remember, Brooks was the key designer for some huge IBM systems. So his perspective is a bit "old school". However, that doesn't mean he's wrong. There is a counter viewpoint. I think most modern agilists would maintain that architecture should be a shared, emergent property of a system (a team effort). They may be right. However, at the moment, there are probably still more examples of successful systems with a single architect (the Brooks theory) than there are good examples of successful evolutionary, shared architectures (I can't think of any). While I'm not sure that I completely agree with Brooks, I can't think of any great counterexamples either.

If your product owner doesn’t understand technology, then perhaps you haven't selected a good product owner. Don’t try supplementing the team with roles like an architect in order to fix that problem. Just get a good product owner. Stop looking at MBAs and start looking at your developers, your QA, and your internal domain experts.

14 views0 comments

Recent Posts

See All