From developers - to Solution Architects: the story of one transformation

A year ago, mobile developer Ivan Trifonov traded a 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 the 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 I was leaving, my colleagues looked at me with bewilderment.”

Today I am in a T-shirt, which 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 and budget limitations. These are mobile clients on Swift, and Kotlin, and a backend on Go.

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

The backend was not without interesting solutions: modern orchestration, a big-data-ready-journaling system with reports based on Grafana / Kibana. The Go language also had interesting solutions - for example, microservice architecture and orchestrating 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. We had to solve problems that are difficult from the point of view of algorithmic.

On the one hand, such work gave me an incentive to grow as an engineer, and on the other, 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 with bewilderment, because to get out of 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 within the framework of the development: at some point it just became scary that the platform could be irrelevant. In EPAM, I was offered a job as a Solution Architect. I was not sure if it would work out, but I decided: once I was given such an opportunity, I had to agree.

“An architect is such a manager ...”

EPAM is a place where you can get an understanding of product development processes "from and to", learn to see them through the prism of business. I looked closely at the company a couple of years ago after participating in the EPAM Insider conference. After some time, 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 Oryol from EPAM began with the phrase “The architect is such a manager ...”.

But he was right. It turned out that one of my main tasks on the current project is to ensure that 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, “pieces” performed by large teams distributed around the world would “magically” stick together into a working system. And at the same time that the developers did not even realize that the process of "gluing" in general takes place. It is the same as in time to substitute the steps under the feet of a person walking with his eyes closed. EPAM began work on the project as a mobile application developer, but gradually the company turns into an integrator that makes all parts of the project work together.

Project X: "Invisible, but necessary as air application"

I was amazed that EPAM was improving the process of working around itself, gradually expanding it to teams from other companies. All agree and begin to work on one process, and this magic happens with your participation. You closely communicate with customers and developers - and a picture emerges in your head, which acquires new details in the process of communication, and inconsistencies are identified and eliminated.

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

We create 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 needed to urgently contact someone via the Internet. Your smartphone has identified 200 Wi-Fi hotspots around, access to which requires a password. Most of these points belong to the same cellular company - why not make the Wi-Fi users experience the same as the cellular users? You walk around the city, and your phone automatically connects to different points without a password. Switching takes place inconspicuously: your video with cats is not interrupted.

The project is far from simple to implement: one of Wi-Fi operators stands behind our mobile application - a global pan-European customer with a complex infrastructure. I still have not managed 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 consciously say that Wi-Fi is “fucking magic”.

And at the same time, twisting, breaking the technical limitations, you can make the product on which we are currently working.

Similar projects not so long ago on the market: a project for a British company and some operators in the United States, a draft of Beltelecom (in the direction of combining all routers into one system). But information about them is vanishingly small, so we do not in any way copy, but create a product from scratch. Technology does not 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 enormous organizational complexity of the project: different parts of the backend (for example, data services on using the phone, accumulated by teams from different countries) must be “friends” with each other.

Between start-up and EPAM: responsibility first

Do you know how this work differs from the work 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 must be achieved.

In a startup, you live according to a simple ideology: "We solve problems as they arrive." And in the EPAM project, you have evil knowledge: if you make a mistake now, then in a month 30 developers will be idle, and this is expensive. This is not about making decisions, but about accepting responsibility, being willing to make a candy out of what is at hand.

It is simply impossible not to make mistakes, and yet force majeure never occurred - unless local errors occurred. I got myself a file called “My Packs”, where I’m recording observations. For example, during this time I came to the conclusion that it is impossible to create such a process by which everything will work flawlessly.

Usually there are two or three initiative employees in the team who close the holes and then teach others. Without them, no Scrum will help. In order to more effectively build communication with people, follow a simple rule - get files about them and write down the minimal facts: what is responsible, where is involved, what helped, what did not help, whether it responds without reminders.

The most difficult task that I have ever had to solve is to streamline the information that comes in the form of letters, meetings, acquaintances, documents. I dream of such wards of reason, like Sherlock's.

Life "on the calendar"

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

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

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

In addition to project activities, EPAM gave 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 Competence, get 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 work in this company, I understood: you can do here everything you can and want. The main thing is to allow time.