5 Myths About Solution Architects Dispelled 

We asked Andriy Trubitsyn, Lead Solution Architect at EPAM, to dispel the most common myths about solution architects (SA). Here’s what we learned.

Myth #1: Solution architects handle only technology tasks

The reality – especially in new projects or streams – is often quite different. For example, at the beginning of the project, 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, Ukraine, 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, and gauge how to react in difficult situations.

I also had to support the team. Due to the client’s microservice architecture, there are frequent releases and a dynamic work rhythm. We are always work-fit, and most of the team likes 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.

Moreover, there are projects with such complicated management teams that the SA might de facto be responsible for the entire delivery process.

Myth #2: Architects should know everything about technologies

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’s architecture communities and rich educational resources really help in this case. There are constant discussions of real project cases, knowledge-sharing sessions, trainings, etc.

Myth #3: Solution architects are experts and have no right for mistakes

As a rule, when you first come to a client, their trust level 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.

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. 

Myth #4: The project team never listens to an architect

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

For an SA to be accepted as more than someone who gives instructions, you need to avoid looking like a know-it-all and win the team’s 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 trust you. Then, your interaction will be smooth, and you’ll move to a higher level of abstraction, delegating architecture tasks to tech leads.

An architect shouldn’t make all decisions on their own. Architects are not fully immersed in all aspects of technological solutions on a large-scale project. Only after a detailed discussion with key project leads can you make decisions with confidence.

Myth #5: A Solution architects’ routine work is boring

There’s a belief that architects always work on something new, engage in never-ending research and development and 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 in the project. Some might find this boring. So, architects are usually the people who have fun doing this.

In any case, solution architecture is 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. 

And if you are keen on landing your next job as a solution architect, check out our job openings.