At what level should a systems architect know technologies?

Question

Programming

Goodnight.
System architects are the second after God, who determine the path of product development and the stack of technologies used. Accordingly, it is quite logical that the architect should have a deep knowledge of everything and everything: databases (broad spectrum), PL (broad spectrum), frameworks (broad spectrum), be aware of the advantages and disadvantages of each, in order, thus, to choose the optimal set technologies for each specific case. In addition, the architect must be good at system administration.
However, it is no secret that even in your narrow stack of one PL and key frameworks, it can be difficult for the average programmer to keep up with the pace of industry development, and even more so, to keep in mind at least the key points of the current state of affairs. Full-stack developers are a couple of times more difficult, because they have at least two working PLs and twice as many technologies.
Based on this, the question is brewing: how superhuman should a system architect be, and at what age should he lose his virginityhow deeply does he need to know each technology, including the "pitfalls" that, as a rule, are available only to specialists who have worked decently with the technology? Again, the industry is very turbulent - when do you have time to work and follow everything that happens in it? Or am I overly idealistic about the role of architects in development?
Thanks in advance.

Answer 1

Disclaimer: I'm not a system architect, and I don't even know who exactly should be called that, probably it's something like a technical director.
Yes, excessive. Architects (as you call them) are not gods and not even "second after god".
An architect can know the pitfalls, but he does not have to find them himself. Usually they are reported to him by specialists who have worked with the technology. And if the technology has not yet been tested, then it is enough for an architect to understand this, and to be able to estimate the risks of finding pitfalls - this skill does not apply to a specific technology.
And you need to be able to highlight the main thing. Well, for example, the day before yesterday they announced docker on Windows on native containers. What does a good CTO need to know? That there are containers in Windows 2016 (moreover, two types, real and on top of hyper-v), that Docker will now use them with all the consequences. It goes without saying that you need to understand what a container is and how it differs from a VM. That's all you need to know, well, look for feedback from the first who dare to try out the technology in action.
Well, or let's take TypeScript. It is not necessary to write on it or know it thoroughly. It is enough to understand what static typing is in the language, and it will already be possible to imagine the difference between using ES5 / ES6 and TypeScript in a large project. It is enough to decide to test it on your own (as we are doing now) on a small piece of the project, and draw a conclusion about its further use.
Finally, let's take databases. I don't think that a good "architect" is required to know that in some Monge some queries with aggregation on two properties work 5 times slower than on one property. However, the fact that Monge does not have an atomic record of several documents at once is very useful to know, I would even say critical (otherwise you can try to write some kind of billing in Monge instead of some relational database, and disrupt a bunch of problems).
It is much more important for the technical director of the project ("architect") to be able to process information correctly, be able to remove marketing husks (like the one that was and is with NoSQL from all problems and misfortunes), calmly respond to trendy buzzwords, and collect a library of trusted people and information resources . And it is important to be aware of things that do not change over time, or change slowly and reluctantly:

• for which tasks functional languages ​​are suitable, and for which - OO;
  
• that a graph DBMS tends to process search queries with a long chain length faster;
  
• that the statement from the previous paragraph would be nice to check in practice with specific DBMS;
  
• that web frameworks are thick and thin;
  
• what are the variations of the MVC pattern today;
  
• that garbage collection is always overhead and sometimes not entirely predictable behavior;
  
• that data from the user needs to be filtered, otherwise the Turing machine will be found in your system in the wrong place;
  
• that the information system has components with different levels of trust, as well as employees;
  
• that transactions in the DBMS were not invented to make textbooks thicker.
  

Answer 2

You are speaking in the words of my programming teacher. He also idolizes system architects. In his opinion, these are the people who design / write either the kernel (a la Linus Torvalds) or the entire OS. They live in a slightly distorted reality and in a slightly different space of time, the secrets of the universe are accessible to them, and they also go to work in a dressing gown and slippers, and use the CD-ROM carriage as a stand for a coffee mug.
Vadim Borisovich - my respect.

Answer 3

Well, the system architect is understood by me as work at the hardware level. That is, he must be able to get the equipment to send two bytes to the space station circling Pluto. And so the system architect must perfect electronics and circuitry, digital circuitry (the list of technologies and architectures is also included in this list, but it is not necessary to know everything; it is important to be able to grasp emerging new technologies on the fly and understand them), low-level programming (you can also to program with opcodes) in assembler, as well as system programming languages ​​that directly affect the creation of operating systems, drivers, and the like. And everything else is not quite for the system architect. Databases and other things are handled by other programmers.

Answer 4

In our universities, the word system is somehow incorrectly interpreted everywhere. Even the specialty code "system programmer" often does not correspond to the program at all.
Regarding architects, it is worth noting that for the web this is extremely rarely singled out in a separate position. The tech lead / tech lead or senior developer is responsible for the architecture, decisions are made from a combination of their own and external experience.