The 5 Types of Poor Architects
I have worked with so many architects in my career, including those who have the “Architect” word in their business card and those who play architect role in their projects. And while I had good fortune to meet very talented people, I am frequently disappointed by poor architects who put their ego, arrogance, fanaticism (and sometimes, ignorance) before anything else. Recalling the memories I have about the poor architects, I come up with the following grouping.
- The nothing-but-nails architects. These architects have hammer and thus they see everything as nails. That said, these people are very eagle to apply overkill technologies to solve even the simplest problems. If the software has web front-end, then a MVC web framework must be used. If it has to integrate with some back-end system, then an Enterprise Service Bus implementation must be deployed. Business logic? We need Enterprise Java Bean, baby. If there are 100 concurrent users, then the system should be hosted in a farm environment with 2 web servers, 2 application servers and 1 database server. And architecture design won’t stop until these architects have put all 23 GoF patterns and one dozen of enterprise architectural patterns which they just learn from a book into their Visio diagrams.
- The no-news-is-good-news architects. These architects are afraid of new things, those they often insist to be “unproven” and “risky”. Some of these architects are of same group as the nothing-but-nail guys, i.e. they are so proud of their bag of tricks that they feel no other technologies are relevant and all problems are the same. The others are way behind the technological trends that they feel threatened by new technologies and tools. The arguments these architects often use to turn down new ideas include “it will never work”, “this is not practical”, “we already has proven methods, why bother such risky solution?”, or even the discussion-stopping message “I have solved this problem before, I know what works and what do not.” I remember an occasion in which I observed a senior architect criticized heavily the design of another architect who “dared” to suggest the use of Amazon’s SimpleDB as the storage engine for their new web application. Arguments used by the former include “database over HTTP is simply unacceptable”, “we don’t need those thousands of servers in Amazon’s farm”, and “you are bringing extra risk for us by introducing another node of security”. The poor latter architect, he did not know he was suggesting something which was radically new to the mind of the former.
- The do-as-I-said architects. Unlike the no-news-is-good-news group which bashes against new ideas, this group turns down whatever ideas not coming from them. This type may not necessarily feel threatened by new things, they just feel like their ability is being challenged by ideas they did not think of from the first place. If they think using Open ESB should be used, then any suggestion about BizTalk, or a home-grown integration solution that does just the job well will be turned down. Even if they do think the latter two are better ideas. Similarly, they will turn down any “RESTful” ideas because it’s WS-* that they propose in the first place even if they understand that the REST alternative may save them bunch of implementation efforts. Just do as they said and all is good.
- The silver-bullet-obsession architects. This group stands on opposite end from the no-news-is-good-news group: they are crazy about new things. They are so interested in fads and buzzwords that they include these in any presentation they make and any design solution they propose. To these architects, it’s just cool to talk about and use new things while completely dismissing the relevancy of such things to the problem at hand. EJB? So old-fashioned, let’s use RoR. Ajax? Forget about it, RIA is the future. RIA by Flex? Silverlight with managed code is the key. ORM is the past, it should be LINQ-2-SQL all the way down, baby. And they keep spending their career looking for more silver bullets.
- The UML-only architects. If you have read my essay, The Code is the Design, you should be able to guess how bad I feel about architects who think coding is only for the wimps. Indeed, there are architects who think that if they have to write the code then there’s little distinction between them and the plain old poor developers. They think that the role is to direct, i.e. draw some diagrams and handle them out to the coders who will “realize” the design. They argue that coding is just a simple step if the design is done right. Some may go as far as stating that they don’t even need to know how to code in a language or understand the ins-and-outs of a technology before architecting a solution using those language and technology. For example I met an architect who admitted that he had not coded any single line of Java code but thought that he would do fine when architecting enterprise JEE applications. “As long as I have good Java coders to implement my design,” he concluded. A joke? Not at all. True story!
There, we have seen the 5 groups of architects who have somewhat been successfully in ruining the software architect role in the eyes of other people. It’s high time they threw away their arrogance to not look down on others’ opinions, got pass their boosterism to use the most appropriate tools for the problem at hand, and acknowledged their ignorance by continuously learning and keeping up with technological trends. And last but not least, it’s high time they started writing code again… And if the software industry has any luck, 5 or 10 years from now some developers may come across this post and think I was joking.