-         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.

Let’s talk about hiring for a moment. I have to hire a set of technology architects and a bunch of contractors for managing logistics part of MTC. Needless to say, hiring right technology architects is essential to survival. Basically, the technology architects in MTC Bangalore should own a particular practice – a practice could be Connected Systems, BI, SQL, Collaborative solutions, Infrastructure Optimization, High performance computing etc. Owning a practice means the following things

-         Ability to map customer business problems and pain points to technical solutions. TA is not expected to be a domain expert and it is expected that Account Manager and field folks who are associated with that particular opportunity has to help our TA to understand business context. But, TA should be able to take the business problem and map it to MS technology/solution platform.

-         Ability to design a solution (widely called as solution architecture) using Microsoft Platform. Oh, by the way, when I say Solution Architecture, I don’t just mean the routine ceremonial, hand-waving high level visio/UML type architecture, but the low level design that includes how exactly the solution be built with MS with focus on performance, security and extensibility.

-         TA is considered the GOD of the practice. She is expected to be omniscient about the technology area that belongs to her practice that she owns. For example, if you are a TA for HPC, you are expected to know anything and everything about Beowulf cluster, MPI programming, HPC management, RIS etc. Customers expect you to know everything; we expect you to know everything about the area that you own.

-         Needless to say, TA should have great communication skills and more importantly, great listening skills.

So, you can say it is all about technology depth, great design skills, great communication skills and customer empathy – and oh yes, little bit of experience is required (minimum 10 years).

With this idea, I set about to hire technology architects for MTC. The experience has been illuminating.

Architect…Who

We did receive whole bunch of resumes. The resumes roughly fall under following categories.

A)    Project manager. Typically has been handling a mid-large sized team (25-100). The resume is all about how he/she built a practice, enabled his/her reports to do whatever they are set out to do..blah blah. They don’t have any hands-on experience of late (that means 2-5 years). Majority of the resumes belong to this category. These ends up being paper rejects because of wrong fit.

B)     Developers with a difference – and the difference being that they have been developing similar apps for 10 years. They typically build in-house apps for IT dept for large customers for quite sometime. Typically (not always), they wouldn’t have designed large scale apps and hence doesn’t know some of the fundamentals related to scalability, transactions (yes sir, it is true), basic algorithms etc. Their title is architect, simply because of their experience. Most of them are paper rejects because of lack of designing large scale apps, some of them get rejected in the first round after stumbling upon cursive questions on transactions and scalability.

C)    Individual contributors – These people have been designing and developing large scale apps for quite sometime. They like being individual contributors (good fit) and they want to remain technical (good fit). In this case, people with good communication and consulting skills (apart from technical skills) proceed to next round. We’ve had some success here. But, unfortunately, we don’t get a lot of these.

Here is an interesting statistics about the source of resumes. Usually, type A and type B come from System Integrators and Customer IS departments. Type C typically comes from ISVs and some SIs. So, you may wonder why we are getting type A (project management folks) when it is very clear what we want is some one with deep technical, hands-on and consulting skills. The problem is because of the nebulous definition of the word ‘Architect’ in the context of IT industry.  

Let’s look at the definition of an Architect from the following sites

http://www.bredemeyer.com/pdf_files/role.pdf

http://www.agilearchitect.org/agile/role.htm

http://www.artima.com/intv/architect.html

http://www.certmag.com/articles/templates/CM_gen_Article_template.asp?articleid=1406&zoneid=225

If you look at the definition of ‘Solution Architect’ in many of these sites, they go beyond the role of solution architect (i.e., to build a solution architecture) and cross over into many of the project management functions (like political handling (for god’s sake how is this part of architect’s job. Actually every role has some politics associated with it. What’s new here), little bit of project management like managing budget, ROI calculation etc). The agile folks seem to have a much more pragmatic view of Solution architects as opposed to others. I think the problem seems to be more like the confusion of different roles such as architects, project management, portfolio management etc. It is entirely possible a single person may be doing all the roles, but it is important to cleave them apart.

