If you ask 10 people what a software architect is, you’re likely to get between 5-10 different answers. Some people will say “they design software systems”, and some people will attempt to enumerate all of the particular tasks they may perform. After giving this quite a bit of thought lately, I think that neither of these types of answers truly captures the essence of what it means to be a software architect. Rather, I believe that the essence is defined by Robert Greenleaf’s concept of servant leadership.
While it first may seem a contradiction in terms, servant leadership is the type of leadership earned by someone once they have demonstrated their commitment to something larger than themselves. What motivates this person is not the success or recognition they may receive; it is the feeling that they will get from knowing they were part of something great. It is earned because leadership is something someone has for a time, but since it is not an essential part of them, it can also be lost. The desire to serve a cause which benefits more than yourself is either part of who you are, or it is not. It can’t be assigned to you, and if you have it, you generally can’t lose it.
This characteristic is an essential part of of the successful software architect because the architect must not be working for themselves. Instead, they must put the desires, needs and goals of their organization or their client ahead of their own personal agenda. They must commit themselves to delivering the best possible system to meet the stated (and often unstated) requirements driving the project. They must shoulder the risks and take ownership and responsibility of their own decisions. If the project is successful, they are successful; if the project fails, they fail–not because they were at fault, but because something to which they were deeply committed was not successful.
Naturally, an architect cannot be successful without having the constant drive to learn and expand their skills. They must know the details of design patterns, development environments, application servers, operating systems, networks and databases and how these all work together to provide a successful system. However, these things are all skills that are learned rather than an inherent part of the person practicing architecture. Knowing these things does not make one an architect any more than a title or a general election makes one a leader. What differentiates the actual architect from the named architect comes down to the character of the individual.
Why is this true?
Think about all of the different things an architect–perhaps yourself–does on a daily basis. Then step back from the detail of what these things are and look at the essence; find the commonalities. What’s left? Leadership. The architect is the person who must take the various requirements and forge them into a consistent and coherent vision for a complete system. In this respect, they are defining the way things will be. They are the ones that take ownership of the goals of the system, internalize it and know what the system is supposed to be; understand what it is and how to make it happen. These things are the root from which all of the daily tasks grow–sometimes like weeds.
The architect creates the vision, articulates it, and can continue to articulate it, consistently and accurately, when anyone is unsure or unconvinced. From their experience, they gain the insights to have the intuition to come up with potential solutions and the judgment to know which of these do or do not fit into the system. However, with all of this experience and confidence, they still must no lose sight of why they are doing it. If the system does not ultimately support the business requirements, it is not a successful system. The architect also knows that, at best, their intuition is only a guide, and that they will undoubtedly make mistakes. They must accept these things as a natural part of working towards the grand goal. It must not be about egos or who is right, but about what the total net benefits of the system will be to its owners.
Being able to successfully do these things is ultimately less about system architecture than it is about being a leader. If you cannot establish a vision and set the direction, you are not an architect. If you cannot listen to your team, your clients or your peers, you are not an architect. If you cannot rely on your intuition to make effective decisions in light of not having all the facts, you are not an architect. If you do not have the humility to accept you do not have all the answers, you are not an architect. If you do not have the foresight to be proactive instead of reactive, you are not an architect. Finally, if you cannot build a community around your vision, you are not an architect.
If you can combine these things with continual personal development and solid, demonstrable architectural skills, you will be able to gain the trust of your organization, your team, your clients and your peers. You will gain their support; you will benefit from their success, and you will be an architect.
- Greenleaf, R. K. (1977), Servant Leadership. New Jersey, Paulist Press.