You are currently browsing the category archive for the ‘Humour’ category.

I originally published ‘The Usual Suspects’ in August 2006 and at the time it seemed to strike a chord with the beginning of the anti-architect revolution.  In the three intervening years the use of the ‘architect’ label has become a title that any self-respecting developer doesn’t want and is synonymous with someone is no good at software development.  I thought that on the three year anniversary of the original post it was time for un update by including the architects that have emerged more recently. Also, apologies for the masculine reference to the architects – there are some women out there doing bad architecture as well.

The Hammer Architect

The Hammer Architect knows one tool reasonably well, although because he may also be a Non-Coding Architect, may only know the tool that everyone stopped using five years ago.  The Hammer Architect sees every problem as a nail perfectly suited to his hammer and bangs away relentlessly like Bender in a steel drum with Paris Hilton.  Hammer Architects leave behind solutions that had promise after two weeks (when the prototype was delivered) but months into the project seem not to have moved beyond the initial prototype because the wrong problem is being solved.

How to spot The Hammer Architect

Hammer Architects are closely aligned with the marketing arm of the hammer vendor and, when the project is going awry, are able to wheel in a technology specialist from the vendor’s marketing department who is able to reinvigorate the sponsors and confirm that The Hammer Architect is doing a grrrreat job.  You will also find that The Hammer Architect will send you links to nicely formatted case studies on the success of his hammer as implemented in a different country, a different region, language and currency and in a different industry that apparently solves a problem completely unrelated to your own.

The Community Architect

The Community Architect thinks that his customers are impressed with his ‘Architect’ title and assumes that the technical community will also be suitably impressed.  He stalks unsuspecting user groups and conferences offering to do presentations where the subject may look compelling but is delivered blandly and where the entire presentation is so lacking in anything remotely compelling that half of the audience are asleep and the other half are engrossed in their mobiles looking out for interesting tweets.  The Community Architect doesn’t get much feedback and people are polite in the breaks, ushering him on his way, thankful thanks he will present next month to a different user group.

How to spot The Community Architect

The Community Architect is generally quite senior at a small ‘consulting company’ with an unremarkable name that, although on every slide, is forgotten three minutes into the presentation.  A Google search of his name returns links to a guy from a country town that is suspected of beating his mother-in-law to death with a with a hosepipe and, since you can’t find any technical references, content or blog for The Community Architect, you begin to think that it is the same person.  The first slide in their presentation has the word ‘Architect’ in the title and ‘Architecture’ on virtually every slide.  If you stayed around long enough to collect a business card you would see that their title contains all of the following words – ‘Architect’, ‘Consultant’ and ‘Senior’.

The Non-Coding Architect

The Non-Coding Architect simply became so good at coding that he reached a spiritual coding nirvana where his mastery of code was so high, and so pure, that he had to move to another plane of coding consciousness and leave the code behind altogether.  Because his code was so pure he can understand all technical problems just by reading a product announcement on the vendors’ website, watching a video and meditating.  He is able to pluck the essence of the solution out of the aether, which in turn gets handed down to the unwashed developers for implementation.

How to spot the Non-Coding Architect

Non-Coding Architects are difficult to spot because they masquerade as Enterprise Architects and can even produce documentation or blog posts that give you the impression that they have written code in the last few years.  The easiest way to identify a Non-Coding Architect is to invite them (in a grovelling manner of course) to help you solve a programming problem you are having – right there in the IDE.  The Non-Coding Architect will not grab your keyboard and push you out of your chair, but will feign an almost solution that he needs to go and try out on his machine before he gets back to you – all while making suggestions on how to adhere to his coding standards guidelines.

The Driven Development Architect

The Driven Development (*DD) Architect has moved beyond TDD, BDD and DDD and is using the latest DD technique that ‘everybody’ (being the four subscribers to the SomethingDD Google group) is using and will radically change how we do development in the future.  He has a repertoire of at least 26 DD techniques and is developing support for UDD (Unicode Driven Development) to support even more techniques.  He is probably working, at this very moment, on a book and seminars called ‘Design Driven Development and Development Driven Design’ but is struggling with the approach because Eric Evans got to the ‘D’ first.

How to spot the Driven Development Architect

Driven Development architects are easy to spot because they use ‘DD’ and ‘Driven Development’ frequently in conversation, blog posts and tweets.  They always seem to introduce new DD techniques based on a very advanced and new framework or approach that is documented in two unindexed blog posts and seven tweets.  Driven Development architects interact with real development teams in the confidence that they are better than mere TDDers but when hanging out with other Driven Development architects they tend to fight a lot – mostly about how much better SomethingDD is than AnotherDD and who’s DD should get a particular letter of the alphabet (although unicode should improve this)

