The 5 Types of Poor Architects

June 20th, 2008

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.

  1. Bart Czernicki
    June 20th, 2008 at 22:14 | #1

    Nice functional breakdown of the architect roles.

    The “UML-only architects” I call them paper architects, because your not doing just UML…you do Workflows/Class Diagrams/Visio/ERD (haven’t done “true UML” I dunno how long), but those kind also deliver internal white papers/coding practices/post mortem reviews etc. Hence their role is to push tech papers around.

    It would be nice to follow this up with a matrix of some other things. Usually I find, the people who are the “no news is good news” architects fell into their job and are the more old school type.

    The “silver bullet” architects is interesting, because I find those to be who are less mature in the industry or understanding the whole scope. I remember having a discussion with an architect about web parts back in 2006 and doing SharePoint/custom portal implementation. He was very insistant on AJAX and our framework needed it. SharePoint SP 1 and .net 3.5 address a lot of the problems, but AJAX in web parts was a complete mess back in 2 years ago. (you can still google the workarounds people did to get stuff to work). My motto is: if there are workardounds just to get a stupid combo box or a label to refresh..u might want to stay away from that technlogy.

    “Nothing but nails” is usually that guy that is really good with theory and intimidation. Is too good to understand that not everyone in the development staff is a delegate/multi threading/n-class hierarchy design guru. Usually, you have this person having the “holier than thou” ego as well.

    Plus certain architects fit in much better in different size organizations. For example, sivler bullet type (R&D, prototypes, first to market) greater role in smaller companies. The UML/nothing but nails/no news are the Fortune 500 company architects…keep the status quo.

    I could write more…this was one of the 10 or so articles I have in the backlog for my site as well :)

  2. June 20th, 2008 at 22:38 | #2

    “That said, these people are very eagle to apply overkill technologies to solve even the simplest problems.”

  3. June 20th, 2008 at 22:51 | #3

    Interesting categorizations, the positive categories? What do you think constitutes a “good-enough” architect? How would you suggest one balance the silver-bullet mentality against the risk-shunning no-news-is-good-news mindset?

  4. June 20th, 2008 at 23:06 | #4

    The worst in my personal experience are the the “no-news-is-good-news”.
    They always speak like “I saw things you human will never see” and make the technology be irrelevant since “it’s all the same shit”

  5. June 21st, 2008 at 00:11 | #5

    This is a good list and I recognize some people I have worked with in these categories. A couple of good follow up posts would be “How to avoid being a difficult architect” and “Strategies for working with a difficult architect.” These would be useful because like any platform, you cannot always choose the architect for your projects and you need to work with them. You may also be assigned as an architect for a team of junior developers who also fit into these categories as well as embracing new ideas while also leveraging proven concepts is always the balance an architect tries to find. The one rule I try to follow lately is, “If it works, it works.”

  6. ton
    June 21st, 2008 at 00:28 | #6

    Whoa great post! I know an architect who is a mix of all the first 3 poor architects. :P Oh man funny post.

  7. June 21st, 2008 at 03:36 | #7

    Crap, I’m the silver-bullet-obsession architect. Once AI comes out, I’ll be proven right! That will solve all of our problems!

  8. June 21st, 2008 at 03:36 | #8

    Me too and I have to add more:
    – Who read a lot of books and attended conferences without ever write one line of code.
    – Who changes the code without tell who is working on it.
    – Who needs an interface for anything ….
    – The Design Pattern Maniac.
    – Who can understand just what he wrote.
    Let me stop.


  9. June 21st, 2008 at 16:25 | #9

    I disagree with the “silver bullet one” because IMHO role of architect is to be informed about all the cool new technologies coming to market because he is the one which should suggest them to business people because early adoption of a technology can give competitive advantages over competitors and by that generate additional revenues

    A perfect example for what I have on mind is a thing you mentioned: Ajax vs RIA… Adopting SL (or FLEX) can result with differentiated UX and possibly with reduced TCO (lower bandwidth consumption, easier to make Silverlight rich UX then heavy Ajax client side experience)

    All this been said, it is important for architect to differentiate hype from usefulness and business opportunities

  10. Bart Czernicki
    June 22nd, 2008 at 04:07 | #10


    Just to add to your like I mentioned above…a Silver Buller Architect is perfect for a SMALL/STARTUP company. I can list drawn out examples of good/bad, but the best example is in the undertones of the show “Start-Up Junkies” on MOJO. They started with a traditional LAMP architecture and then had to port everything to .NET/WPF (nothing wrong with LAMP), but having an architect know this ahead of time and know the new emerging tech out there, they might of not had this problem.

    For those that don’t know…Start Up Junkies profiles the company Earth Class Mail, that makes ur snail mail available to u online (screams for WPF), stuff that is a little harder to do with open source tools.

  11. pigbert
    June 22nd, 2008 at 13:15 | #11

    Very interesting article ^_^

    I don’t think the silver-bullet type is all that bad. They simply have an attitude problem, which could be corrected as time goes on. They are at least smart and fun to talk to, and they’ll be an asset if used in the right way ^o^

    The “no-news-is-good-news” type simply shouldn’t be in this fast growing industry… They should go find another job, something like a primary school teacher (no offense ^_^)

  12. June 22nd, 2008 at 14:03 | #12

    Thanks for your comments & suggestions, everyone!

    You make many good points! The SP web part & AJAX example is excellent. I totally agree that certain emphasis is necessary for architects in different organizations (or even different departments of the same organization), as long as they don’t go to the extreme. Looking forwards to seeing your article then.

    IMO, balancing is the key. For example, good architects won’t go to any extreme by rejecting new things completely or only using new tools for the sake of fun & challenges and neglecting risks and ROI. They keep an eye on the trends, knowing which tools can work in which situations (and which are plain fads) and yet use the plain old things to solve problems if no new tools are more productive or relevant. They do know architecture is important but yet don’t neglect the complexity of the details and how these details can actually affect the big picture. They welcome others’ opinions and use feedback to improve their decisions and at the same time know when to stop discussing and make the call…

    The point is that architects are paid mostly for making judgment about the use of technologies to solve problems. It’s almost impossible to make every decision right, esp. in a fast-changing industry like computer software, but the ability to make more correct than incorrect decisions is the difference between good and the not-so-good architects. And correct judgment can hardly come from architects who belong to one or more of the 5 categories described in this post.

  13. June 22nd, 2008 at 15:10 | #13

    I’m sure the machines will eventually be able to implement a requirement or design document fed to them. (Actually things like MDA, software factories and code generation are helping with part of the task). But that’s a long way from now and I don’t think silver-bullet-obsession architects will help us get there :-) .

    Very good examples. Thanks.

    @Nikola, @pigbert:
    I completely agree with you. I never meant architects should not look beyond the existing status quote and try out new things. In fact, I do think it’s highly necessary for architects, especially those work in the environments that Bart and some others pointed out (start-ups, R&D…), to stay on tops of new things, extract germs from dust and find applications and opportunities from them. It’s only problematic if the architects only care about using cool stuff for the sake of self-interest (or challenge) and neglect the relevancy and applicability of their choices.

  14. June 22nd, 2008 at 15:14 | #14

    Good point! Realizing a problem is one thing and know how to effectively deal with or workaround it is quite another.

    Earlier in my career, as a developer I just simply accepted the given architecture and could do nothing about it. For example, I worked as a developer in a project with an architect who came up with an architecture design employing a bunch of J2EE patterns, although the application is a thick-client desktop app with no J2EE involved, and forced people to follow. That project was a disaster in terms of software architecture and as I recall I can only say that the design was nothing but seriously flawed.

    When being an engineering manager, I have the bless to select architects for my projects and I just simply reject the unqualified ones (i.e. those belonging to one of the 5 categorizations). I fortunately never miss this shot but if I will, I have the option to get rid of the poor architect instead of accepting him/her. Therefore, I have been thinking less about how to deal with poor architects than how to distinguish the good from poor ones.

    However, I agree with you that in some platforms we just have to work well with the given and strategies to deal with them are highly useful. For that, I currently don’t have enough of experience to come up with very useful advices. But I’ll definitely think about it though and hopefully there will be some blog posts as a result of that.

    Have you faced such circumstances and do you have any advices?

  15. Architect NV
    June 24th, 2008 at 08:12 | #15

    It’s become fashionable for developers to bash on architects, since most developers have a frustrated desire to one day have that title. Let’s examine real architects (you know, the ones that design buildings). We have carpenters and we have architects, and they’re on completely different levels. Carpenters also tend to bash these architects, but one has to question the motivation behind that. Do you really think all architects can be grouped into such boxes? Maybe the architects you speak of are not real architects, much like there are carpenters (developers) who tell their cousins that they can design and build a house. Perhaps after a few more years of learning.

  16. June 24th, 2008 at 10:15 | #16

    @Architect NV:
    Thanks for your comments.

    It’s become fashionable for developers to bash on architects, since most developers have a frustrated desire to one day have that title

    Since you’re commenting on a post bashing the poor architects, I suppose you’re also thinking that I’m too yet another developer hoping to be an architect one day. If not, I’m sorry for the poor assumption. But if that’s what you’re suggesting then you’re wrong about that. I’m an engineering manager who staffs architects for my projects. But first, this post discusses about the poor architects, not about ALL architects. (I did mention in the post that there are many talented architects out there and I fortunately had the chance to work with some.) If an architect writes a post bashing poor managers then I hope you don’t think that architect hopes to be a manager one day.

    With the same assumption, IMO, if you don’t agree anything about this post, then providing your reasoning about the disagreements is much better than simply say “Role A tells bad thing about Role B because those in Role A wants to have Role B but can’t be”.

    Do you really think all architects can be grouped into such boxes?

    I clearly don’t think all architects can be grouped in these boxes – these are groups of poor architects only.

    Maybe the architects you speak of are not real architects, much like there are carpenters (developers) who tell their cousins that they can design and build a house

    Depending on what you refer to as “real”. I put it clearly in the first paragraph that I refer to both those who have the business title as well as those who happen to play architect role in their project (i.e. their managers & members call them architect, not just their cousins) :-) .


  17. Sk. Adnan Islam
    June 27th, 2008 at 08:43 | #17

    planning should be introduced in architecture for sustainable development.

  18. Athanassios Papageorgiou
    June 27th, 2008 at 14:48 | #18

    There is always the other side of the same coin.

    If an architect can be (based on the situation) any of these types of architects, he/she can be a good architect, at least as far as business reality is concerned.

    The “nothing-but-nails architects” are good when you have to work in a company with many projects and technical teams that have people coming and going (resignations, movement of people between teams, new recruitments etc). In such cases you have to see all as nails, it is very difficult to have different strategies for each project and still cope with team changes. Of course in such companies “silver-bullet-obsession architects” would be required so that hammers and nails do change over time.

    The “no-news-is-good-news architects” are good for maintaining existing systems with low maintenance budget. Start using new technologies is bound to increase the problems and thus the budget.

    The” do-as-I-said architects” are good when you have short deadlines and a junior technical team (full of ideas, which is good, but not on certain occasions).

    The “silver-bullet-obsession architects” are good for prototyping new products, deciding on the technologies that a company is going to adopt. You have to try new things if you plan for the future.

    The UML-only architects, are necessary in huge projects that require a common language (UML) and documentation available for all.

    Of course there is no architect or developer that would agree that the above are good in an optimal world. But, reality is far from optimal so one has to adjust. Remember that, at the end, the goal is to create useful software systems within budget and time. If one had unlimited time and resources than one would be “find the optimal solution architect”, but none is.

  19. June 27th, 2008 at 16:13 | #19

    @Athanassios Papageorgiou
    Thanks for your comments. I agree with the point that at certain circumstance one style should be more appropriate and thus emphasized than the other styles. However, I disagree that architects strictly belonging to one of these 5 styles are good architects.

    You mentioned that UML-only architect is acceptable in huge projects – but by “UML-only”, I mean the type of architects who knows little about specific technologies and can only draw some diagrams and then ask others to implement. That’s far different from architects who are well-versed in both the big pictures and the details so that he can jump to perform code review and mentor developers in his team.

    For the do-as-I-said, I really mean architects who just do not accept ideas from others as long as those ideas do not come from them in the first place.

    For the nothing-but-nails, even for maintenance projects it’s still better if the architects look out for new tools & techniques that can increase the productivity of the team.

    And the silver-bullet-obsession, I meant those who just spend their time learning and using new things and disregard the relevancy of such new things to the problem at hand altogether.

  20. August 7th, 2008 at 11:04 | #20

    This post is interested.
    By this post, I wonder how to become a good architecture. And when i read all comments, and in my own opinion: a good architecture is a man have all 5 above attributes.

    When I were young, I was interested in Doreamon comic, i remember the story: “Nobita dream to be a handsome man, and doreamon help him with a special toy. But when Nobita want to be handsome, he must loose something for that : his health, his clever …”. So, in this case, I imagine that when you have 100 coins ( of course, better architect will have more coins :D ), and you have to fill in 5 bottles. All of these bottles are required for a good architure, so when you fill all coins in one, you can’t be a good. But when you lack one of them, you still a poor one.

    Besides, I want to talk about another kind of architecture ( not good , not bad one, but interesting). I call these “Home-made” architectures. These man love technologies, reading much and find out other frameworks are not suit for him, and he build another one for him ( in some words, he like to “reinvent the wheel”). For example, when using .NET, you known that XMl Serializer is built-in. But after using it, he decide to develop another.Now, his Xml Serializer is faster 3x than .NET, and file size is 2x smaller.

    PS: Mr Buu, thanks for your blog, there are many interesting posts here.

  21. August 7th, 2008 at 13:32 | #21

    That is another interesting type. (How about “Not-invented-here architects”?) Talking about the good architect, I think a person who exposes exactly one of these behaviors is bad enough, less 5 of them… (Imaging having an architect who never cares to listen to his subordinates and is only good at drawing UML diagrams in your team. Yes, I knew no less than one such architect.) The good architect, IMO, is the one who does not go to any of these extremes, i.e. technically competent yet know to listen, staying on top of techs yet not fooled by hypes…

    I’m glad you find by blog interesting!

Comments are closed.