The Unsure Architect
The trouble with the world is that the stupid are cocksure and the intelligent full of doubt — Bertrand Russell
While written in an entirely different context (in late 19th century), the above quote fits very well with the software architects in the IT industry. BUT, I don’t really think its a ‘trouble’ that the intelligent architects are full of doubt… that’s the way it must be !!
After having interviewed more than a few software architects, I realize that a common theme across, is that the ones that I don’t find suitable, are usually those who boast to have found the magic bullet to make huge IT projects successful, by the sheer beauty of their future proof designs, right technology choices and perfect execution plans, ‘upfront’. The problem though, is that the notions such as future proof design, are only as true as the stories about Santa Claus leaving gifts on the Christmas eve.
But before we talk about Unsure Architects, let’s go back in time to study the origins of the term ‘Software Architect’. IT industry is a very young one, with the first traces of modern computation machines dating back only around 60-70 years. So, in the beginning of IT time, our industry was looking for inspiration from other existing professions, to coin terms/ideas/processes/strategies for itself. That is when (unfortunately) we decided to borrow the titles ‘Architects’ and ‘Engineers’, thereby equating us to construction/production industries at some level. And to be fair, for the first 50 years, we did work like them. Architects created blue-prints, engineers implemented them. A bad blue-print meant large project failures with massive costs, somewhat similar to a civil architect creating a bad bridge design. With such responsibility, architects were people wearing suits, sitting in shiny offices (ivory towers) and never smiling.
But the advent of ‘agile development practices’ in the last decade or so, changed all that. If I were to write the single biggest contribution of the agile bandwagon, it would be that it brought the cost of failure down, and by a magnitude. A software project, instead of being similar to building a bridge, became more like planting a garden. Gardners do start with an idea of how the end garden will look like, the kind of trees on the outer circle, the species of grass, variety of flowers etc. But they may soon realize that the soil is not suitable for a chosen flower variety… or the owner doesn’t like the roses and now wants dahlias instead… Also, a garden needs constant pruning and maintenance, replacement of dead plants/weeds, protection from pests etc.
Similar to a garden, modern software products are (or must be) built in small iterations where changes or even failures are common. And similar to a garden, a software product is never really done… it requires constant maintenance and pruning (lest it will die eventually). And in this constant evolution process, the idea of an upfront complete design and execution model doesn’t really fit. When a software project starts, an initial design and plan is indeed needed, but that’s just a broad vision. The actual details evolve as development teams go deep into execution, and start getting constant user feedback (basic tenet of agile development). The end product might match somewhat to the initial design, or might be something completely different.
So, what then is the role of a modern architect. What good are they, if there isn’t a need for an ‘architecture design’, and is having an architect an anti-pattern in the agile world?… Well, on the contrary, a modern day software architect is needed all the time, as against ivory architects who were mostly needed only during the ‘initial’ design phase. Instead of providing an upfront magical design, they must now constantly innovate ‘with the team’ and be part of development, just like any other scrum team member. They must not be ‘too confident’ that their initial hypothesis (all designs are just hypothesis) is infallible, willing to course-correct (or even reverse) whenever needed. The ones who follow this approach, are who I call as the “Unsure Architects”.
Posted on: 11th November 2017, by : AdityaBhushan