Many times I've heard it said that software architects should be hands-on - they shouldn't be in an ivory tower. They should still be coding, one foot in the game. There is so much to unwrap from this!
Hands-on
First of all, yes, architects should be hands-on. To me this means engaged, reactive to and even in front of the challenges that the business is confronted with. They should also be helping the business evade those challenges. Not asking much, eh? 🤔
Hands-on is often referred to as being a synonym for coding. This couldn't be further from the truth, as actually when you have a multi-disciplinary team, or are working across different levels of abstraction, the scope is much broader. If you use the term engaged instead, you are considering who the architect is working with, rather than what they are doing. The broader the scope, the better your awareness of context, and the better the influence of everybody in the organisation and product decision-making processes.
Examples of strong engagement include:
🔍 Finding problems in the captured requirements
🧪 Uncovering test strategy limitations or challenges
🚨 Reviewing and assessing operational tickets
🏗️ Understanding team CICD pipeline workflows
🚩 Pioneering and educating around the team's use of platforms
Examples of engagement vary up and down the architectural stack, as the artefacts, business processes and stakeholders will change, but the same principles of linking people, perspectives, and most importantly experiences remains.
Ivory Towers
Let's now address the aspect of ivory tower architecture. To me this brings about imagery of an architect in a rapunzel-like tower, absorbed in their ideas for what could be eternity. It also suggests altitude, suggesting that there is a long distance and barriers to accessibility for those around them in the business - the architect's ideas are never tested, and do not fit with a broader business strategy.
Does being a coding architect resolve these problems? Not at all, if the architect were to stay within their bubble! Furthermore, if the architect spends too much time coding, rather than providing and understanding perspectives, then the development teams and business are without an advocate. Experiences and perspectives remain unshared; they will code quite happily from their ivory tower uninterrupted.
The analogy I would use instead is to have your architects visiting and involved at the construction site, not laying bricks.
Caveat
It's worth saying I do code, work on IaC, data, pipelines, etc as an architect, and the amount of insight you gain from an hour or two in new contexts is remarkable, but that degree of insight gained is exactly the same from the same time spent across all of the other activities I outlined previously.
Coding isn't the cure - it is one of many sources of vitamin D.
©️ Read the Architecture Ltd.
Top comments (0)