Who Is A Software Architect? — Part 2

In part 1 I looked into how the “order-making”side of a software architect’s role might ignite a certain resistance and even repulsion from those who are supposed to be taking the orders. Even if these “orders” are given by an experienced professional, who has certain weighed-out reasons for making a certain architecture/design decision, the others in the work group are likely to perceive those “orders” not as a well-thought-out guidance, but as an attempt at overriding and neglecting their personal input to the common cause. What I’m saying here might seem weird and incomprehensible to those developers who have never seen how an individual bosses others around only because of their job role as His/Her Majesty Software Architect. The monster order-makers, as a species, have mostly been shunned aside with the advent of the agile movement in the early-mid 2000’s, as the emphasis has shifted onto the collective way of making decisions. Including those related to software architecture. A junior developer, who hasn’t made enough meters on their professional lifetime’s odometer, and has only seen the collective side of decision-making, will probably not even be aware that there was a time when software architecture used to be a responsibility of just one person, and a person with the capacity to give unquestionable orders at that! On the other hand, senior developers — who have been in the industry longer — might be perplexed upon hearing this very: “Who is a software architect?” question from the juniors. As I wrote in part 1, human nature has many nooks and crannies. There’s a mental groove that by default sends us onto the “assuming dumbness” trail, especially if we don’t take time to stop and think what the reasons for people’s questions or behavior are, other than labelling them as “dumb” right out of the gate. I might be too optimistic (or not informed enough), but I’m certain that a textbook definition of the software architect’s role has been a part of professional education for any developer. And,even if that is not true — which, in my view, would be highly unlikely — there are plenty of ways to catch up on the basics e.g. to study “The Path to Becoming a Software Architect” series of articles referenced in part 1.

Now, let’s move on to how the phenomenon of throwing baby out with the bath water manifests in the context of software architect role (see part 1 and “Why Self-Organization Is a Luxury” for more info on the overarching trend behind this phenomenon). Those developers who’ve only seen software architecture decisions made by a group sense that something might be amiss with the collective way, while the seniors — who remember the times when it was custom to hold only one person accountable, “the dictator” — might experience something akin to a bitterness as they see how oh not possible it is anymore to put through a decision by just saying: “We will do the architecture this way, because… that’s what I say, and I know better than all of you”. Yet, both the sides want to come out with a sustainable architecture for the software they’re making, and they have a common goal despite their varying professional/experiential backgrounds. And, there’s only one way to work out the ways of achieving a common goal for groups that might be otherwise different: by empathy, compromise and balancing people’s needs.

The story continues in part 3.