Burning Down the Architect Title

Note: There is no ill will towards Roger, he just hit a hot button.

While walking the dog, I listened to the .NET Rocks! episode with Roger Sessions on Enterprise Architecture. I expected the episode to be about enterprise level problems such as scalability and durability (and all the other -ilities). Instead Roger decided to pretentiously talk about his definition of the enterprise architect role. To paraphrase:

Right now, most businesses are split into two camps, the developers (technologists) and the business analyst. Companies think having two camps specialized is a good idea, but it is not…

The role of the enterprise architect is to understand the problem domain regardless if it is small organization or large corporation. It is a marriage between technology and business…

OK, timeout.

While I understand what he is attempting to say, and I agree that the separation of camps needs to blend [into the proposed marriage] for correct software to be built, there are a number of things wrong with this statement and a majority of this interview.

First off, please do not slap the word enterprise in front of any title unless you are specifically working on enterprise level problems. Using the terms enterprise and small organization in the same sentence is an oxymoron. If your job is load balancing the MySpace web farms then you may have the ‘enterprise’ moniker.

Second, attempting to understand your customers’ business domain does not bestow you the architect title because it is not exclusively an architect activity. I rarely meet a developer that has blindly developed off of a requirements document. Normally, the opposite occurs and passionate developers believe they understand the problem domain better than the client (which they promptly need to be reminded that this is not the case).

What I found most hypocritical about his architectural perspective was while advocating the a needed high level union of business and technology, he divided the technological camp by separating the roles of architect and developers. Developers are the ones doing the implementation, should we not be teaching them to learn more about the business domain? If we are segregating the technologists that know the business domain and those that do not, are we not just creating knowledge silos?

Too often I see the title architect incorrectly used for project managers with no technical skills or senior developers with no people skills. And now, I see the title enterprise architect being used out of context. When titles are misappropriated they start to lose meaning. As a result, the wrong people are placed in the wrong positions causing poor decisions.

In my mind, the architect role is about being the strongest team player, fluent in both the proposed technology but also the problem domain, but no more important than the single developer. The only difference between the architect and developer is the different altitude at which the problem is viewed.

Update: I mistakenly said David Hayden earlier but it was a recording with Roger Sessions. Sorry Dave!