5 myths about solution architects dispelled

When children dream of growing up to be, say, doctors or detectives, they don’t know what the work entails. This happens to adults as well. How can we find out what the reality is? One way is to talk with someone who has that job and look through solution architect job descriptions. We asked Andriy Trubitsyn, Solution Architect from Java CC, to dispel the most common myths about solution architecture. Here’s what we learned.

The reality – especially in new projects or streams – is often quite different. For example, at the beginning of the project, which I’m on now, I had to go to the client’s office in the United States to participate in the discovery phase and planning sessions. Then I came to Kharkiv, where we had two new teams that had never worked together before. In this case, I had to combine the roles of an architect and business analyst: I needed to not only suggest technological solutions, teach the team to work with microservices or review code – I also discussed use cases and functionality details with them. Together with our project manager and scrum master, we set up work processes using the SAFе framework.

Since I had experience and knew the client firsthand, it was easier for me to foresee how things would develop, tell the team how best to communicate with the client, how to react in difficult situations, or what level of detail in the descriptions would be sufficient (software engineers are often guilty of overusing technological nuances. Phrases like “the Jason format coming from the external server begins with the wrong symbol, and that’s why we’re seeing crashes…” are superfluous for people working in other areas).

I also had to support the team. Due to the client’s microservice architecture – there are frequent releases and dynamic work rhythm. We are always work-fit, and a lot of the team like that intensity. Here, it’s important to thank developers for their initiatives, support them in their work, and give them confidence in their undertakings. If you have a strong team spirit and focus on results, you’ll see who brings results in just a few iterations. Some of them could become architects in a year or two.

What is more, there are projects with such complicated management teams that the SA might de facto answer for the entire delivery process.

That’s quite impossible, isn’t it? The truth is that an architect should know technologies and their specifics better than any other technical person on a project. And a solution architect should look ahead. It’s rightfully said that software developers are like high-speed trains, while software solution architects are the ones laying the tracks.

An architect must always learn and keep up with the latest trends. I spend no fewer than ten hours a week studying technologies unrelated to my current project.  EPAM architecture communities and rich educational resources really help in this case. There are constant discussions of real project cases,knowledge-sharing sessions, trainings, etc.

As a rule, when you first come to a client, the level of trust they have in you is slightly above zero. A solution architect’s main task – and the team’s – is to win the client’s trust. At first, it may seem that the client is closely watching your every move, but with time you’ll be the one who gives advice about the next steps.

In a few months, we’ll be using another platform for microservices, so I need to dive in and study all the related technologies in order to support the teams and transfer knowledge during the switch. This is much more effective than having everyone learn it all from the beginning.

Still, the architect can make mistakes and must be able to admit them, fix them, and move on. Avoiding mistakes is easier with direct communication with project leads. You should conduct team brainstorming sessions and look at solutions from all sides to find potential problems in implementing technologies on a project. Without a team, the architect can’t lead a project to success. 

The image of the “architect in an ivory tower” – a SA who is unapproachable, doing their own thing while the team handles delivery – didn’t come out of nowhere. Such architects are useless for both the project and the team.

For a SA to be accepted as more than a person who gives instructions, you need to avoid looking like a know-it-all and win teams’ trust. Observe what your colleagues do and help them not just with advice, but with your actions: write code when necessary, share experience, and work out details to fully understand the development context. Gradually, as the teams see that your actions are beneficial, they’ll start to trust you. Then, your interaction will be maximally smooth, and you’ll move to a higher level of abstraction, delegating architecture tasks to tech leads.

Really, an architect shouldn’t make all decisions on their own. On a large project, architects are not fully immersed in all aspects of technological solutions. Only after a detailed discussion with key project leads you can make decisions with confidence.

There’s a belief that architects always work on something new, get engaged in never-ending research and development, apply cutting-edge technologies. But that’s not always the case. The architect’s main work is documenting the design and architecture of solutions used on the project. Some might find this boring. So, architects are usually the people who have fun doing this.

Personally, I find it very rewarding to draw diagrams and untangle them into beautiful, simple things with clear connections. My biggest win is when a lead sees my diagram and says everything is clear.

From time to time architects take part in ‘boring’ discussions where you have to persuade a client to choose your solution. This can turn into long email threads. But I have fun with that as well :) When I see that I was able to show the client that our decision was the right one and that it brings profit, I am satisfied.

In any case, solution architecture is an interesting work. A calling, even. It lets you dive deeper into technologies without becoming isolated from the team, travel for business, and meet face to face with clients, develop a community of talented engineers and develop your own skills.

Ask an architect you know if they ever regret their career choice. I bet they’ll say no ;)