Recently, we in Devoteam have found out that all mentors* have a different understanding of what an architect is (of course, I mean an architect in the context of IT in general and IT consulting in particular). It was a bit of a surprise, however, in retrospect, it makes a lot of sense. We are a diverse group, by age, focus (more development-oriented or more consulting oriented), education and experience. Nevertheless, we want to get aligned on what skills and personal traits an architect should have. We are after all supposed to help our mentees* choose and follow a career path. Because we hate long meetings we have decided to consider it homework for the next mentor’s* session.
My goal was not to do a lot of research and sum up all the available information I find but to talk from my perspective and my experience instead. I will also try to describe the role as generally as possible, without references to a particular technology or IT specialization.
What an architect has?
- The architect has a vision. The vision does not need to be complete, it does not need to contain all the details. The vision can and should change if needed.
- The architect has very good or even great communication skills. There is no point in having a vision if you cannot discuss it with others.
- The architect has a lot of experience. I believe that to be an architect, you should first participate in a number of different projects, preferably for different customers (yes, this applies only to consulting).
- The architect has a successor. Assuming there is enough seniority in the team and the project is ongoing, the architect should be training her / his successor.
What an architect is?
- A team player. Every architect should accept that they are not going to achieve too much by working alone. An architect without a team or not being able to work within a team is a senior developer at best, although senior developers are usually better developers than architects already.
- A leader. I don’t believe that in software development, traditional management methods are of much use. Nobody believes anymore we can measure productivity by how many lines of code are written or stories closed or commits pushed.
- A decision-maker. In an IT project, there are many decisions to take. From profound ones such as “What technology should be used?” to seemingly small ones such as “What database model should we use for this one feature?”. In the first place, an architect has to identify, what decisions are the important ones and make sure the decision is the right one.
What an architect is NOT
- The architect is not simply a very experienced developer. Of course, most architects are recruited from the ranks of senior developers, but what I mean is that you should not consider an architect to be a developer. As mentioned below, an architect should know how to code, but maybe not even in every programming language the system uses.
What an architect does regularly
- An architect learns constantly. As technology evolves every day, architects need to ingest a lot of information just to keep up to date. If you want to learn something new, you need to spend even more time.
- Meetings, calls, and emails. If you hate meetings, conference calls, emails, maybe this role is not for you. I am not saying it is impossible to do without meetings etc., however, I did not yet found a way. Unfortunately. Let me know if and how you managed to get rid of meetings, I will be forever grateful.
What an architect does NOT do regularly
- Coding. Even though, in my opinion, architects should be able to read code, because it provides common ground with the rest of the team and the code itself is the ultimate source of truth. This leads me to a question that I have not resolved yet and which might be a topic of a future article: How does an architect retain deep knowledge of a system if they did not develop it themselves, at least partially?
In conclusion, it is not easy to be an architect. The reason is that on one hand, you have to have good technical skills. On the other hand, you need to be a good communicator of your ideas and decisions to your colleagues and to be able to materialize your vision. Fortunately, I believe that in Devoteam we have people who can do both.
*For the purpose of this article think of mentors as managers and mentees as their subordinates. It is of course different, however, I am not the best person to explain this and this article is not the right place for it anyway.
