I have seen the title of "Software Architect" thrown around quite a bit within the industry. The architects' which I have encountered often fulfill one or more responsibilities below:

* Lead software developer
(a senior software developer with the, ALL IMPORTANT, veto rights during technical disputes)
* Scrum master
(read: operational CHECKER UPPER; or maybe project manager's helping hand)
* Business / systems analyst
(sets the requirements, defines the way things should be done)

I believe that none of the above responsibilities really define what an software architect should be.

I was interested to see what topics was suggested at the first (architecture forum) meeting in 2010. (http://www.jcse.org.za/events.php?itemid=85)

It concerns me that a topic such as "The personality type on an Architect" made it onto the list. I will explain in a separate post.

What are your ideas?

Let me give some background with regards to the question of personality type of an software architect.

My experience is that the software development fraternity consists of employees for which the following rule is often true: "The technical skills of a software developer is indirectly proportional to his emotional intelligence".

This rule is true more often than what we would like to admit within any professional environment; with dire consequences. Unhealthy competition between colleagues and jousting for position often ensues.

This creates a situation where the most of software developers aspire to become software architects (because the software architect is the leader of the pack, right). And this is what happens all the time.

The resulting situation is that the biggest personality within the software development team becomes the architect. Don't get me wrong he may have been on the formal course; but his personality still secures him the position as leader of the pack.

My problem with this is that: I don't believe that the software architect should be the:
* most senior software developer, or the
* natural leader of in the software development team
I believe that the training of a software architect should be completely different to that of a software developer.

I believe there is a better way: the roles of software developer and software architect can better compliment each other. Provided, the title of "SOFTWARE ARCHITECT" is not used to crown the "GOLD STAR" developer with a nice title.

My question is what is a software architect? Any ideas?

In fact, it is these types of questions which I will like to be answered on a forum of software architecture:

1) What is the training requirements of an architect?
2) What is the responsibilities of a software architect?
3) What is personality traits of a good architect?

Now it seems like I am contradicting myself because of no (3); this is important. It is AS important as is the personality of any of your employees.

Disclaimer:
Please if there are any software architects out there that want to enlighten me, please do. I am not a software architect and I do not mean to offend any architects.

What I am saying is that we can benefit a great deal from clearly defining the role of the software architect. I am also sure our software development process quality can be improved by training, uplifting and supporting the (brave souls) architects; whom are dealing with difficult projects everyday.

hi javadeveloper, thanks for posting your views.

In my opinion, and architect should be someone who overseas and contributes to higher-level system design, generally at an enterprise (as opposed to) application level.

Architects should also be on-hand to answer day-to-day design questions and problems, as well as conduct code reviews from time to time. I guess architects should also be involved in setting guidelines for developers in an organisation. Architects should also be involved in mentoring junior developers.

I don't think an architect can be trained. Rather, I believe good architects are forged through experience. (Training should be the same training that 'produce' good developers'.)

I also believe that an 'architect' role should be a technical role, and that architects shouldn't be line managers for other employees. This is by default - if someone in the role of architect has the ability to act in a line manager role, there's no reason why it can't happen.

With regards to your questions on personality: The first comment I have to make is that if we accept that an architect should be at least the most experienced and technically 'advanced' in a team, that goes some way to solving the issue of 'the architect being the biggest personality'. (Experience can be measured).

A lot of the agile thinking and practices are intended to foster increased and improved collective ownership. Having a 'god' architect dictating terms to developers is not conducive to collective ownership, and will lead to developers feeling disenfranchised (in my opinion).

Planning poker, where every developer who will work on a feature is asked to estimate the size of the feature or task, (in secret ballot fashion) is a nice example of a practice conducive to collective ownership. This kind of technique also takes personalities out of the equation, since no single person's say should be considered over any other person's say, no matter how junior or senior they may be.

I also believe it is up to management to create an environment that is mature, aware and introspective enough to allow any person on the team to voice concerns about any issue at any time. Perhaps the issue of 'architect being the biggest personality' is a symptom of other, more fundamental issues in the environment.