“Do you want to be a system architect? There is only light and purity ... "

Many years ago, due to fatigue, I leaned against the wall of a technical corridor and began to crawl along it slowly. We have just handed over the project after a couple of weeks of nightly reworking to meet the deadline. My head was walking past, I groaned:

- Roma, I got tired of being an engineer. Everything, I leave!
He smiled gently and said:
- Good. You will be a system architect. There is only light and purity. Get enough sleep and come, tell you what to do.
')
I was young and naive. Sleep well and come. Then I began to gradually become an architect (now I became), and I can safely say: there is as much light and purity here as an engineer in everyday life. But more responsibility. Therefore - no, you don’t have to be an architect, if you don’t understand what you’re going to do.

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

What does this look like?

In general, it seemed to me that it would be interesting to communicate with customers, to identify myself, what they really need, to find out what is in their heads, in the infrastructure, and then to do big projects - and so that everything is beautiful.

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

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

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

In general, an architect is someone who makes major decisions on a project. Probably, this is the most and “sits down” on the profession.

What does an architect do?

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

Someone draws a data center. Someone well versed in databases. Someone on the net. And in all this you need a person who understands the high-level customer requirements for the project as a whole. The customer has no desire to build a data center or implement some kind of system. His task is “I want to move all my workload from one place to another” or “to organize a fail-safe platform that would allow all my systems to survive the dysaster.” We need someone who will understand all these requirements. And they are not even requirements, they are just Wishlist. “We want to increase sales by 2 times and reduce the number of incidents by 3 times” - we need to come to talk with the right people, understand where they have so many incidents, what can be done about it.

That is, the Wishlist is first collected. Then TK is compiled and coordinated, then a decision is made on it, which includes both physics and the applied part - an architect is needed for all these tasks.

An architect doesn’t necessarily do the whole project for all subsystems - on large things the system of advice or areas of responsibility under the guidance of the chief specialist. For example, a network architect is involved when it is necessary to design and build HQS (SCS) for a project. An applied architect is involved when it is necessary to develop some information systems. And so on.

The easiest way to explain is the cloud. I do the initial design of everything that the company sells from the cloud. I plan and design (and then control) building my own infrastructure, then I hand it over to the operation 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 he already has half of what he wants, and we tell him, 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 cool: the processes are drawn from the business (“We fully execute ITIL in the processes, applications are negotiated cleanly only in systems, everything skips instantly ”), and the DBMS admins find out that security guards are still being asked to bring a paper copy signed by all company executives. They analyze this piece of paper for many months and only then give the go-ahead to deploy some kind of test environment.

The bottom line is that if you come to a project for a business with the wording that everything is working wrong for you, then pray that you will not be taken into this project.

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

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

And yes, I like to think about how all this can be changed.

You can evaluate the project only 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 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 everything about everyone. It happens, people just leave somewhere from the post because of accumulated fatigue and responsibility. It happens people suffer. For example, I know one very strong technical expert. He comes and covers everybody with a good mat.

Says: "How do you carry the earth, such idiots!" And proves by parsing the code. But he is loved for his professionalism. He never wanted to be an architect, says: "I don’t want to translate the shades of meanings and emanations that they feel there." And remains an engineer to this day. “There are 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 unit, and now he is engaged in remote administration from some tropical island, it seems. Happy.

So, if you think that the architect is a branch of the developer’s development, which is immediately after the team leader, I’m not sure. As you see, there are a lot of hemorrhoids here, but there are a lot of joys from the fact that you figured out and solved the difficult task. But only the projects are large, so the joy comes a couple of times a year.

"And if I do wrong?"

Telecom's IT director once asked, "If I do wrong, will you correct me?"

"Yes, - I say, - we will talk."

He: "How will you convince me?"

I say: “Nothing. You have a gun. I can only say that if you shoot yourself in the leg, it will probably hurt you. ”

But I will always warn you that the gun is pointing up.

Or here's an example. There are virtualized applications, the load jumps from time to time. A customer is from a retail store, and a squall begins before March 8. The backend has time, and the sites fall on 404. Everything is simple: you just need to spread the application to parallel processes, think over that there are no bottlenecks. And it was written in the 90s and since then it was overgrown with shells - you need to turn a lot of things. Then people in business changed, they say: "Let's buy extra servers and we will live on the concept, so that there is enough power under the peak". We bought a couple of racks, idle chasing them 320 of 365 days a year. Two years later, these guys left, came new. They look at the racks, they say: "What is warm air, let's sell." Sell. Spring comes unexpectedly, the peak. The first iteration begins again. As a result, they go to the cloud, and my colleagues begin to help them to correctly make the installation. Not everyone even understands what a balancer is, but then the operation will tell you better in details, they are boiling.

Often it is necessary to quickly launch a project at any cost for 2 months, but in fact, when you dismantle the zoo, you understand that you must build for 10 years. Sometimes it is possible to convey. Sometimes not - the customer thinks the 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, conditionally speaking, the pros and cons of each in the most clear numbers or definitions.

And we are sometimes teased by startups - we are increasingly launching prototypes, and then we begin to convert them into permanent pieces.

Who can "pull"?

I do not know how to 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. In "Technoserv" two and a half years. But “on the other side,” I still worked with Technoserv engineers, as with contractor people — they did one big project.

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

Many in the architecture go 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 quite a limited time, you can include the solutions of some vendor in your portfolio. For example, there is monitoring of the database, applications, network, user transactions, data centers - in principle, the approaches are the same. Solves experience (a lot of experience) and system thinking.

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

In the development of knowledge, technologies become obsolete quickly, and the culture and skills of algorithmization remain forever. And in architecture, almost none of the knowledge becomes obsolete - by studying something, you can be sure that much will come in handy in a year, in five, and in ten.

How to understand what 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 are still an architect on projects, this role simply enters into something called differently.

In general, come. We have here, they say, only light and purity.

This is the material of our architect Alexander Shubin.