Five Software Architect Antipatterns

I believe that all software design comes down to trade-offs, and the only way for software architects to get to the right decisions on those trade-offs is for them to have a very broad and senior role within their organisation. I’ve observed some people in the industry who are called architects but, for one reason or another, are not in a position to design software well. Here are five types of software architects that are ill placed to actually design software.

1. “Well Paid Programmer” Architects

Sometimes, giving people the job title of Architect is just a way of giving them a pay rise without their job materially changing. Some architects are really just programmers who reached the top of their pay scale and didn’t want to manage people. In theory they’re supposed to be setting the technical direction but in reality they’re no more influential than an opinionated developer. Quite often they’re locked in conflict with other developers about the direction of the system being built and lack the necessary clout or managerial backing to enforce architectural decisions.

Lesson: Software requires tough choices to be taken, once you’ve found the right person for the job, they need management backing and they need the strength of their convictions to own that role.

2. “COBOL Programmer” Architects

Some architects are programmers who got stuck on an old technology that their company doesn’t use any more; But making them an architect is a way of keeping them around in case those old systems fall over. These architects spend a lot of time getting involved in non-work related bits and bobs. You’ll find them on the fire safety committee, they’ll be one of nominated first aiders in the office, a regular organiser of corporate charity fundraising events, they always have plenty of time to help the support team with the aforementioned COBOL system and they will always have an apt anecdote from the days of 80 column card interfaces or EBCDIC encoding. They don’t really know how to code in the languages that are used by the developers these days and they have an annoying habit of referring to IE as “Mosaic”, but they can just about cost up a new server, given a few days notice.

Lesson: Software Architecture is a real job that people need doing, its not a way to put old techies out to pasture. If you want to keep those people around then fine, but call them “Consultants” or something and hire a proper architect.

3. One Tick Architects

Some architects know one thing, like Networking Configuration or Relation Schema Design really really well but little else. Designs get written which explain in fine detail how the subnets of the servers’ network cards are going to be setup, but skip casually over whole areas of detail with statements like “A suitable object relational mapping technology (Linq2SQL/EF/NHibernate) should be used”.

Lesson: You’re skills in one discipline may have been enough to get you the architect job, but the value of the architect is in their cross disciplinary skills; To do your new job well you need to start learning news skills, and fast.

4. Back Room Architects

Some architects lack the basic personal skills to be allowed out in front of customers or users and consequently come to view their role as a purely technical one. Unaware of the political and budgetary landscape their projects are operating in, their designs are masterpieces in resilient, scalable, flexible and buzz word filled architecture which, if actually followed, would cost millions to complete. These architects are perpetually locked in battles with project managers over how much time it is reasonable to spend building each system. Look out for phases like “one day we’ll actually build a system right from day one” i.e. they see software architecture as a binary good vs. bad issue as opposed to a series of trade offs.

Lesson: All decisions in software design are compromises between development time, hardware cost, supportability, usability, maintainability, tooling costs, recruitment considerations, staff retention considerations, the aspirations of the people paying for it, the actual needs of the users and many other things, you can’t understand all those competing influences by sitting behind a desk running Emacs, you have to get out there and talk to people.

5. Non-Technical Architects

These architects are really just business analysts. They are great at talking to customers, they spend lots of time capturing the non-functional requirements of the system and writing documents that list those non-functional requirements for the benefit of the developers and server engineers. But as far as solutions go they haven’t a clue. They are full of handy suggestions like “we should do some performance testing” but when asked what to do with the results, they fall back on sledgehammer solutions like “buy a better server” or “get the programers to add some caching”.

Lesson: If you’ve somehow made it into an architect role and you’re NOT a C Hacker/SQL Guru/Bash Ninja then you have a problem. The techies will soon start to figure you out and your authority over them is dependant on you reaching some minimal level of technical ability. Find a way to start adding value to what they do before they give up on you.


I'd love to meet you on twitter here.