The role of the Software Architect by Fabrice Marguerie
The Software Architect function is not well defined, and we have to admit that it is difficult to give a precise definition of the term. This article tries to determine the identity of these strange characters by presenting the tasks they are assigned and the required qualities to fulfill them.
Some time ago, I was asked to give my definition of the role of a software architect in a small team, and state what the required qualities to satisfy this function are, in my opinion. This article presents the answer I gave at that time. I hope it will help you to better understand the role and duties of an architect.
Architect or ArchitectS ?
The term “Software Architect” is somewhat vague. The definitions we can give depend on the context. This article concentrates on architects working with a small to medium team, on multiple projects, but not so many. In these conditions, the software architect also acts as a technical expert on one or multiple platforms.
During the DotNetGuru Symposium 2003, Sami Jaber presented two kinds of architects:
- functional architects, who optimize business processes, and have a very good knowledge about analysis methods;
- technical architects, who design long-term, reliable and adaptive technical architectures, and constitute a technical gateway between the project manager and the developers.
We can come across other kinds of architects. You can refer to the resources presented at the bottom of this page to learn more. We will focus here on technical architects, and not on functional architects.
Here is the role of a technical architect, according to Sami:
- Anticipate on technological evolutions
- Build durable architectures
- Independence with regard to API/framework providers
- Promote genericity and abstraction
- Bridge between developers, project managers, and business experts
- Technological evangelization, sharp sense of communication
- Ensure the technical directions and choices
- Often mixed culture (.NET/J2EE/opensource)
- First a role instead of a job
Tasks and required skills
I won’t give here a definition of the word architect in the sense I use it. I will instead introduce some aspects of the role of a technical software architect, as well as the required qualities to perform such a function. As previously stated, I here address mostly the context of small and medium-sized businesses or small development departments. In these cases, the role is often close to the role of a technical expert.
We could summarize the functions of an architect within a few words. Those could include: proposal work, advisory work, design, realization, validation, presentations, reports, management, transmitting as clearly as possible the results of a continuous technological survey, guarantee the technical quality of developments…
But there is much more than that. The work carried out by an architect is satisfying only if he has understood that his mission goes beyond simple expertise and knowledge application.
An architect is often an ex-developer who has accumulated such experience as to reach a good level in expertise. This experience must cover ideally a variety of platforms and products, and knowledge about the lifecycle of an application, or even of an information system.
The role of an architect is unique compared to the job of developers or project managers, because it requires long-term involvement, transverse to projects and teams. This gets even truer for long-lasting collaborations, compared to classic consulting missions.
It is a key role in a team. The architect must work hand in hand with the whole of the team to federate the energies of all the team members.
It is obvious that the benefits of having an architect highly rely on his involvement and integration with the project teams. It is thanks to permanent interchanges with the developers and the project managers that the architect will be able to communicate his knowledge, but also make the best out of the work of the team and the individuals. The architect must also be listening to the needs. Due to all this, there are big relational requirements in this function. Communication skills are required.
Diplomacy and pedagogy skills are also required to be able to explain architectures, debate about them and have them adopted.
An architect must be able to step back and take a higher-level look, which is often difficult for developers and projects managers because they are often too focused on a specific project and so on immediate needs. This means raising from the application level to the information system level. This also means that the architect has to perform a continuous technological survey; one that goes further than the context a specific project.
The architect has to submit proposals on the directions for developments, with a long-term vision of the information system’s architecture and of application integration problems, while keeping in mind the priorities. It is thus better to favor a pragmatic approach, by opposition to an idealistic one. Theory must remain guidance for the long term and not an obstacle for developments, which are often constrained in terms of delays.
However, even if I maintain that an architect has to step back from his work and the teams’ work, I hardly conceive an architect who would remain far from the implementation shop (the code, the project). Indeed, an architect can have to write lines of code (at least to create prototypes or mock-ups), but also has to get his hands dirty with code to validate the quality of what is produced or resolve a particularly technically difficult situation. Often are the pretty UML diagrams or the architecture papers to be left aside to look under the hood how things work (or don’t) in an application. This mainly means that an architect must be able to quickly read and analyze code.
An architect doesn’t take part to a project only at its beginning, but during the whole project’s lifecycle to ensure a right implementation of the design and architecture. He also has to keep listening to new requirements to adapt solutions if needed. Therefore, the involvement of an architect can span the lifetime of an application to give new directions, and ensure that the evolutions don’t weaken the whole construction.
Often, architects will initiate in-house frameworks, which represent a big part of the capitalization work of a company. In this case, the architect becomes responsible for the framework’s directions and works on the evolution to come.
A framework also facilitates the adoption of a technological platform such as .NET or J2EE. This is another task where an architect can help if he is expert in a given environment.
Let’s repeat that architect is more a role than a job. Having experience is not all, it also requires qualities and before all a state of mind.
Architect or developer?
To finish on a lighter note, a question that gets often asked is: “how to differenciate a software architect from a developer?” Michael Platt wrote: “Architects are a lot slower in getting a solution, especially if the problem is simple!”. Probably we could add that “Architects are much likely to come up with complex and costly solutions, especially if the problem is simple!”.
When I first published this article, a couple of persons came up with interesting links:
- Who needs an architect? – Martin Fowler
- Do you wanna be an Architect when you grow up? – Martin Fowler