I’m glad you find by blog interesting!

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.

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.

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.

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

Peace!

Earlier in my career, as a developer I just simply accepted the given architects 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?