The Reluctant Architect

The Reluctant Architect is simply a good technical person that is called an architect because a) he was the most senior developer on the team when the previous architect quit or b) he was at the same pay scale for the last three years and ‘Architect’ or ‘Presales consultant’ were the only career paths available or c) his employer parades him as an ‘Architect’ in front of the customer in order to get better rates.  The reluctant architect does, surprisingly, actually do architecture but simply considers it part of building solutions.

How to spot the Reluctant Architect

Reluctant Architects are difficult to spot because they don’t actually tell you that they are architects.  The best way to uncover a Reluctant Architect is to look for someone that doesn’t claim to be one, does architecture and is indicated as being an architect on their business card or LinkedIn profile.  They also frequently deride self-proclaimed architects in conversations and posts such as this one.

Below are the original Usual Suspects from 2006…

The PowerPoint Architect

By far the most common type of architect is The PowerPoint Architect, these kinds of architects produce the best looking architectures on paper… I mean PowerPoint.  Great colours, no crossing lines and reasonably straightforward to implement… apparently.  The problem with PowerPoint architects is that they are so far removed from real implementation that architectures that they propose simply won’t work.  The PowerPoint Architect is generally a consultant who, just before implementation is about to start, picks up their slides and moves to the next project – leaving everyone else to implement their pretty diagrams.  The PowerPoint Architect believes that software development is similar to doing animations in PowerPoint and infrastructure is about how to get your notebook connected to a data projector.

How to spot The PowerPoint Architect

The PowerPoint Architect gives him/herself away by scheduling presentations in meeting rooms and having so many slides that there is no time to go into the detail.  If the meeting has more business and project representatives than technical staff, it was probably organized by The PowerPoint Architect so that technical questions seem out of place and should be ‘taken off-line’.  The PowerPoint Architect has also been known to use Visio.

The Matrix Architect

Named after ‘The Architect’ in the Matrix movie series, The Matrix Architect has been there so long that he/she doesn’t know any other way.  Matrix Architects leaves no room for improvement, discussion or negotiation as the architecture was written by them eons ago and has worked fine, thank you very much.  Much like the scene in The Matrix Reloaded, The Matrix Architect has a personalised, well defended office and if you manage to get in, you simply have to leave by one of two doors – without getting a chance to explain yourself.

How to spot The Matrix Architect

The Matrix Architect normally has their own office and is well settled.  Technical books on CORBA, Betamax and other has-been technologies are proudly displayed on the shelves.  The Matrix Architect can also be spotted by their uncanny ability to work their way into meetings and throw curveball comments like “That’s just like the SGML interface that we used on DECT and in my day…”

The Embedded Architect

The Embedded Architect creates architectures that are so huge and complex that removing them is similar to taking out your own liver.  Most of the time they do this for career stability or, if they come from an external organization are there to milk as much future profit out of projects as possible.

How to spot The Embedded Architect

The Embedded Architect is very difficult so spot during the embryonic stage when they are infecting the existing architecture and often once spotted it is too late.  The Embedded Architect often has a team of disciples that as a group understand the entire architecture, but individually know very little.  A requirement that new team members go on an induction course on the architecture is a sign that there may be an Embedded Architect somewhere within the organization.

The Hardware Vendor Architect

The Hardware Vendor Architect is actually a salesman with a reworked title.  The Hardware Architect’s role is to point out the flaws in everyone else’s architecture so that they can justify why the extra hardware expense is not their fault.  At Hardware Architect School, The Hardware Architect is trained in creating proprietary hardware platforms that create vendor lock-in.

How to spot The Hardware Vendor Architect

The Hardware Vendor Architect normally has a car full of pens, mouse mats and notepads emblazoned with some well-known brand which they use to assimilate the weak.  They also have huge expense accounts where they can take the entire data centre to lunch occasionally.  They are often heard saying things like ‘You need a 24×7 99.999999% disaster recovery site’

The Auditor Architect

We are not sure of the origins of The Auditor Architect, because they are supposed to be auditing things, not creating architectures.  The Auditor Architect will always propose an architecture that uses spreadsheets for every possible system interface that requires each user to be a CA so that they can review the transactions before they are submitted (not to be confused with The Auditor Project Manager who uses spreadsheets for all documentation).  Since most organizations don’t have that many CA’s, The Auditor Architect represents a firm that can provide as many CA’s as may be necessary.

