With regard to where requirements should originate and how to evaluate them… that should be done in large part with the users. However, the relative priority of those requirements must be set by someone with the big picture view and the overall authority to make decisions. This often – not always – goes along with the big wallet. This is where Scrum came up with the concept of the Product Owner which is a little more specific than (my understanding of) XP’s Customer.

The challenge much of this is pointing out is that software development, and technology in general, has advanced to the point that projects need a wide variety of different ‘architects’ and they all need to be capable of analysis and design. These days large organizations have such complex environments that you need input from any number of architects (security, network, enterprise, usability… take your pick). However, understanding the true goals of the system and ensuring these are well understood is what will make your implementation successful.

On a slight aside, over the course of my career I’ve become increasingly suspect of asking for ‘users’ to define the requirements of a new system or enhancement. Most users, unfortunately, often have very myopic views of how they use a system and the overarching business processes their activities support. That ‘big wallet’ guy that Robert referenced often has a better vision of what the system really needs to do because you usually don’t get the big wallet without being connected to the real strategies/direction of the company.

I find it funny that both of us reference Fred Brooks.

Therefore, I suggest that architecture choices (.NET vs. Ruby , Rails vs. MERB, one rubygem vs. another, etc.) should be made by team members rather than by “the Architect”. Note that I say “those with architectural knowledge” in the post. I should probably change that to “team members with architectural knowledge”; it was that way in a draft.

The one point I disagree with in your longer comment is implying that the possibility of bad architecture is a reason to never plan architecture. While bad architecture is painful, lack of *any* architecural planning *can be* even more painful. To detect whether that is the case, I suggested the list of smells.

Also, as I mention at the end, I do not recommend this for all projects. It is generally applicable when there are multiple projects that must integrate. Integrate either in their deployment or in the need for team members to move between projects.

Before anyone hoists me for saying that someone can move between projects… Note: I don’t mean work on multiple projects at a time. That is generally a bad idea. However, if an organization has two products, one may have a lull when the other is trying to deliver more features for a release. In that case,moving staff from one to the other *can be* a good idea. Also in that case, having some consistency in the libraries/frameworks/components used can reduce the impact of ramp up and communication overhead that we’ve known about since even before Fred Brooks’ Mythical Man-Month.

I’ve been burned by “architects” as have others, as suggested by your own words. A co-worker of mine has said that he had a really positive experience working for a large private contractor and another good experience working for a large government owned corporation.

I think the case for using an architect may greatly depend on the architect.

When I was at Agile Austin Open Space, Scott Belware introduced me to the term “design hernia”. Think of a herniatied disk in the spine. This disk is inflammed and applies pressure to the spinal cord causing in many cases severe pain. If the hernia is resolved in the body, eventually the surrounding tissue will cease to be affected. That is, the body is self correcting. Programming code is not self-correcting. Effects of a design hernia can continue to be felt even after the hernia is removed.

I’ve been in a few environments now where the “architect” (whether this person refered to themselves as such or not) actually introduced some serious design hernias and was either unable to remove them because of bureaucratic inertia or was too stubborn to concede that the “architecture” was flawed.

In building construction, design is the process and architecture is the result.

To me, too many architects come up with their architecture without thinking about its consequences. Why do these people try to set in stone what basically should just be design before their ideas are validated through user acceptance testing?

Bad architecture can unnecessarily increase the time to live, increase the overall complexity of the system and increase the maintenance burden.

These things make me question, “Is architecture really worth it?”

Robert

p.s. That other article that suggested non-functional requirements were best handled by architecture was in “Better Software” magazine.