“Want to be a systems architect?” There is only light and purity ... "

Many years ago, from exhaustion, I leaned on the wall of the technical corridor and began to slowly crawl along it. We just handed over the project after a couple of weeks of overtime to meet the deadline. My leader walked past, I groaned:

- Roma, I got sick of being an engineer. I’m leaving!
He smiled affectionately and said:
“Good.” You will be a system architect. There is only light and purity. Get enough sleep and come, I’ll tell you what you’ll do.

I was young and naive. He slept and came. Then he began to gradually become an architect (now he has become), and I can safely say: there is as much light and purity as there is in the everyday life of an engineer. But there is more responsibility. Therefore, no, you don’t have to be an architect if you don’t understand what you’re going for.

But! If you understand, this will be a very exciting adventure.

What does it look like?

In general, it seemed to me that it would be interesting to communicate with customers, to reveal for themselves what they really needed, to find out what was in their heads, in the infrastructure, and then to make large projects - and that everything would be beautiful.

The gap with reality is that what they have in their heads does not always correlate with what they have in their infrastructure.

And first you work as a psychologist, then you bring the truth, then you are offended (sometimes), then you again work as a psychologist, then you ask a hundred questions, then you check the facts (and not all of them are as presented) - and only after that an opinion is formed, how to design a system. Then you explain this to all the people who are interested in it: why so, why, how much it will cost, how right it is for such and such a situation, and for such and such why it may turn out that “it works faster” and “it takes 10 years forward ”may be on the same technology, but may not be. And how to choose. And then, when your liver grows big, big, it remains only to draw an owl - in fact, design the system in detail.

The greatest pleasure in the profession is to finish the design first and understand that everything is exactly as it is needed for the task. And then, after a couple of years, see how this is embodied by a team (or by many teams, up to hundreds of people), and be glad that you saw it and showed how to do it.

In general, the architect is the one who makes the main decisions on the project. Probably, this is most of all and "imparts" to the profession.

What does an architect do in general?

Now I am engaged in client projects and our Cloud Technoserv Cloud . Entertainment looks like this: some major project arrives. For example, design a data center.

Someone is drawing a data center. Someone is well versed in databases. Someone is online. And in all of this we need a person who understands the customer’s higher-level requirements for the project as a whole. The customer has no desire to build a data center or introduce some kind of system. His task is “I want to move my entire load from one place to another” or “organize a fault-tolerant platform that would allow all my systems to survive the disaster”. We need someone who understands all these requirements. And they are not even requirements yet, they are just Wishlist. “We want to increase sales by 2 times and at the same time reduce the number of incidents by 3 times” - we must come to talk to the right people, to understand where they got so many incidents from, what can be done about it.

That is, Wishlist first gather. Then the technical specifications are compiled and agreed upon, then a decision is made that includes both physics and the applied part — an architect is needed for all these tasks.

Not necessarily the architect does the entire project for all subsystems - on large things, a system of advice or areas of responsibility under the guidance of a chief specialist. For example, a network architect is involved when it is necessary to design and build a VKS (SCS) for a project. The applied architect is involved when it is necessary to develop some kind of information systems. Etc.

The easiest way to explain is the cloud. I do the initial design of all that the company sells from the cloud. I plan and design (and then control) the construction of my own infrastructure, then I hand it over to the operating team. Three people work with me on subtasks: they are responsible for OpenStack, for VMware, for the storage network.

Where then is hemorrhoids?

Somewhere in 85% of cases, the business believes that half of what he wants, and we tell him, he already has - and there are no problems. But the thing is that when you go down to the level of a department, department, etc., it turns out that everything is not so fun: the processes are drawn up by the business (“We fully execute ITIL in the processes, requests go through coordination only in systems, everything skips instantly ”), and the DBMS admins find out that the security guards still ask for a paper copy signed by all the company’s managers. They analyze this piece of paper for many months and only then give the green light for the deployment of some kind of test environment.

The catch is that if you come to a business on a project with the wording that everything is not working for you, then pray that you are not accepted into this project.

Because those whom you “burned” with this will not let you work.

Especially, you know, occasionally there are such ancient osobists who always have to have a piece of paper to hide behind.

And yes, I like to figure out how all this can be changed.

