What you need to know to become a systems architect

Roles in the project look like this:

1. The analyst hears from the business a task in the spirit of “we need to work faster” and goes to find out what is needed for this. For a long time he picks himself and learns, for example, that production needs a simpler or more transparent process flow for processing orders. Discusses with the team. Business decides to do. The analyst throws demands on the new system at the architect. The analyst will know where to go.
2. The architect looks at the requirements, looks at the system, is surprised, looks back and forth again - and after that sets the exact technical task. The architect sees what needs to be done.
3. The designer is the happiest person. He takes the requirements of the architect and simply labs them to the level of a detailed design of the system. The designer knows how to make specific details.
4. The project manager takes the project and looks at how many people, hardware, money and other resources are needed. Makes a work plan. PM knows who will do and how much it will cost .

Then, in the reverse order, the project is accepted.

Also, chief engineers (in places where there is a lot of iron or where complex work is required) and other people can participate here. Often the roles are combined - for example, an architect can be both a designer and take on part of the analytics. PM can sometimes be a team lead for developers. But the role model is something like this.

Next - IMHO about what you need from the first three roles.

An architect, oddly enough, is a person who comes into contact with the real world. If we consider the development model, the developer or engineer → designer → architect (parts of the project) → lead architect, then at first the real world is behind glass and it seems safe. The designer at the entrance has the dry requirements of a senior fellow architect. As you grow along this chain (it’s not the only possible one, development doesn’t necessarily follow this way), you need to communicate more and more with other people from your team and the customer.

There is a need for additional skills. First come technical skills - for example, when we select designers from developers and engineers, we want them to be able to clearly monitor the monitoring of large networks, application groups, be able to manage network configuration, make an inventory of the network, know the theory about network models and control protocols. For young architects, not only data collection skills are needed, but also their display, you need to be able to work with arrays of visually assembled data, build schemes that are understandable to everyone in the team.

Again, it is unlikely that the designer will need skills to manage the service desk or skills of migration-changes. And to the architect - very much, because the process has three stages: where are we now, how will we live the next year, and where will we be at the end of the project. And this year it would be good not to lose under the motto “under construction”.

As the sophistication of the architect grows, the requirements for knowledge of standards increase. You can start with the affectionate and gentle GOST 34, and then read about the principles of GIS placement for medicine with personal and payment data right away. There, design methodologies. The designer does not need to know the theory of project management, and the architect must understand how people work (at least at the level of understanding what a planning error is). The lead architect should be able to be PM'om if necessary, but never do such a job.

And then the non-standard and often underestimated begins. For example, why does a normal IT specialist need the skills to speak and conduct presentations? And they are needed, at least basic. To begin with - not to start explaining the new system with the words:

“You are all blissful idiots here.” See what we will do.

The real case, by the way. Most importantly, the person answered for the words and proved why they are such people. But the performers after this beginning were not eager to work. In fact, presentation skills are not needed for this, but in order to explain their ideas to the rest of the team. There are several basic things that are very time-saving for everyone.

The designer and the ordinary architect, in theory, do not need to know a lot about sales. The presenter - it is necessary, he had to at least once sell an IT solution. Because then he will know what language the business speaks. And this will not be “some risks of increasing the FRR of the navigation system”, but “if we do not change this, you will have a full corpse plane in the strip”. There is a slight difference in the credibility and accuracy of reporting. Very close lies the skill of choosing promising products, when nothing is clear about the technology (if you could choose it yourself, then you know that the customer is in a similar situation when the architect shows a couple of options).

Need the ability to audit other people's infrastructure. This is to be able to understand what is important and what is not. By the standard, anyone can, but with the understanding that it is more important at the application level, and where you can come to terms with some features of the infrastructure and the project - if only it worked as it should for the business - no longer.

A very important skill in choosing a design solution is whether a person knows how to justify a choice or not. If the assessment is done on the basis of price, reliability, scalability and other factors in the aggregate - this is a rational designer. And if the assessment is made taking into account all possible scenarios collected by the analyst, then this is the lead architect. Why? Because you still need to be able to identify the dependencies of the project, its risks and exact requirements. Revealing is not when you introduced and found out that something is missing, but when you knew in advance what would happen and prepared in advance. For a couple of years. Here, the leading architect differs from his more applied colleague in that he thinks about it always and in everything.

