Who is Software Architect

I've seen many software architects in my life, and this article is not to judge any of them. This is to clarify what I feel is a correct definition of a software architect.

At the same time, I want to make it clear where the demand stands, and what should be the proper supply level in order to satisfy the demand for the strong software architect.

Please have in mind that all the criteria mentioned here describe a software architect in the best way that can exist. Most of the times, software architects pass only part of the criteria, and that's absolutely fine - the world is not the home of perfection.

 

Definition

Here is a short definition of a software architect as I see it:

Software Architect is an opinionated technical guru, who is able to translate business expectations into the high quality Software Architecture.

I will not cover here what a Software Architecture is, or how I differentiate high quality software architecture from the low quality one. You can go ahead and read the topic I published recently that talks about it.

In this topic, I would like to touch those points that I feel are more of an importance in regards to the Software Architect's role.

 

Stereotypes

First, let's get rid of the stereotypes.

Definition of a good software architect cannot be found on job boards because the format of it simply does not fit into a proper definition, or the other way around. Software Architect shows his/her best knowledge during an interview (or furthermore, during an actual assignment). That also means that the resume of a software architect sometimes does not shine as it would be expected. One of the reasons is because nowadays, many newbie engineers have better resume-writing skills than a good software architect. I know, it does not make it any easier, so let's continue.

Age is not relevant, mindset is. I've heard stories that a typical software architect should weight at least 200 lbs, should have a beard or a bold head, and should have at least 15 years of experience. Well, the latter does not matter for sure (not that I meet the first part of the criteria). I've met talented technical people who could have been architects if not their age - and I would be ashamed to let those people wait because of their ages. I think that I would not want to miss on a bright mind that can outperform more experienced architects in the early age. It's rare, but you don't want to miss this try.

 

Architect's Strong Side

Now, let's outline some of the great things that a good software architect should possess.

Learning domain and building/maintaining a big picture is what software architect does constantly. Many software architects do it on the reasonable (and surprisingly somewhere on the same) level. Good software architect takes it further - he/she catches things faster, starts reacting to the contradicting statements during early debates, and proactively initiates next steps in order to dig further into the unknown areas of research.

Structural thinking - I cannot stretch how important it is. Software architects tend to see patterns and start following them on regular basis so that they can usually bring some light into long lasting debates. Good software architect takes it further - he/she starts finding patterns inside patterns. In other words, he/she won't use general approach into specific cases when not appropriate, and vice versa.

Communication skills - software architect should not go into the pocket to find a proper word. Many software architects talk a lot, and can convince many others who tend to be from the same league. A good software architect takes it further - he/she bases communication on standards (UML, Design Patterns, diagrams, terms, domain-specific facts) and leaves no space for debates over facts. And, fair to mention - let's not confuse between being native in architectural conversation and being native in English - diversity of cultures and nationalities is the primary weapon of the U.S.A. as we know it.

Care for the product should put software architect aside from the rest of the people involved in the development. Many software architects seem concerned about the final outcome, but they seem to be unstable with their thoughts; they demonstrate uncertainty in their decisions and thus in the ways the product should grow. How can it be a proper care if they are not even sure about the roadmap? I think you can guess what a good software architect would do on the other hand.

And the final thing that composes everything said above: strong opinion and confidence. While software architect must be open to different opinions and obviously, should change his/her mind when needed, it should happen rarely. Not because the opinion should not (or cannot) be changed, but because a good software architect rarely misses right opinion in the first place. Any software architect can come up with one way of doing things, and then sit on the meetings to pick the best way out of many other suggestions; only a good software architect comes up with the best way from the beginning, then listens to the others and makes it clear that his/her opinion is better by providing correct and fair arguments.

 

That's about it. And don't forget that choosing a right software architect might be as challenging as building a high quality software architecture.

Share If You Like It