Kruchten: Antipatterns

Picking up on the theme of antipatterns, let's look at a list provided by Philippe Kruchten in his whitepaper "What do software architects do?". This paper, by the way, is another good source of perspective on the emerging discipline of Software Architecture.

Antipattern: Creating a perfect architecture, for the wrong system.

A software architect that is not communicating regularly with the customer, the end users, or whomever represent them (the product manager) is likely to miss the target, in particular as the target is moving, or rather, as the target is only gradually understood.

Antipattern: Creating a perfect architecture, but too hard to implement.

A software architect who does not understand the (maybe limited) skills, capability and experience of the implementation team(s) that will continue and finish the work will create enormous level of stress and frustration, and likely not deliver a quality product in time. The architectural effort has turned into a computer science research project.

Antipattern: Ivory tower

The worse combination is the architecture team that lives isolated in some other part of the organization - another floor, another building, another country - and who comes up after some months with a complete architecture, out of the blue. To their complete surprise, they will experience rejection: an apparent misfit on both front, functional and implementation. This is especially the case if the developers (the non architects) had a few months to make some progress and they have in some ways made some architectural decisions, under some other name. A special case of this antipattern is the architecture group that only scouts technologies and provides recommendations to other groups, but is not making design decisions and is not accountable, as I have witnessed in two large telecommunication companies, the architecture watch..

There is another issue that cannot be completely ignored; it has to do with whom you have chosen to be the architects. It is very likely that you have in this role some of your most talented staff: good at manipulating abstractions, wide experience of a range of systems and technologies, good communication skills, domain knowledge, etc. and you may want to use some of these skills for other tasks than just building architectural views. You want them to speak to the new prospective customers, to show off the organization technical expertise, you want them to help this or that team that experiences a difficult technical issue, you want them to review the architecture of another project, to take part of a due diligence process to acquire a company, to present papers a conference to strut your stuff, or merely extinguishing some nasty fire. But if you are not careful, this leads to another "antipattern:"

Antipattern: The absent architects

No or little architecture design progress is made: the architects are always away, doing fascinating things, or fighting fires. It is very easy to slip in this mode, especially after some initial good progress and early successes, which brought some fame on the architects.

Have you seen examples of these anti-patterns in action? What were the results?