What you need to know about senior systems architect
- Post by: Public
- on: 23-09-19
An architect, oddly enough, is a person who comes into contact with the real world. If we consider the development model as a developer or engineer → designer → architect (parts of the project) → leading architect, then at first the real world is behind the glass and it seems safe. The designer at the entrance has the dry requirements of a senior architect colleague. As you grow along this chain (it is not the only possible one, development does not necessarily go that 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, they need not only data collection skills, 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 Senior System Architect requirements for knowledge of standards increase. You can start with the affectionate and gentle GOST 34, and then read about the principles of placing a GIS 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
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. Leading - it is necessary, he had at least once to 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 Senior System Architect. 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 the business needed - 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 made by 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, a 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 Senior System Architect probably the most important difference between a professional and a person who can design a system. The architect must consider everything: possible unconventional 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.