Architect – what architect?
In many projects and organizations I am constantly meeting software architects. Given the quantity I’d only expect only a fraction of software development projects to encounter any issues in software architecture and design. As we all certainly know, quite the opposite is true.
Ok, nice and true words, but what exactly is the reason for this observation?
Of course, I absolutely have no clue :-; So let me just make some assumptions.
Could it be that the term “software architect” on a business card is subject to a variety of different interpretations?
In one company, someone may be promoted to software architect, just because she/he is the only one who owns a pattern book. [Beware of humour!]
Consulting companies may entitle some of their engineers as software architects, because they can charge more for architects than for developers.
A handful of companies may offer a challenging education program to become a software architect.
With other words, it is not clearly defined what a software architect is or should be. Nothing prevents you from calling yourself a software architect. You may remember that I am proposing a rather tough profile for software architects. Well, I know too many projects that failed miserably because of lack of competencies, experience or skills by the responsible software architects.
Note: not only the skills count! As software engineering is heavily related to communication and learning from failure, becoming a software architect requires starting as a developer, taking over more and more responsibilities over the years, before finally turning into a butterfly.
Another issue I often encounter is the missing separation between software and system architects. Today, many system architects are also considered as software architects. This might work very well if the system architect is an experienced software architect. Likewise, the aforementioned setting is adequate for software-intensive developments. But here again, the system architect needs also to be an experienced software architect. If the latter doesn’t hold, the software relevance is obviously underestimated and will inevitably lead to trouble.
Hold on, there is even another possibility. Even if you can justify that you are a software architect now, this doesn’t mean you’ll be a software architect forever. One of the most fundamental challenges is to know the state of the art of relevant software technologies and methods as well as appreciating and practicing coding and testing skills. Guess, you have been appointed as a software architect ten years ago, but in the meantime you were constrained to using UML tools, Powerpoint and other Office applications. With other words: would you trust a surgeon to operate on your heart who lacks ten years of practice?
I bet, you made some similar experiences in your environment. If that is the case, a comment would be highly appreciated. If not, even more!