How to spot The Auditor Architect

The Auditor Architect always wears a black suit, white shirt and an expensive tie in the latest fashionable colour and style.  The Auditor Architect will often go to great lengths to express that they are unbiased and just want to make sure that things are done correctly.  Most emails received from The Auditor Architect have spreadsheet attachments.

The Gartner Architect

The Gartner Architect has knows all the buzzwords and has all the supporting documentation.  They never actually put together a workable architecture but run ongoing workshops on the likelihood of the architecture looking a particular way at some point in the next six months to five years.  As soon as an architecture is established, The Gartner Architect uncovers some ‘new research’ that requires a suspension of the project while the architecture is re-evaluated.  Incidentally, sometimes The Gartner Architect is known as The Meta Architect.

How to spot The Gartner Architect

The Gartner Architect always does presentations with references to some research noted on every slide and the true test of The Gartner Architect is asking for the document that is being referred to – it won’t materialize.  The Gartner Architect is often accompanied by a harem of PowerPoint Architects eager to get their hands on the material.  The Gartner Architect is often entertained by The Hardware Architect, provided that they represent products that are in ‘The Magic Quadrant’.

The ERP Vendor Architect

True Architects for ERP systems do exist – but they hang out somewhere else, like in Germany, and not on your particular project.  There is no need for an architect on a system that if changed, self destructs within thirty seconds.  The ERP Vendor Architect is actually an implementation project assistant that is billed at a high rate.

How to spot The ERP Vendor Architect

The ERP Vendor Architect almost always has a branded leather folder of some really fun training conference that they went to in some exotic location with thousands of other ERP Vendor Architects.  A dead giveaway is if The ERP Vendor Architect and The Hardware Architect are exchanging corporate gift goodies – a sure sign that they are colluding do blame legacy systems for the poor performance.

The UML Architect

The UML Architect is not interested in any architecture that cannot be depicted using UML diagrams and spend a considerable amount of effort making sure that this happens.  The UML Architect lives in an object bubble and has no consideration that their intended audience never learned SmallTalk.

How to spot The UML Architect

The UML Architect is easy to spot from the documents that they produce.  All documents have a lot of stick-men, hang-men and and cartoon characters pointing at bubbles.  The UML Architect will always be able to describe the architecture by <<stereotyping>> it as something that you will understand.

The Beta Architect

The Beta Architect insists that the current version of whatever software you are using is going to be ridiculously out of date by the time the system goes live.  For that reason it is important that the development be done with the beta framework, operating system or development environment and not to worry, the product will be probably released before the system needs to go into production.

How to spot The Beta Architect

The Beta Architect normally wears a golf short with a large software vendors logo embroidered on the front and walks around with a conference bag suitably branded.  The Beta Architect normally comes from an external organization that has a partnership with a large vendor indicated by some metal, but always gold or platinum – bronze and silver partners are not worthy.

Simon Munro

@simonmunro

More posts from me

I do most of my short format blogging on CloudComments.net. So head over there for more current blog posts on cloud computing

RSS Posts on CloudComments.net

  • Free eBook on Designing Cloud Applications
    Too often we see cloud project fail, not because of the platforms or lack of enthusiasm, but from a general lack of skills on cloud computing principles and architectures. At the beginning of last year I looked at how to address this problem and realised that some guidance was needed on what is different with […]
  • AWS and high performance commodity
    One of the primary influencers on cloud application architectures is the lack of high performance infrastructure — particularly infrastructure that satisfies the I/O demands of databases. Databases running on public cloud infrastructure have never had access to the custom-build high I/O infrastructure of their on-premise counterparts. This had led to the wel […]
  • Fingers should be pointed at AWS
    The recent outage suffered at Amazon Web Services due to the failure of something-or-other caused by storms in Virginia has created yet another round of discussions about availability in the public cloud. Update: The report from AWS on the cause and ramifications of the outage is here. While there has been some of the usual […]
  • Microsoft can do it without partners
    Microsoft’s biggest strength has always its partner network and it seemed, at least for a couple of decades, that a strong channel was needed to get your product into the market. Few remember the days where buyers only saw products in computer magazines, computer trade shows and the salespeople walking through the door — the […]
  • The significance of Linux VMs on Windows Azure
    One of the most significant, highly anticipated, and worst kept secrets of the Windows Azure spring release is the inclusion of persistent VMs, with the notable addition of support for Linux on those VMs. The significance of the feature is not that high architecturally — after all, Windows Azure applications that were specifically architected for […]

@simonmunro

Follow

Get every new post delivered to your Inbox.