You can evaluate the project only together with the business, and then in a couple of years. But at the very presentation there is a subjective component: well, the plane must fly and be beautiful. And also such a result should become a template ideally, so that it can be implemented in all similar cases.

How to burn out

The market is small, everyone knows about everyone. It happens that people just leave somewhere because of the accumulated fatigue and responsibility. It happens that people suffer. For example, I know one very strong technical expert. He comes and covers all with good obscenities.

Says: "How the earth wears you, such idiots!" And proves by parsing the code. But he is loved for his professionalism. He never wanted to be an architect, says: "I do not want to translate the shades of meanings and emanations that they feel there." And remains an engineer to this day. “There is TK. I took, went and did. I don’t even want to know if he needed it or not. ”

Another colleague headed the technical service, then the architectural division, and now he is engaged in remote administration from a tropical island, it seems. Happy.

So, if you think that an architect is a development branch of a developer, which immediately after a team lead is not sure. There are a lot of hemorrhoids, as you can see, but there are a lot of joys that you figured out and solved a difficult problem. But only the projects are all big, so the joy comes a couple of times a year.

“What if I do wrong?”

The telecom IT director once asked: “If I do wrong, will you correct me?”

“Yes,” I say, “we will talk.”

He: “And how will you convince me?”

I say: “No way. The gun is with you. I can only say that if you shoot yourself in the foot, you will probably be hurt. ”

But I always warn that the gun is pointing in the foot.

Or here is an example. There are virtualized applications, the load jumps from case to case. The client is from retail, and he has a flurry before March 8th. The backend succeeds, and the sites fall at 404. Everything is simple: you just need to distribute the application into parallel processes, consider that there are no bottlenecks. And it was written in the 90s, and since then it has been overgrown with shells - a lot of things have to be transformed. Then people in the business changed, they say: "Let's buy extra servers and live on the concept, so that the capacities are enough for the peak." We bought a couple of racks, idle them 320 out of 365 days a year. Two years later, these uncles left, new ones arrived. They look at the racks, they say: "Why warm the air, let's sell it." Sell. Spring comes unexpectedly, peak. The first iteration begins again. In the end, they go to the cloud, and my colleagues begin to help them do the installation correctly. Not everyone even understands what a balancer is, but here it’s better to explain the operation in detail, they have boiled up.

Often it is necessary to quickly launch a project at any cost for 2 months, but in fact, when you disassemble the zoo, you understand that they must build for 10 years. Sometimes it is possible to convey. Sometimes not - the customer thinks with an annual plan, and this is his money and his business. He is right, he knows what to do strategically in business. My task is to show him the options and, relatively speaking, the pros and cons of each in the most understandable numbers or definitions.

And sometimes we are teased by start-ups - more and more often we launch prototypes, and then we begin to remake them into permanent pieces.

Who can pull?

I don’t know how they become architects. I can say that I worked as an engineer for 4 years, then in another company (already with experience) - as a designer, and then as an architect. At Technoserv two and a half years. But "on the other side," I still worked with the engineers of Technoserv, as with the people of the contractor - they did one big project.

Most architects, of course, grow out of advanced developers and engineers. But there are few exceptions, it all depends on the skills of system thinking, which in general are not necessarily acquired in IT specialties.

Many people go to architecture for new technologies. General approaches to the design and construction of systems remain unchanged. What to implement and what to plan is a matter of preparation. For a fairly limited time, you can include the solutions of a vendor in your portfolio. For example, there is monitoring of databases, applications, networks, user transactions, data centers - in principle, the approaches are the same. Decides experience (a lot of experience) and systemic thinking.

If I had to interview a new architect as a team, I would prefer to lose the situation with the customer and the executor: I set the task, or rather, voice the Wishlist, as customers often do, and then I look at what questions the applicant asks me, how the task finds out, which models offers.

In the development of technology knowledge becomes obsolete quickly, and the culture and skills of algorithms remain forever. And in architecture, almost nothing of knowledge becomes obsolete - by studying something, you can be sure that a lot will come in handy in a year, and in five, and in ten.

How to understand what it is worth going to architects?

I do not know. Probably, when you want the thrill of communicating with people and solving complex problems with many factors. Or when you still act as an architect on projects, it’s just that this role enters into something called differently.

In general, come. Here, they say, only light and purity are here.

This is the material of our architect Alexander Shubin.