Who Is A Software Architect? — Part 1
When we are about to read an article, we first look at the headline, and by doing so we set certain expectations as to what the read would be about. The headline that I chose today might appear trite for many software developers. Isn’t that obvious what a software architect is responsible for? Yet, from what I’ve heard and read, this role is surprisingly misunderstood, or, rather, misinterpreted, by many. And, there’s more to it than just a misunderstanding of a role here. If we have trouble identifying the fundamentals of a system — and architecture, no doubt, is the base on which any robust app is built — we are at a higher risk of producing software which would be anything but dependable and sustainable. So, I took a deeper look into the roots of those misunderstandings… and found out that the devil is hiding not in the details (as in the technical details), but in the nooks and crannies of … the human nature.
From the technical standpoint, I’d suggest studying this excellent series of articles to those who aspire to become a software architect and/or to learn more about this role. My job is to uncover why this role — once so sought after — might have become misunderstood and even stigmatized to a certain extent.
Let’s start with the definition, and I’m quoting from the series referenced above:
“A software architect is a software expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms. The leading expert is referred to as the chief architect.”
Now, as you read this definition, is there anything that doesn’t resonate with you? Catches your eye? To me, it’s the word “dictates”. Besides, for various reasons, some of us might have become allergic to some roles or job titles that come with the prefix “chief”. And, once we see a word or catch a vibe that pulls at our emotional side, we might become deaf to the voice of reason, just like a proverbial bull that flies into rage upon seeing a red rag. The red rag here would be our intolerance of anyone who uses their position “to dictate” anything, even if what they dictate appears perfectly right from the technical standards or a high-level design point of view. Whoever wrote this:
“There is no such thing as a software architect and we don’t need people telling us what to do. Software architects should write code along with the rest of the development team.” — source
must have been exposed to a command of a software architect who dictated without explaining why things are supposed to be done or not done this or that way. And, from what people say, it appears that software architects have dictated a lot, and a lot.
In “Why Self-Organization Is A Luxury” I’ve traced some patterns that emerge as a pendulum bounceback reaction to the organizational practices that have lost their functional purpose, falling prey to intended or unintended misuses. When the pendulum swings, they tend to throw baby out with the bath water by discarding — or even stigmatizing — the original benefits of a misused practice or a behavior that boosted the bounceback.
If I were to put on a hat of a crime investigator 🤠, I’d say this: the evidence suggests that misunderstandings about software architects fall into another such pendulum bounceback pattern. Stay with me for further investigation in part 2 :)
