One of the topics presented during the Architecture Track in the just-concluded Microsoft TechED South East Asia 2006 was done by IASA.
It was done via a very interactive session with the floor questioning the panel from the IASA Malaysian chapter about the value of being an architect and topics of the like.
One of the questions from the floor was: "Do you believe that architects should be writing code ?"
It seems that 3/4 of the panel members agree. Some even going on bragging that he is still doing it in assembly, C++ language. hmmm ... In the interest of keeping the session on time so that that the attendees can get home on time amidst the KL jams - I kept my mouth shut.
Let me open them now.
Architects shouldnt code. Period. My thoughts. Period. To prevent myself from rambling, which is what I always do when I have a strong opinion on something, let me list them in point forms.
The term "architect" is a very nebulous term. The hype around it with all the wannabees printing it in bold font on their cards out there (I know a couple of them in Singapore who does them with no shame), who have no idea what is the difference between horizontal and vertical scaling, doesnt make it any better. For better or worse, I only believe in one type - and that is the all-emcompassing solution architect.
Afterall, aint what all customers want is a solution ? Do you think they really care what is underneath the solution more than that this solution works well, is kept within their budget, perform effectively and efficiently within the constraints of their environment ? Therefore, in this context, I will speak in the context of Solution Architects.
- In the past, code influenced architecture. The limitations of written-code in a chosen-platform in a defined-era is the damning evidence of the limitation of the architecture. VB3 anyone ?
- Biasedness based on preference. A solution architect that has a decade long experience in writing code is usually one that doesnt see the other side of the fence, doesnt know that there are better solutions and worst - refuse to want to see it. Most of the people in this category are usually skilled in one platform over the other and it is very hard for people like that to sit down and analyze a problem without a pre-conceived notion in mind in a very neutral manner. Because of this, the likely solution they are going to propose will have the same limitations of the platform they have been so comfortable with. I dont question the depth. Where is the breadth ? These guys should remain what they are good in and be experts in their domains and probably be paid better than a solution architect. For those who argue that they are equally well-versed in both sides of the fence - Good for you. Stay there. It is very likely you are drawing a lot more than an architect. If you are not, you just need to sell yourself better.
- It is all about the business. Solution Architects bridge the gap between (the returns of) the business with the (returns of) technology. So, yes, they should be just as apt with the Finanical Calculator as much as an Integrated Development Environment or a Installation Panel or Console. They understand the entire depreciation cycle of an enterprise solution much better than the differences between a thread and a process. So yes, the higher the level the language they used to code in (I am talking about 4GL), the better. Bragging how much you still do your work today in First or Second Level Programming Lanaguages doesnt do you any good. In fact, it makes you look bad. It shows the lack of touch you have with your business, how it is run, what are the constraints and the entire business and revenue model. Writing performance drivers, assemblers, kernels, runtimes has nothing to do with a company's business model in a world where Moore's Law still rules.
It is all about the business, still.