What you need to know to become a system architect

Roles in the project look like this:

1. The analyst hears a task from the business in the spirit of “we need to work faster” and is going to find out what is needed for that. Picks around for a long time and learns, for example, that production needs a simpler or more transparent scheme for processing orders. Discusses with the team. Business decides to do. The analyst throws at the architect the requirements for a new system. The analyst finds out where to go.
2. The architect looks at the requirements, looks at the system, is surprised, looks again and again - and then puts 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 the 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 it 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. Often the roles are combined - for example, an architect can be both a designer and take on some of the analytics. PM can sometimes be a developer lead. But the role model is like this.

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

An architect, oddly enough - a man who comes into contact with the real world. If we consider the development model, the developer or the engineer → the designer → the architect (parts of the project) → the leading architect , then at first the real world behind the glass seems to be safe. The designer at the entrance dry requirements of a senior colleague architect. As it grows along this chain (it is not the only possible one, it is not necessarily the development that goes like this), you need to communicate more and more with other people from your team and the customer.

There is a need for additional skills. First, technical skills come - for example, when we select designers from developers and engineers, we want them to clearly see monitoring large networks, groups of applications, know how to manage network configuration, make network inventories, know the theory about network models and control protocols. For young architects, we need not only the skills of data collection, but also their mapping, we need to be able to work with visually collected arrays, to build schemes that everyone can understand in a team.

Again, it is unlikely that the designer will need service desk management skills or migration-change skills. And to the architect, very much, because the process has three stages: where are we now, how will we live 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 architect’s sophistication grows, requirements for standards of knowledge grow. You can start with the tender and gentle GOST 34, and then read about the principles of placing GIS for medicine with personal and payment data immediately. In the same place - 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 a PM if necessary, but never do such work.

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

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

Real case, by the way. The most important thing is that the person answered for words and proved why they are such people. But the performers after such a start were not eager to work. In fact, presentation skills are needed not for this, but in order to explain your ideas to the others in the team. There are a few basic things that really cherish the whole time.

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

We need the skill of auditing someone else's infrastructure. This is to be able to understand what is important and what is not. According to the standard, anyone can, but with the understanding that in the application layer it is more important, and where you can come to terms with some features of the infrastructure and project - if only it works, how the business needs it - no longer.

A very important skill in choosing a design solution is whether a person is able to justify a choice or not. If the assessment is done by price, reliability, scalability and other factors in the aggregate - this is already a rational designer. And if the assessment is done taking into account all the possible scenarios collected by the analyst, this is the lead architect. Why? Because you still need to be able to identify project dependencies, its risks and exact requirements. Detecting is not when you have implemented and learned that something is missing, but when you knew beforehand 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 - prepare in advance and think through all the options - probably the most important difference between a professional and a person who is able to design a system. An architect should take everything into account: possible non-traditional uses, protection from a fool, and think over points of failures, a transition process. A simplified analogy is this: if you have played in city planning strategies, then you know that sometimes the best architecture for “in 10 years” can be extremely counterintuitive. You need to first build a city, and then refactor it, to understand how to properly. The architect has no such luxury - construction and refactoring go in the head, and an optimized model is taken into work. An architect - he thinks about the concept and influence on related systems, about the purpose, applicability and benefits.

Important skills in the formulation of technical requirements and technical specifications. And yet - risk assessment and change. If a person worked only with projects up to, say, 50 days - assessment skills are most likely insufficient. On really big projects there are some peculiarities related to the specifics of the customer and the fact that with a large accumulation of conventional 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 excess working time does not appear from anywhere.

Preparation of different plans - it is not enough to have a plan for your department, resource plans are being prepared (regardless of belonging to the units). This removes the need to control the plan of a whole alien division - it is necessary to understand the competencies and capabilities of the team.

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

Work decomposition seems to be a PM skill, but in reality 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, if necessary, motivating the team. Yes, projects are often well-grounded enough to understand what is growing from where, but it is the architect who does the right decomposition.

Business communication skills - if the lead architect does not know how, then he very quickly ceases to be the lead, because serious people do not speak to him. Because it is one thing to express an opinion on the system with the word “ass” in the middle of a smoking room, and another is the same thing as 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, in the process I often meet with the fact that “sales” just know what kind of meetings an architect needs in order to draw correct patterns in the air with his fingers - and take them with me to the customer.

Of the "universal" skills, usually when assigning a role, the responses of previous leaders of a person on the work history are evaluated. We need a focus on results: do not pass the system, but solve the problem. “Everything is done according to the TK, but it does not work” - this is not a solution to the problem.

A very important criterion is curiosity: as a rule, if a person is looking for new knowledge himself and is learning, this is a reason to wonder why he lives. So, he does not care (well, or he is ready to change the company, gee-gee). The architect should care most.

Time management is important: for a designer, setting priorities in the spirit of short sprints (I got the task, I did it, I passed it, I received a new one), but for the architect, I’d have to determine the time of my tasks myself, their priorities, and I would do everything myself. And the ability to make decisions in the context of lack of time, lack of resources and when everything is burning: the bike is on fire, and the crutches are burning, and you are burning. The “stretched” project, when something went wrong, is not only a kilometer of nerves and lack of sleep, but also a chance to become better, having understood something for yourself about how tasks in the real world are really solved.

That's about it. I repeat: this is a harsh IMHO, but my school among 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 have already said, to be an architect is both stressful and interesting. It has become particularly interesting in recent years, when infrastructures appeared that can be changed relatively quickly - in particular, on the basis of clouds. For example, in our cloud Technoserv architects are needed for almost every move - for many it is an opportunity not only to transfer infrastructure to the cloud, but also to immediately cut off the “tail” from every legacy and stretching crutches, having designed the system correctly - since it changes all the same.

If suddenly you want to become an architect, and your company does not have the courses you really need - think about it. Very many competences are connected with such basic things as project management and negotiations. Although this is more of a history of PM or sales, it can also come in handy for you unexpectedly.

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