Hugo Troche's blog: The Essence of the Software Architect

I have been asked many times about the role of a Software Architect. I have been asked about the skills necessary to become a Software Architect. I think today in the industry there is a firm understanding of the technical skills necessary to be a Software Architect. I think that technical skills represent only 20% of what an effective Software Architect needs. The list usually includes:

- - Years of experience as a Software Engineer.

- - Deep technical knowledge of relevant technologies to the position. Software Architects are comfortable reading formal specifications for new technologies like JSRs.

- - - Mastery of Object Oriented design patterns and Enterprise design patterns.

- - - Master knowledge of software process.

- - - Solid knowledge of deployment and operations issues.

After being a Software Architect and seeing other Software Architects at work, bellow is my distillation of what I think constitutes the basic attitude of a Software Architect.

1) A Software Architect is a leader before an Engineer

It is much more important to have the buy in of all the engineers for a particular design, than having the perfect design. Driving the process for the buy in is the Software Architect responsibility. The Software Architect needs the technical skills to weight design decisions and explain both sides. Yet, if the Software Architect can’t transform his technical knowhow into agreement from his team members, he might as well not be able to write a hello world class. The world is full of great software architectures and frameworks that nobody uses.

2) A Software Architect does much more giving than enforcing

A very experienced Software Architect friend of mine once told me: “If I have to point a design flaw in an implemented system, I did not do my job well.” It is easy to look at an application after the fact and pointing problems and asking for changes. The effective Software Architect mentors the development teams way before a project starts about design patterns, consequences of picking certain technology components, tradeoffs, maintenance challenges, performance objectives, etc. He holds regular formal mentoring sessions in the shape of lunch and learn or similar activities. He continuously performs code reviews and mentors developers from what he sees there. He makes his first priority to always have time to answer developer’s questions, everything else is less important.

3) A Software Architect thinks globally but acts locally

It is important for a Software Architect to think of the implications that design decisions will have in the entire portfolio of applications and infrastructure. Yet, an effective Software Architect never starts a project, sets up infrastructure or writes code that does not implement a specification or feature of an application. He designs his applications to create an architecture pattern and framework, not a framework to create applications.

4) A Software Architect thinks in simple terms

An effective software Architect that I met in a consulting engagement always analyzed everything through a simple prism. He thought the implications of technical decisions in regards to usability, reliability, scalability and maintainability. Whenever someone asked him to analyze a tradeoff, he always touched those four subjects. Everyone knew how he thought. A developer with a good idea would usually think about those four areas before coming to him. The parameters a Software Architect uses might be different from my friends, but as long as they are simple, consistent and well known they will have the same effect of getting the organization considering those parameters.