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!
6 comments:
A very true obeservation. A good post! Thanks!
Michael,
well, there is at least a (imho quite good) proposal to define the field of Software Architects by the "International Software Architecture Qualification Board", http://www.isaqb.org.
We (I'm member of isaqb...) developed this curriculum in a joint-venture of researchers and practitioners from various industries.
All right - currently it covers only the "foundation level".
Siemens seems to be one of few companies using the terms "system architect" and "software architect". And still Siemens seems to produce bad SW...
Anyway, good post!
To the anonymous blogger: Either you know more details about Siemens software development. Then you should know what you're claiming is plain wrong. Or you don't know any details of our software development projects which makes your statement very questionable.
I'd like to see some examples of the bad software we produce, facts no rumors.
Michael,
I follow your posts from time to time; I enjoy them.
Every project needs a software leader, an architect would be great. When there isn't an architect per se, then one is born. When that person realizes the need for architecting the software, that person will search for the knowledge required to learn to architect the product that has to be developed. I did that I ended up taking one of your classes at OOPLSA.
What I am saying is that individuals identify the need for architecture and then they search for knowledge.
Thank you for your post.
Michael,
a very thoughtful article, thank you very much. For me, an architect should combine the communication skills of a manager with the design skills of an engineer. This might, indeed Luis, have to do with knowledge aggregation. Alike building architects (see http://www.sei.cmu.edu/library/abstracts/news-at-sei/architectsep98.cfm) it might be the insight in a never-ending journey to become a systems architect. Wax-on, Wax-off.
Post a Comment