In general, this is to prepare in advance and think through all the options - probably the most important difference between a professional and a person who can design a system. The architect needs to consider everything: possible non-traditional uses, and protection from the fool, and think over the points of failure, the transition process. A simplified analogy is this: if you played urban strategies, then you know that sometimes the best architecture for “in 10 years” can be extremely counterintuitive. You must first build a city, and then refactor it to understand how to properly. The architect does not have such luxury - construction and refactoring go to the head, and an already optimized model is taken into work. Architect - he thinks about the concept and impact on related systems, about the purpose, applicability and benefits.

Important skills are the formulation of technical requirements and terms of reference. And also - risk and change assessments. If a person worked only with projects until, say, 50 days, the evaluation skills are most likely insufficient. Really large projects have their own peculiarities related to the specifics of the customer and the fact that with a large accumulation of usual errors it is no longer possible to "finish it in half an hour in the evening." More precisely, time is a very limited resource, and extra working time does not appear out of nowhere.

Preparation of different plans - it is not enough to have a plan for your unit, resource plans are still being prepared (regardless of affiliation to units). This removes the need to control the plan of a whole foreign unit, - you need to understand the competencies and capabilities of the team.

Documentation development is just a useful skill, needed at any stage. He also greatly disciplines in terms of systems thinking.

Decomposition of works - it seems PM'nyy skill, but in fact it is the task of the architect. The project manager himself will not be able to do this, because he does not have sufficient competencies in the designed system, and he simply collects information from the architect, designers and engineers, draws up a schedule and carefully monitors the execution, motivating the team if necessary. Yes, projects are often well-versed enough to understand where it grows from, but it is the architect who makes the right decomposition.

Business communication skills - if a leading architect does not know how to do this, then he very quickly ceases to be a leader, as serious people do not talk to him. Because it is one thing to express an opinion on the system with the word "ass" in the middle in a smoking room, and another thing is the same to the vice-president of a European company. Plus, you need fluent English to communicate with vendors. The liver and brain are preserved in their original form. Although, for example, I often meet in the process that “sales” just know what kind of meetings an architect needs to draw the right patterns in the air with their fingers - and take them with them to the customer.

Of the “universal” skills, usually when assigning a role, the feedback of previous person’s leaders on labor biography is evaluated. We need a focus on the result: not to pass the system, but to solve the problem. “Everything is done according to the ToR, but does not work” - this is not a solution to the problem.

Curiosity is a very important criterion: as a rule, if a person seeks new knowledge and learns himself, this is an occasion to think about why he lives. So he cares (well, or he’s getting ready to change company, gee-gee). The architect should not care more than anyone else.

Time management is important: for the designer - setting priorities in the spirit of short sprints (received the task - did - passed - received a new one), but for the architect - to determine the deadlines for his tasks, their priorities and do everything right yourself. And also the ability to make decisions in conditions of lack of time, lack of resources and when everything around is on fire: the bicycle is on fire, and crutches are on fire, and you are on fire. An “elongated” project, when something went wrong, is not only a kilometer of nerves and lack of sleep, but also a chance to get cooler, realizing something for yourself about how tasks are really solved in the real world.

Like this. I repeat: this is a harsh IMHO, but my school with experienced comrades showed that it is necessary to grow approximately in this direction. And I expect something similar from my colleagues in the areas of projects.

Therefore, as I said, being an architect is both intense and interesting. It has become especially interesting in recent years, when infrastructures appeared that can be changed relatively quickly - in particular, on the basis of clouds. For example, in our Technoserv cloud, architects are needed for almost every move - for many it is an opportunity not only to transfer the infrastructure to the cloud, but also to immediately chop off the “tail” from any legacy and stretching crutches, designing the system correctly - since it changes anyway.

If you suddenly want to become an architect, and your company does not have the courses you really need, think about it. A lot of competencies are associated with such basic things as project management and negotiations. Although this is more the story of PM'a or "sales", it can also come in handy unexpectedly for you.

This is the material of the architect of our Cloud Technoserv Cloud Alexander Shubin. Here is his last post about the architect : what his work looks like.