This follows from the post: “It’s Going to be Wrong”
It’s common knowledge that a given group of people behaves less intelligently than the individuals that make up that group. It is therefore no surprise that on many projects, even through the individual developers, architects and so forth know what constitutes good design, the code appears to be remarkably bereft of any such wisdom. As a general rule, the quality the code tends to be inversely proportional to the number of developers working on it.
This disintegration of code quality can be arrested by having the architect be an architect. In these situations, the architect is often as neck deep in coding as the developers and is not actually doing much ‘architect-y’ work. As previously stated, the only development work an architect should be doing is that which relates to proof of concepts, prototyping and / or frameworks. When not doing this type of work, the architect should be devoted to reviewing code to make sure it adheres to prevailing architectural guidelines / interface contracts and so forth. The architect also needs to be a mentor to those developers who are not quite on board with the whole OO thing (yes, there’s still quite a few out there). If the architect is spending all their time developing (including fiddling around with Maven POMs or Ant build.xml files), they do not have the time to do these things.
You only have to look at www.dice.com to see all the architect positions that require hands on work to see that this problem is more the rule than the exception. Go on try it.
The architect needs to be the strategist for the group. If they are bogged down in the constant minutia of day to day development they cannot fulfill this role. Not to mention the two efforts require completely different mindsets.