The Pragmatic Craftsman         :: Simplicity from complexity :: | About Me |

You are here: The Pragmatic Craftsman > Architecture & Design

Go to: « Improving Your Process | Martin on Bad Design »

Characteristics of a software architect

Are you thinking of becoming an architect someday? What are your plans for future? Maybe you are just a hard-core programmer and want to stay that way? There are people in each group. I would like to become an architect, a technical leader, and a manager. What? All three? Actually, I would like to become a manager, but I think a software manager should also be a technical leader and have at least some of the architect's skills. I'd say, by the end of 2008, I would like to be a manager. Those are my goals for next couple of years. I am still not 100% on it, but more and more, that's the direction I want to pursue.

Back to architecture. Being a software architect is not easy. It is only for the select few.

But I know, now, what software architect is, and what it entails. I found out from this excellent article, Characteristics of a software architect, by Peter Eeles, a Senior IT Architect at IBM. It's an excellent read. A must read if you would like to go in that direction.

Software Architect is (I'm putting my comments for each major point; quotes are taken from the article)..

The architect is a technical leader
No question about it. You have to know your stuff. You have to be an expert in a lot of different areas.

First and foremost, the architect is a technical leader, which means that, as well as having technical skills, the architect exhibits leadership qualities.

The architect role may be fulfilled by a team
This is an interesting point. I think that's how I would like it to be: a team effort.

Given that the role of architect requires a very broad set of skills, it is often the case that the architect role is fulfilled by more than one person. This allows the skills to be spread across a number of individuals, each bringing his or her own experiences to the role. In particular, the skills required to understand both the business domain and also various aspects of technology are often best spread across a number of individuals.

The architect understands the software development process
This is a must. A software process needs to be continuously improved. You have to understand it first, to make improvements. Thus, you need to know others processes as well.

The architect has a knowledge of the business domain
Very important. One interesting point in the article, by knowing the domain you can foresee some of the problems or extension to the system.

The architect has technology knowledge
Of course.

The architect has design skills
A big part of architecting is designing flexible, easy to understand, maintainable systems.

The architect has programming skills
As an architect, you will oversee other programmers, you have to know.

The developers on the project represent one of the most important groups that the architect must interact with. After all, it is their work products that ultimately deliver the working executable software. The communication between the architect and the developers can only be effective if the architect is appreciative of the work of developers.

The architect is a good communicator
An architect has to be able to communicate with a lot of stakeholders; he has to share his vision clearly. Plus, he has to defend his decisions.

Being able to communicate effectively is a skill that is fundamental to the success of a project for many reasons. Clearly, communication with stakeholders is particularly important in order to understand their needs and also to communicate the architecture in a way that secures (and maintains) agreement with all stakeholders. Communication with the project team is particularly important, since the architect is not simply responsible for conveying information to the team, but also for motivating them. Specifically, the architect is responsible for communicating (and reinforcing the communication of) the vision for the system, so that the vision becomes shared and not something that is only understood and believed in by the architect.

The architect makes decisions
Very good point.

The architect is aware of organizational politics
You cannot avoid politics, as much as I don't like it, that's the truth.

The architect is a negotiator
You have to talk to programmers, testers, business people. You have to negotiate.

What do you think? A lot of skills and knowledge required.

Excellent article. This is the best summary I've read. Written in a clean manner. Nice, pragmatic approach.

Do you still want to be an architect?

Reference
Characteristics of a software architect, The Rational Edge Newsletter, March 2005, my recommended resource


Comments

Post a comment









Remember personal info?







Go to:
   « previous entry: Improving Your Process
   » next entry: Martin on Bad Design

Random Quote

Search

 

Topics

Architecture & Design :12
Better Coder :29
Books :43
Books Recommended :18
Buzzwords :5
Career :25
Craftsmanship :15
Java :15
Quotes :25
Recommended :9
Software Engineering :3
Uncategorized :33
Web Development :1

Archive

May 2008 (1)
April 2008 (2)
March 2008 (1)
February 2008 (1)
January 2008 (2)
November 2007 (1)
October 2007 (3)
August 2007 (3)

...since January 2002

Currently Reading


:: See list of books I finished reading

Info

© 2001-2008 Stanley Kubasek About me :: Contact me