From developers to Solution Architects: a story of one transformation

A year ago, mobile developer Ivan Trifonov traded the sensational startup for the position of Solution Architect in one of the innovative projects in EPAM. Here is his story about how he learned to swim in a sea of ​​project activities, how his attitude to the work process has changed, and why the position of the architect teaches us to get rid of self-esteem.

“When I said that I was leaving, my colleagues looked at me in bewilderment”

Today I am in a T-shirt, which has remained from the previous place of work. This is a startup where the most “stubborn” developers from all of Minsk and not only were assembled. We made magical technological solutions with almost no time limit and budget. These are mobile clients on Swift, and Kotlin, and a backend on Go.

At our own risk, we used not yet time-tested, but promising approaches in reactive and functional programming. Fortunately, everything worked out: by the time of release, these technologies had matured to the level of production-ready - by the way, not without our participation.

The backend could not do without interesting solutions: modern orchestration, a big-data-ready-system of journaling with reporting based on Grafana / Kibana. The Go language also appealed to interesting solutions - for example, microservice architecture and orchestration of a large number of interchangeable nodes. Most of all I remember their fail-tolerance approach: if you encounter an error, it is easier to kill the node and restart the system. It takes half a second and saves a lot of time. I had to solve problems that are complex in terms of algorithms.

On the one hand, such work gave me an incentive to grow as an engineer, and on the other hand, I wanted to share interesting practices outside our team, to influence people to do something better.

When I said that I was leaving the company, my colleagues looked at me in bewilderment, because in order to leave an advanced startup, you need a clear goal. I had it - development as a technical leader. To be honest, I didn’t want to stay in the development framework: at some point it just became scary that the platform might not be relevant. At EPAM, I was offered a job as a Solution Architect. I was not sure if it would work out, but I decided: since they give such an opportunity, I have to agree.

“An architect is such a manager ...”

EPAM is a place where you can get an understanding of the product development processes “from and to”, learn to see them through the prism of business. I looked at the company a couple of years ago after participating in the EPAM Insider conference. After some time, he became their employee.
Figuratively speaking, at first I imagined the work of Solution Architect as drawing squares and arrows. However, my attitude began to change already at the interview stage, which the architect Oleg Orel from EPAM began with the phrase "An architect is such a manager ...".

But he was right. It turned out that one of my main tasks on the current project was to make so many participants in the development process talk about the same thing and do not write hundreds of angry letters to each other.

So that after several months of work the “pieces”, executed by large teams distributed around the world, “magically” stick together in a working system. And at the same time, so that the developers do not even realize that the process of “bonding” generally takes place. It's like putting the steps under the feet of a person walking with their eyes closed in time. EPAM began work on the project as a mobile application developer, but gradually the company turns into an integrator who forces all parts of the project to work together.

Project X: “An inconspicuous but necessary application like air”

I was fascinated by the fact that EPAM is establishing a process of working around itself, gradually expanding it to teams from other companies. Everyone agrees and begins to work on one process, and this magic happens with your participation. You communicate closely with customers and developers - and a picture develops in your head, which acquires new details in the communication process, inconsistencies are revealed and eliminated.

How does the project look from the point of view of developers?

We are creating a mobile application that in the future will become invisible, but necessary, like air. Imagine that you came to Europe without a SIM card and you urgently needed to contact someone via the Internet. Your smartphone has identified 200 Wi-Fi points around that require a password to access. Most of these points belong to one cellular company - why not make the experience of Wi-Fi users the same as the users of cellular communications? You walk around the city, and your phone automatically connects to different points without a password. Switching is invisible to the eye: your video with cats is not interrupted.

The project is far from simple to implement: behind our mobile application is one of the Wi-Fi operators - a global pan-European customer with a complex infrastructure. I still have not been able to fully understand how a Wi-Fi router works, and more than one document is required to describe its capabilities. Therefore, as a Solution Architect, I can quite consciously say that Wi-Fi is “fucking magic”.

And at the same time, dodging, overcoming technical limitations, you can make the product that we are currently working on.

Similar projects have recently been on the market: a project for a British company and some operators in the USA, Beltelecom hints (in the direction of combining all routers into one system). But information about them is vanishingly small, so we are by no means copying, but creating a product from scratch. Technology doesn't matter here.

Of course, it’s great that our application is built on modern architectures, uses reactive programming and even has tests. But the main thing is the huge organizational complexity of the project: different parts of the backend (for example, data services about the use of the telephone, developed by teams from different countries) must be “made friends” with each other.

Between Startup and EPAM: Responsibility First

Do you know how this work differs from working on a startup, does the startup team purposefully create one product? There are many teams that deal with different products and other activities, the time and attention of which still needs to be achieved.

In a startup, you live by a simple ideology: “We solve problems as they become available.” And in the EPAM project, you have evil knowledge: if you make a mistake now, then in a month 30 developers will be idle, which is expensive. It is not about making decisions, but about taking responsibility, willingness to mold candy from what is at hand.

It’s simply impossible not to be mistaken, and yet force majeure has never arisen - if only local mistakes. I got myself a file called "My Fakapy", where I record observations. For example, during this time I came to the conclusion that it is impossible to create such a process, according to which everything will work perfectly.

Typically, a team has two to three proactive employees who close holes and then teach others to do so. Without them, no Scrum will help. In order to build communication with people more efficiently, I follow a simple rule - enter files about them and write down the minimum facts there: for which I am responsible, where I participate, what I helped, what I didn’t help, if I answer without reminders.

The most difficult task that I have ever had to solve is to organize the information that comes in the form of letters, meetings, acquaintances, documents. I dream of such wards of mind as Sherlock’s.

Life "according to the calendar"

The work is so dynamic that in 8 months I have radically changed as a professional: starting from the first meetings with customers, when I asked my colleague to speak for me, and ending with the current autonomous state. I learned how to better plan time and switch tasks faster. This led to life "on a calendar", when even the time to "think about vacation" is scheduled. Planning helped me put in order not only my work, but the rest of my life.

In addition, working as a Solution Architect helped me to cope with personal psychological problems: not to think about how others evaluate you, take some punches for yourself and for others, so that the project moves forward. Nevertheless, it is difficult to work when the results of your actions can be very long in time.

My self-esteem fluctuates between “If I leave this project, in a week it will end” and “If I leave this project, in a month no one will notice.”

In addition to project activities, EPAM provided many opportunities to grow in any direction - from eye-contact training to a review of news from the world of architecture. There is an opportunity to share knowledge with the community within the framework of the Center for Mobile Competency, undergo training in the so-called Solution Architecture University - a program aimed at the growth of senior and Lead specialists. Such initiatives are always supported by management. During my time at this company, I realized that you can do everything you can and want here. The main thing is that time allows.