Recycled Bullsh-IT

One of the unintentionally funniest parts of the Matrix sequel was the appearance of the Architect. Characterised as a cold, humourless man sitting alone in an ivory tower, he talked flowery bollocks, and was trying to remove free will from humanity. Not at all like the Enterprise and Solution Architects we all know…

I know it is easy to dis Architects – as this blog will prove – but it is worth reflecting why we have them and what value they are to organisations and projects. So, how did these roles come about? Ironically, rather than coming first before we wrote any code, the architects appeared late in the history of computing as the industry woke up to the challenges of developing, changing and maintaining more complicated software. 

The earliest information systems frameworks appeared in the 80s from IBM and John Zachman, aimed at classifying the domains and layers that provide a blueprint for development. Over time IS architecture evolved, with Zachman and TOGAF the main frameworks used and abused by an industry trying to evolve from a black art to an engineering discipline. For a large minority of IT professionals with a tendency along the autism/Asperger’s spectrum (me included), the chance to categorise, catalogue, and count all the components of the IT hardware and software estate, rather than interact with the wetware (other people) was immensely attractive.

Since then, the role of the Architect has evolved in three directions: Enterprise (or Wide) Architects; Domain (or Deep) Architects; and Solution (Pick ‘n’ Mix) Architects

Enterprise Architects (EAs) are closest to the Matrix mould, with aspirations to own the overall way that not only the IT ecosystem is built, but to muscle into the wider business and tell them how to structure themselves. The latter pretension is always fun to watch, and take bets on whether they make a quantum of difference after being completely ignored. In many organisations they will go around in packs – surely we only need one enterprise architect per enterprise? – and assault the project teams trying to sneak through some quick and dirty change to placate their demanding sponsors. This ambush, usually known as the (Technical) Design Authority, will review the project deliverables against their TOGAF framework to ensure it conforms to an “agreed” (only by the EAs) set of principles, reference models, catalogues, standards, and patterns, and if you are unlucky, methods, capabilities and competencies. There will obviously be no way the deliverables will get through unscathed: The smart PM knows which part of the design to sacrifice to get through the TDA. 

Although the EAs have a wide knowledge across all the whole estate, they are unlikely to have in-depth knowledge of specific domains. This is where we need the:

Domain Architects. The accelerating complexity of computing has led to increasing specialisation across a number of towers, e.g. Data, Network, Security, Application, Integration, Infrastructure/Cloud, Digital, etc. Traditionally, you would point your least customer-friendly and most anal geeks at these, put them in a dark corner with the manuals, and call them Technical Specialists. Like the rest of IT, job inflation has turned these roles into Data/Network/Security/etc Architects, who see themselves as the new elite (or more likely L33T). In fact, they are so L33T they have their own languages and dialects, consisting almost entirely of TLAs. You will see them fighting in their cubicles on who has pwned the few remaining Three Letter Acronyms of the 37,856 possible. Their day job is to advise projects on what to look out for in each of the domains, so that it works and will be likely to pass the TDA. They are also likely to support the EAs in pronouncing (in TLAs) at the TDA on what they like and don’t like about the project deliverables.

So how do the project teams best prepare for the TDAs? Enter the Solution Architects. Not literally, of course.

Solution Architects. Back in the day, to help interpret what the user wanted into what the developer had to program, you would have a Systems Analyst. The SA was social enough to talk requirements with users (or Business Analysts at least) and technical enough to converse in logic with the programmer. Again (more complexity, job inflation) these roles morphed into that jack of all trades, the Solution Architect. Typically looked down on by the Enterprise and Domain Architects, SAs know their place. Which is working with the project teams to come up with a cunning design (which is why they also used to be called Solution Designers) with which to trick convince the TDA into approving the components of the solution. To be able to do this, the SA needs to know a little about a lot of technology. But unlike the EAs, who only deal with the conceptual, the SA needs to have more practical knowledge about what will really work rather than what will look pretty in PowerPoint. A good SA will be as cunning as a fox who’s just been appointed Professor of Cunning at Oxford University (©Blackadder), and will be tenacious enough to grind out a complicated compromise of a solution that displeases as few important people as possible. 

So where does Morality fit into this diatribe? Other than namechecking a classic OMD* album, there is a bit of a moral maze in the role of architecture in IT these days. Some large companies can afford to have an army of architects providing these separate functions with discrete responsibilities for governance, technical excellence and solution design. However, these architects can sometimes become so detached from the difficult, dirty job of delivering real value now for their organisation that they might as well wear a white suit, randomly spouting ergo and concordantly. Knowing when to relax and allow a good enough solution through is a rare but respected skill. (The Architect: “The first matrix I designed was quite naturally perfect. It was a work of art. Flawless. Sublime. A triumph only equalled by its monumental failure.”)

Most organisations, if they have architects, will want these people to be Judge, Jury and Executioner, having the moral hazard of drafting, reviewing and approving their own designs. Some individuals will be easy with this, some will abuse it, and others will be distinctly uncomfortable. Most will do all three. If you are in that small a function, you could consider some outside independent governance, if your minuscule change budget will stretch. Otherwise buy yourself three hats/wigs/caps and try role play, which as a good techie you probably do online and in a field at weekends with your mates anyway.

John “take the red pill” Moe

*one less TLA left. Or is that one fewer…