Let’s talk about architects in Microsoft. The architects in Microsoft I know grew threw the ranks as Software Design Engineers and are extremely technical in nature. If a normal programmer knows 10 things about a thing, then an architect for the thing knows 500 different things about the thing. For instance, Christopher Brumme probably knows 500 different things about GC than a competent .NET Programmer. Roughly, architects in Microsoft product dev team do the following things

 

-         They usually own a specific area of a product and come up with complete design (to the level of lowest granularity). Their tremendous experience in software engineering and their ship record helps them to look around corners, optimize things based on the underlying platform and provide guidance for developers to implement a particular strategy in a most optimal way.

-         They work with other feature teams and architects to make sure that whatever they design seamlessly work with other components.

-         They are extremely technical. This cannot be stressed enough.

-         They write code – a lot of code actually.

-         They communicate really well – one thing I have appreciated and trying to learn over a period of time is the clarity these guys bring to table. It is as though they speak the language of context-free grammar. You can’t interpret a sentence in two different ways.

 

They have huge credibility and it is due to their proven technology depth, engineering skills and their vast knowledge.  

 

Let me digress and talk about the other types of architects I encounter (outside product teams) on a daily basis.

 

Beware of VNAs

 

I keep hearing this new term called Vendor Neutral Architects. First time, when I heard this, I spilled the NaaN that I was eating. (NaaN is not ‘Not a Number’, this is an Indian bread type J.) From what I hear, these guys are supposed to know all the technologies provided by all the vendors at the goriest level of detail for a particular problem domain to help customers make a knowledgeable decision. For example, if the domain is Messaging, then the VNA should know Exchange, SendMail, Lotus Notes etc in all their gory details and help customers choose the technology based on whatever the customer needs are. From what I see, you can count people with deep skills in all competing technologies in any domain. For example, it must be easy to count the people who can compare and contrast CLR and JVM at the minutest level of detail (for instance how the JIT optimization works in CLR and JVM or the GC heuristics used by different runtimes) or for that matter people who knows how to compare SQL Server Query Optimization vs Oracle’s query optimization. It is of course obvious that a person who has this knowledge will be of tremendous value to any team, but it is just that they are very hard to find.

 

From my experience, the VNAs I have met are definitely vendor neutral – in the sense they don’t know any vendor technologies at any level of detail. These people seem to have all the other ‘right’ attributes like socializing, playing politics, playing golf, nice dress sense etc. I am not generalizing, but this has been my experience so far. Some of these architects hold a view point that they only design at high level (i.e., UML and Visio) and leave the details to developers. Hello? You can’t write code, you are not an architect. Sorry – you didn’t pass the necessary condition (at least not in MTC).

 

So, I am going to use two variations of architects - Architect with capital A to denote MS Software Architects type; and an ‘architect’ with small caps to represent the solution architect and VNAs as defined (or loosely defined J) by world at large.

 

We want Architects not architects. If we come up short, I would settle for experienced software design engineers with good customer handling skills.

 

PS: These are all my personal view points and doesn't reflect view point of my employer.