And I am not sure why we take these definitions as god’s gospel. Where are the proof points that this model has worked? Given that overwhelming of the software projects are failure (http://www.agilefactor.com/stats.aspx), what you have, in fact, is the counter-proofs that these models never worked. I personally feel closer to agile approach.

There is an interesting aside. In India, most of the IT population works for system integrators. In the Indian Sis, it is (at least it used to be) very difficult for a techie to have a career as software engineer. This is not because the SIs don’t want to promote individual contributor role with technical focus, but because of the ‘time and material’ business model they all follow. In this model, ROI of a ‘resource’ is directly proportional to how much they can be billed in a specific time. If you remain as an engineer for quite sometime, the ROI (of you) will be diminished over time as your pay increases over time, while your billable amount remain constant (or near constant). I guess this is changing now as the customers also recognize the word ‘architect’ and willing to pay a little bit more. Also, there are few companies in Pune that truly value Software engineers and have built career plan for them as individual contributor role.

In the next blog entry, I will talk about architects in Microsoft and how different they are from the architects as understood by outside world.

PS: These are all my personal opinions based on my observations and it doesn't reflect my employer's view point.

For the first workshop, we chose Colloborative applications as the theme and you can find the content and presentations here in the GotDotNet workspace. Your comments are appreciated.

We offer whole suite of things ranging from a quick 2-4 hours strategy briefing to 2 days architecture design sessions to 2 weeks POC.

We provide world class facilities for doing a POC (proof of concept) in our MTC. As a customer/partner, you can bring in your development team and technical architect from MS will work closely with that team on the architecture, design, development and testing the POC. We will provide a dedicated work spaces and lab resources for developers and architects from our customers.

We are expecting the MTC Bangalore to become operational by November 2005. We are looking for solution architects who can survive in an high-octane intellectual environment. We are interested in folks who can button up and do strategy briefings for CIOs and at the same time, can also roll up your sleeves to design and build (meaning writing code) a solution. We are looking for both IT architects and solution architects. What we are looking for is passion to help customers, passion for MS technologies and passion to learn and lead. If you think you are the right person, please feel free to contact me through the contact form. Looking forward to hear from you.

I will post the CLR Architecture workshop content soon.

I am also looking forward to hear from you regarding the future workshops and the subject areas of interest to solution architects. Please use the 'Contact Form' to directly send an email to me. Thanks.

BTW, we also did SQL Server 2005 internals workshop and CLR internals workshop earlier. We will be posting the content for those workshops in the same workspace in the near future. Govind maintains an excellent blog that contains tons of pointer to interesting database related articles that formed the basis for our SQL workshop.

I am also looking forward to hear from you regarding the future workshops and the subject areas of interest to solution architects. Please use the 'Contact Form' to directly send an email to me. Thanks.

 Inspired by 'Small World' song of Disneyland

It's a small world after all

Hence we should Inter...op

It's a small world after all

Make sure we can interop

(IBM Interop)

It's a world of CICS and a world of queues

It is a world of Bigs and a world of blues

We can screen scrap you; to get to guts of you

So that we can Inter…op

(It's a small world after all…)

(Apps interop)

It's a world of Apps and a world of Silver bullets

It's a world of COTS and world of stove pipes

Wrap with services; talk with adapters

So that we can inter…op

(It's a small world after all…)

(J2 Inteorp)

It's a world of objects and world of messages

It's a world of Transaction and world of resources

There is so much we share; that we should be aware

That we should inter…op

(It's a small world after all…)

You can extend this with (DB Inteorp), (Directory interop) etc. Very extensible song :)

 Inspired by 'Small World' song of Disneyland

It's a small world after all

Hence we should Inter...op

It's a small world after all

Make sure we can interop

(IBM Interop)

It's a world of CICS and a world of queues

It is a world of Bigs and a world of blues

We can screen scrap you; to get to guts of you

So that we can Inter…op

(It's a small world after all…)

(Apps interop)

It's a world of Apps and a world of Silver bullets

It's a world of COTS and world of stove pipes

Wrap with services; talk with adapters

So that we can inter…op

(It's a small world after all…)

(J2 Inteorp)

It's a world of objects and world of messages

It's a world of Transaction and world of resources

There is so much we share; that we should be aware

That we should inter…op

(It's a small world after all…)

You can extend this with (DB Inteorp), (Directory interop) etc. Very extensible song :)

Obviously, usage of EVMs have been the highlight of the election. Obviously, it didn't get the attention it deserves, because media doesn't care about things that work. Here are some of the requirements for EVM system.

1. 600 Million possible voters (380 million actually voted in this election)
2. Million election booths.
3. Each constituency will have different set of candidates. Some constituency may have up to 100s of candidates standing in the election - which is an unlikely thing in west (of course, California is the exception.)
4. EVM should support 18 different official languages. For example, I hail from a state called Tamil Nadu and voters belonging to this state understand only Tamil.
5. ~15-20% of the voters are illiterate - can't read and write. It adds an interesting perspective to the usability aspect of EVM.

Here are few facts.

1. One million EVMs have been manufactured for this election.
2. There was virtually no complaint about usability of EVMs. In my opinion, this is the greatest achievement. If you ask why, just think about all the hoopla around Florida episode during last USA presidential election.
3. Each EVM is shipped to the local booth via appropriate transport mechanisms. I am sure you have seen photos of elephants carrying EVMs to the remotest corners of India. This is a logistical nightmare at the best of times. This is one of the reasons (apart from security) as to why the election was conducted over a period of three weeks.
4. All votes were counted. (sorry mate, couldn't avoid taking a pot shot :) Honestly though, I have a huge respect for US electoral process. IMO, contrary to popular opinion, it is really efficient. It could be made better, by buying EVMs from India. :))
5. Here is the counting process: All the EVMs are brought to a centralized place and they were connected to the network. Counting is a matter of just summing up the votes for individual candidates from different EVMs. All said and done, the whole process takes up to 2 hours. Before the usage of EVMs, the whole process takes up to 2 days and is error prone as the votes were counted manually.
6. Millions of trees were sparred from extermination.

The cool thing about this election is this: If EVMs work for India, it should work for every democratic country for conducting polls (and it will work for china too, if and when china becomes democratic.) When it comes to polls, India should be the benchmark, just by its sheer size and the population. Folks who designed this system should be really proud about what they have achieved.

So, next time when you think of India, please think about the EVMs and not call centers and snake charmers. :)