What is a Software Architect?

This essay discusses the tasks of a Software Architect and what properties and skills an engineer has to have to fulfill the role.

The headline skills required are Design and Communication with some secondary Project Management skills.

Communication

A software architect has to be able to communicate with a wide range of people including customers, suppliers and partners as well as within the development team.

As in any situation, if you want to communicate effectively with somebody you need to understand their needs and their point of view. Therefore, the software architect needs to understand these different groups well in order to be successful.

This communication ability can be difficult for some software engineers to acquire, particularly if they have spent a lot of time in a back-office or working in specialized technology. The good news for such engineers is that this is the standard stuff of management training and these skills are well worth acquiring in their own right.

There are several reasons why a software architect needs to communicate with various groups:

• the architect needs to talk to the customers to find out their use cases and their requirements. This also requires that the architect be able to understand their business so more management skills come into play.

• The architect needs to present a proposed solution to customers. Even if there are sales or marketing professionals involved, the architect will be needed to answer technical questions and he or she may end up as the external face of the project or system.

• The architect needs to communicate within the team to ensure that everybody understands the overall design and what is needed.

Representing the chosen solution in this way requires that the architect develop good 'people skills'. An engineer who is not a 'people person' will struggle to be a good software architect.

Design

It is probably obvious that a software architect needs to be skilled at software design but it is still worth stating. It is also useful to consider the additional design skills that an architect needs that designers of smaller components may not have developed.

The principal difference is in the scope of the design. Almost by definition, a software architect needs to design complete systems that may consist of a number of parts that communicate or interface with each other.

The architectural design must take into account overall performance and robustness rather than focusing on one part in isolation. This kind of overall optimization is more difficult than purely local optimization and may require some parts to be less optimized for the sake of the larger picture.

The architectural design must be heavily concerned with the split into sub-systems or components and with the communication between them. Therefore, an architect must be good at defining or finding the interfaces or protocols between the parts of the system. In general, if there is a good (or good enough) standard or protocol then it should be used rather than a newly invented one. This means that a software architect needs to be familiar with all the different protocols that may be useful.

Although the software architect is concerned with the 'big picture' design, he or she has also to be aware of the lower level design issues. This is comparable with a civil engineering architect needing to be familiar with the properties of concrete, steel, brick and glass in order to know how best to use them. If a software architect is not capable of designing the building blocks of the overall design then their design is likely to be flawed in detail (or they will need a lot of support from local experts).

This is why I think that a software architect needs to find ways of keeping their technical skills up to date. Where possible, some prototyping or hobby programming contributes to this but extensive reading is also required.

Making sure that the architectural design is of a high quality in the first place is critical but the architect also needs to make sure that the quality of the actual deliveries is maintained. This is not really a design issue but it is a technical issue and the architect is likely to be the final arbiter on whether the quality is good enough.

Project Management

In many cases the software architect will not also be the Project Manager but the architect needs to have a good awareness of project management issues and must be committed to supporting the project manager. Of course, if the architect is also the project manager (maybe with a title such as Software Lead) then the need is even stronger.

The architect needs to consider development and maintenance costs for the different parts of the system. If there are design choices then the costs are a factor alongside technical suitability.

When the project plan is under development, the dependencies and ordering of tasks must be based on technical considerations. The choice of which components to implement first (or which parts should be designed and implemented in parallel) may be based on technical dependencies or on which parts can be tested in isolation or on which parts carry the highest risk. All of these are technical questions that the architect must answer.

Once development is underway, risks must be kept under review and the project manager needs the architect to decide what is happening to the technical risks.

Within the project team, the architect is best placed to make sure that everyone knows what is going on from a technical point of view and he or she is responsible for contributing to team morale (in a positive way!). An architect who is a good leader and is respected by the team can make a tremendous difference to the success of a project. One who fails in these regards is a serious danger.