5 myths about the work of a decision architect. Expert Opinion
When in childhood we want to become, say, a doctor or an investigator, we hardly know the specifics of the profession. Similar situations happen with adults: the idea of a dream job in reality has little to do with reality. But how to find out for sure where the pitfalls are hidden? One way is to talk to the practitioner honestly! We invited Andrei Trubitsyn , who works with EPAM as the Solution Architect of the Java Competency Center, to debunk common myths about the work of an architect.
The reality - especially on new projects or streams - is often different. At the start of the project that I am currently working on, I had to go to the States, to the client’s office, to take part in the discovery phase and planning session. After that, I came to Kharkov, where two teams were assembled, which had never before worked together. In this situation , the combination of the role of an architect and a business analyst was required: I not only suggested technological solutions, taught how to work with microservices and made code reviews, but also clarified and discussed various use cases and functional details with the team. Together with a colleague, Eugene Efremov, PM and Scrum-master on this project, we set up the process of working on the SAF-framework.
In addition, due to experience and direct acquaintance with the client, it was easier for me to predict the situation ahead, tell the team how best to communicate with the client, how to respond to difficult situations, what level of detail in the descriptions will be sufficient (engineers sometimes sin that abuse technological subtleties. In fact, the tirade that "... the JSON format that comes from a third-party service does not start with the character that is expected, and for this reason there is some kind of failure ...", for person to who works all his life in another field, will be redundant).
In addition, you need to support the team. Due to the microservice architecture, my project has very frequent releases and a dynamic rhythm of work. We are always in good shape and many guys are so intense in their liking. More importantto thank engineers for their initiative, support in work, inspire confidence in undertakings . If team spirit and focus on results are strong, then after a few iterations, people who show high results stand out. I think some of them will be able to become architects in a year or two.
Apart are projects in which the situation in the management team is so complicated that SA is responsible for the entire process of product distribution.
It is not true. The architect does not know everything. But he really needs to strive to learn more technologies and their features than any other technical person on the project. And yet - SA must look ahead, think about the prospects. No wonder they say that engineers are high-speed trains, and architects are those who pave the way so that they are not stuck in some kind of swamp.
In general, the architect must constantly engage in self-education. My norm is to spend at least 10 hours a week studying non-project related technologies . In this, in particular, professional communities of architects in the company help. There are constantly held discussions of various cases and knowledge sharing sessions.
As a rule, when you come to the role of an architect to a client, the level of trust in you is slightly higher than zero (and this is only because they expect to see a smiling man in a shirt :)). The main task of SA - and subsequently teams - is to prove to the client that he can trust us . And if at first it feels like the customer meticulously checks all the steps and all the actions that you take, then over time you will have the opportunity to advise the client what and how to do. It is the accumulated level of trust that allowed my project account to grow up to 200 people (70 of which work in Kharkov). And we continue to grow!
In a few months, our team plans to use Kubernetes and Istio as a platform for microservices, so now I need to delve deeper into the topic, study all the related technologies, so that during the immediate transition I will provide technical support for the teams and transfer knowledge quickly and efficiently to them . This is much more effective than diving into a topic together from scratch.
At the same time, the architect has the right to make a mistake and must be able to recognize it, correct it and move on. Direct communication with lead projects helps to avoid them. It is necessary to arrange team brainstorms and consider the solution from all sides to find potential difficulties with the introduction of certain technologies on the project.Without a team, an architect cannot lead a project to success.
The concept of “architect in an ivory tower” - that is, an SA that sits somewhere high, is engaged in something of its own, and the engineers at this time are in real distribution - did not arise from scratch. An architect of this type does not help the project; his team does not need his help.
So that SA is not perceived as another person who came to command, it is important not to be a know-it-all, but to observe what colleagues are doing on the project and help. To help not only with advice, but also with “hands”: write code, when necessary, share experience, find out details and details in order to be maximized in the context of direct development. Gradually, when the teams see that the architect’s actions are beneficial, they begin to truly trust him.Then the interaction becomes as smooth as possible and allows over time to move to a higher level of abstraction, to delegate architectural tasks to technical leads.
In general, an architect should not make absolutely all decisions alone . Indeed, on a large project, he is not immersed in absolutely all aspects of the application of a particular technology. Only after a detailed discussion with key people on the project can a decisive step be taken.
There is an opinion that architects are always doing something new, are involved in endless R&D activities, working with cutting edge-technologies. But no. The main part of the architect’s work is to document the design and architectural decisions that are used on the project. Some may find this boring. Therefore, architects are people who find in this something fascinating for themselves.
For example, it gives me a lot of pleasure to draw diagrams and turn them from intricate and complex to very beautiful, simple, with even and clear connections. The biggest reward is when the lead sees this diagram and says that everything is simple and very clearly demonstrated in it.
From time to time, the architect takes part in “boring” conversations, where it is necessary to convey some detail of the implementation to the client and show why it is necessary to do this and not otherwise. This may turn into long threads of correspondence, but I am interested in this activity. When I understand that I was able to prove the optimal choice of our solution and this led to a profit for the client, I enjoy it.
Be that as it may, the solution architect is an interesting job . Even a vocation. It allows you to immerse yourself in technology and not go into isolation at the same time; go on business trips and communicate with customers; to develop a community of talented engineers and pump their own competencies.
Ask a friend of the architect if he regrets his career choice. Bet he says no? ;)
Interview and text prepared by Ksenia Bai, communications expert at EPAM Ukraine.
Myth number 1. The solution architect does not deal with managerial tasks on his project. His business is technology!
The reality - especially on new projects or streams - is often different. At the start of the project that I am currently working on, I had to go to the States, to the client’s office, to take part in the discovery phase and planning session. After that, I came to Kharkov, where two teams were assembled, which had never before worked together. In this situation , the combination of the role of an architect and a business analyst was required: I not only suggested technological solutions, taught how to work with microservices and made code reviews, but also clarified and discussed various use cases and functional details with the team. Together with a colleague, Eugene Efremov, PM and Scrum-master on this project, we set up the process of working on the SAF-framework.
In addition, due to experience and direct acquaintance with the client, it was easier for me to predict the situation ahead, tell the team how best to communicate with the client, how to respond to difficult situations, what level of detail in the descriptions will be sufficient (engineers sometimes sin that abuse technological subtleties. In fact, the tirade that "... the JSON format that comes from a third-party service does not start with the character that is expected, and for this reason there is some kind of failure ...", for person to who works all his life in another field, will be redundant).
In addition, you need to support the team. Due to the microservice architecture, my project has very frequent releases and a dynamic rhythm of work. We are always in good shape and many guys are so intense in their liking. More importantto thank engineers for their initiative, support in work, inspire confidence in undertakings . If team spirit and focus on results are strong, then after a few iterations, people who show high results stand out. I think some of them will be able to become architects in a year or two.
Apart are projects in which the situation in the management team is so complicated that SA is responsible for the entire process of product distribution.
Myth number 2. An architect knows all about technology
It is not true. The architect does not know everything. But he really needs to strive to learn more technologies and their features than any other technical person on the project. And yet - SA must look ahead, think about the prospects. No wonder they say that engineers are high-speed trains, and architects are those who pave the way so that they are not stuck in some kind of swamp.
In general, the architect must constantly engage in self-education. My norm is to spend at least 10 hours a week studying non-project related technologies . In this, in particular, professional communities of architects in the company help. There are constantly held discussions of various cases and knowledge sharing sessions.
Myth number 3. SA post makes you an expert by default
As a rule, when you come to the role of an architect to a client, the level of trust in you is slightly higher than zero (and this is only because they expect to see a smiling man in a shirt :)). The main task of SA - and subsequently teams - is to prove to the client that he can trust us . And if at first it feels like the customer meticulously checks all the steps and all the actions that you take, then over time you will have the opportunity to advise the client what and how to do. It is the accumulated level of trust that allowed my project account to grow up to 200 people (70 of which work in Kharkov). And we continue to grow!
In a few months, our team plans to use Kubernetes and Istio as a platform for microservices, so now I need to delve deeper into the topic, study all the related technologies, so that during the immediate transition I will provide technical support for the teams and transfer knowledge quickly and efficiently to them . This is much more effective than diving into a topic together from scratch.
At the same time, the architect has the right to make a mistake and must be able to recognize it, correct it and move on. Direct communication with lead projects helps to avoid them. It is necessary to arrange team brainstorms and consider the solution from all sides to find potential difficulties with the introduction of certain technologies on the project.Without a team, an architect cannot lead a project to success.
Myth number 4. The project team always listens to the architect
The concept of “architect in an ivory tower” - that is, an SA that sits somewhere high, is engaged in something of its own, and the engineers at this time are in real distribution - did not arise from scratch. An architect of this type does not help the project; his team does not need his help.
So that SA is not perceived as another person who came to command, it is important not to be a know-it-all, but to observe what colleagues are doing on the project and help. To help not only with advice, but also with “hands”: write code, when necessary, share experience, find out details and details in order to be maximized in the context of direct development. Gradually, when the teams see that the architect’s actions are beneficial, they begin to truly trust him.Then the interaction becomes as smooth as possible and allows over time to move to a higher level of abstraction, to delegate architectural tasks to technical leads.
In general, an architect should not make absolutely all decisions alone . Indeed, on a large project, he is not immersed in absolutely all aspects of the application of a particular technology. Only after a detailed discussion with key people on the project can a decisive step be taken.
Myth number 5. An architect does not have boring, routine work
There is an opinion that architects are always doing something new, are involved in endless R&D activities, working with cutting edge-technologies. But no. The main part of the architect’s work is to document the design and architectural decisions that are used on the project. Some may find this boring. Therefore, architects are people who find in this something fascinating for themselves.
For example, it gives me a lot of pleasure to draw diagrams and turn them from intricate and complex to very beautiful, simple, with even and clear connections. The biggest reward is when the lead sees this diagram and says that everything is simple and very clearly demonstrated in it.
From time to time, the architect takes part in “boring” conversations, where it is necessary to convey some detail of the implementation to the client and show why it is necessary to do this and not otherwise. This may turn into long threads of correspondence, but I am interested in this activity. When I understand that I was able to prove the optimal choice of our solution and this led to a profit for the client, I enjoy it.
Be that as it may, the solution architect is an interesting job . Even a vocation. It allows you to immerse yourself in technology and not go into isolation at the same time; go on business trips and communicate with customers; to develop a community of talented engineers and pump their own competencies.
Ask a friend of the architect if he regrets his career choice. Bet he says no? ;)
Interview and text prepared by Ksenia Bai, communications expert at EPAM Ukraine.