System Architect: First After God

A source

"To think correctly is more valuable than to know a lot"
John locke

A system architect is an interesting and extremely important profession in the modern world, and not only related to the IT world. Both today and in the foreseeable future, system architects will be the most sought-after and highly scarce resource in any rapidly developing industry. And necessarily in the field of system integration. Moreover, by the degree and quality of use of system architects can be judged by the maturity of management in the organization. And according to the corresponding assessment of their work, too. In many ways, this is why a significant part of young professionals who are still ahead is interested in obtaining information about the profession of a system architect. What exactly?

If you think that the Creator was not the first system architect, then you can read no further on this article.

It is unlikely that anyone will argue with the fact that the magnificence of our technical civilization surrounding us and the overwhelming number of all sorts of innovations, from shovels and computers to spacecraft, robots and artificial intelligence, were originally invented, designed, created, maintained and continuously upgraded by the global engineering community. However, if you are fundamentally convinced that all this is actually invented, created, etc., for example, exclusively by the proletariat or graduates of the MBA, you will either have to accept the above mentioned by faith, or read it through.

About competencies

Of course, engineers have different specializations, skills, outlook, competencies, and experience. And if you build a pyramid out of them taking into account all of this, then entities that were previously named chief designers will appear at the top, but today in different organizations they are often called systemic, sometimes complex architects, or business architects, which is essentially the same thing. But the main thing is that these names are understood by the people who pronounce them. For example, in real projects, in addition to business processes, there are quite a few other problems that need to be solved comprehensively or systemically.

There is a lot of terminological confusion around the notion of a “system architect”, more associated with a set of tasks or the personal outlook of those who use it. Therefore, it should immediately be noted that the term “systemic” can be derived from two concepts - the “system” itself and the “system approach”, which is by no means the same thing in the modern world. Therefore, in any conversation about system architects (and this is a very important topic for all segments of the market), we should first clarify which architects we are talking about. It is worth mentioning, by the way, that the exact same problem arises when people start talking about the Internet, which actually exists simultaneously in three guises: as a network of networks, as a global information database and as a business platform. Sometimes people can argue and prove something for a long time until they are hoarse until suddenly it turns out that the problems they are discussing are in completely different pools and are almost orthogonal. A small illustration of the above is shown in Fig.1.

Source Fig.1. Orthogonal truth

Note that this is a clear example of only two projections of truth. The networker sees the Internet as a collection of routers connected by communication channels and terminals connected to the “last mile.” The infrastructure builder is aware of the availability of telecommunications, but his being gives priority to what is stored on the network and where it is generated. Developers are often blinded within environments (development, test, presales, finished products), etc. The system architect is obliged to see and understand all the above-mentioned persons, the user who scrolls through the social network, and the businessman who owns this social network, and a lot of people involved in the process. In general, he must understand that to whom and from whom it is necessary.

In relation to system architects, these incarnations have many more varieties. In the simplest case, an “advanced” engineer is a specialist in a particular system and knows what can be built from it and where it can be applied. Yes, he is sometimes called a system architect, but he is a true "warrior of light" exclusively in his field. This field may be a particular supplier’s system / systems or systems that many suppliers produce, but with their own characteristics (for example, switching systems or database management systems). In some foreign companies, such specialists are called “certified engineers”, and here we are leading engineers.

However, all of the above does not apply to the profession of a system architect, the main content of which is still a systematic approach and systems engineering thinking. Indeed, in a huge number of projects, a variety of different types of systems and various solutions for all occasions usually coexist, which implies the presence of higher level specialists. Accordingly, system-engineering thinking is the use of a systems approach in engineering. In turn, system engineering can be defined as a set of ways to create a successful system (that is, satisfying all the needs of customers, users and other relevant system stakeholders) based on an interdisciplinary approach, involving work with various engineering specialties.

The system can be anything from a complex of information systems to entire industrial enterprises (industrial groups), including technological and production processes, logistics, business processes, as well as equipment and buildings. And if, for the lead engineer, the system is, for example, a server farm integrated into a computer system by means of infrastructure software, then for a systems architect, the system is a working complex, where such a farm is a small unit. For example, a large shopping center operated by a company that has an optimally staffed staff (even here the architect participates), optimally selected the ratio of its own staff and contract / outsourcing, designed and implemented all the necessary systems (information, parking, engineering, security systems ...) , an optimal plan of interaction with tenants has been developed ... And the IT infrastructure here is far from the first place in terms of the scope of tasks, even IT as a whole, this is not the most capacious section. In other words, a system architect solves a business problem, and the system for him is an enterprise, an organization, an industry ... with all the processes, people and mechanisms.

A source

Accordingly, the interdisciplinary approach implies work not only exclusively with engineering specialties, but in general with any specialties that will be necessary for the implementation of a particular system (project). In particular, if you take the well-known Roscosmos state corporation, then in its projects it is not difficult to see a place for mechanical engineers, electronic engineers and civil engineers, and for rocket makers, ballistics, cryogenics specialists, psychologists, physicians, astronomers, telecommunications , programmers, financiers, lawyers, etc., etc. And each project will need system architects of different levels. How to understand exactly what you need in a particular project?

See the heart of the problem

It is no secret that to solve any problem, it is necessary to use knowledge, often deeply professional, and the set of necessary professions for each problem is specific, unique. Sometimes it creates a lasting impression that the problems of specialists in each industry are very different from each other. And the specifics of problems come to the fore, which everyone can handle, including crisis managers. Of course, to solve a specific problem, special, sometimes very deep professional knowledge is needed. But there is, however, another approach, called “systems analysis”. This is a kind of universal algorithm for solving problems, suitable for use in any profession, which the system architect uses in his daily practice. Actually, why not? After all, we all live in the same world, obey the general laws of the universe and methodically repeat everything that was created by nature (or the Creator) before us, from time to time sincerely surprised at innovations. Gradually, the universal systemic nature of the world around us (or the potential project space) was realized until the emergence of a technology called “applied system analysis”. This area of ​​knowledge has already become a profession, and system analysts are trained at a number of universities in the world.

It turns out that the likelihood of success increases if you follow the same advice, regardless of the nature of the problem, if you pay attention not to the substantive specificity of a specific problem, but to the technology of working with it, to the sequence of actions and precautions regarding risk research, etc.

The technology of applied systems analysis is often compared with a locksmith's case containing a set of necessary tools and devices. In addition to the tools in his work the master uses the knowledge applied in a certain sequence. An important feature of applied system analysis is to take into account the distinction between problems of consciously formalized (up to the construction of mathematical models) and weakly structured, loose problems, stated in terms of a spoken or descriptive professional language, which, by the way, is quite typical for a considerable number of business customers.

For example, have you ever heard the word Wishlist? It is extremely difficult to bring the Wishlist to a project without a system architect. Between the customer and the performer there is an abyss. And if they very much reach out to each other, then perhaps the desired will happen. However, there are also "little". The case is not clinical, but in real life it happens when the customer cannot really explain what he needs. The customer doesn’t have the requirements that are not yet formed, he even has not formed the Wish list, he just has a problem and he wants everything to work, but he doesn’t know what to do. In general, we need a system architect again.

A source

So, the main tools of system architects, as they say, are obvious, and now we just need to learn how to use it. The latter, however, usually takes a lifetime when competences grow, the hand is “crowded” and inevitably mistakes are made. It is based on your experience, knowledge and previous mistakes (and not only your own), that a system architect can learn to create something worthwhile. Even more - the system architect is simply obliged to learn not only from his mistakes, but also from those around him. Of course, it is impossible to become an expert in all industries or technologies, but without the ability to accumulate and experience others, as your own, you cannot become a system architect. And the ability to absorb other people's knowledge and experience has another useful way out - creativity. Therefore, the system architect is a creative person with sophisticated thinking.

Architectural diversity

Returning to the hierarchy of architects, we note that in addition to the experts on specific solutions from specific manufacturers already discussed above, you can meet architects on specific technologies and services, security and applications, in specific areas or in any subject area, telecommunications and IT. , on management systems and software, on IT and on business processes, on infrastructure and on integration, on equipment and on functional solutions. Locally, each of them can even be called a system architect, but this will be true only if, apart from the niche in which the given architect works, there is nothing more in the project. Otherwise, someone else will have to be at the top, from which the entire project is visible in all the variety of tasks to be solved. This will be the “real” system architect or the main architect of the project. That is, an expert with many competencies in different areas with extensive experience in the implementation of various projects. And not from the point of view of their management, but of versatile technical implementation.

Very often in literature (and even more often on the Internet) a software architect is called a system architect (very often it is a “tmlid” who grew up as an applied architect), which, of course, is true and highly respected among programmers. But long before the programmers start the project, higher order system architects have to build the architecture of the entire design solution, decomposing it into components with an understanding of which technical problems will be solved in each of them and which connections will be between them (and by what parts), what information systems will be needed, specifications will be made, according to which the engineering staff and the project manager will start working. Of course, for all this, it is not enough to be just an engineer, and even more so - just a project manager. The first one needs to get a lot of experience in various areas of project life, but from the second, alas, no system architect will work out in principle (he is “sharpened” to solve very different tasks). On the contrary, in the course of his work, the system architect must have a good idea of ​​the work of the project manager, to whom he represents, in essence, if not the roadmap of the entire project, then at least its draft. In other words, the system architect puts his shoulder to the project manager. And in such a bundle they will succeed.

When is a systems architect required?

In practice, the question often arises: when is it necessary to involve a system architect in the project and at what stage? Figure 2 shows the global field of project activities with the differentiation of projects in terms of the supply of products and the necessary survey, design and other works (the larger the text size, the larger the volume). It also shows the conditional "limit of applicability" of system architects, depicted in blue. Accordingly, there are projects that require minimal resources, when the equipment is simply supplied, when a competition is being prepared or when the entire project can be completed at the expense of an outside contractor. And there are large projects that imply a large amount of various works, including construction, significant supplies of equipment, etc. And, of course, there are exceptions to the rules.

Fig.2. Global field of project activities

When a project appears, it is important to immediately assess its complexity and complexity. And if the project is connected, for example, with the organization of LAN, installation of servers and the implementation of any virtualized functions, including support, which can be easily specified at the initial stage, then the involvement of a system architect in such a project (and this is usually not a cheap resource). ) will be ineffective. In such cases, it is possible to attract application network architects, specialists in virtualization, but not complex system architects.

If the project looks at more than one topic (than, for example, simply organizing a LAN with appropriate connections) and planning, say, construction and installation works, then in some cases it is necessary to clarify its content at the top level. To do this, you should further study the requirements of the customer and, perhaps, even conduct additional interviews, as a result of which any circumstances hidden at first glance will “emerge”. Here you may need a system architect. However, if the project does not go beyond the competence of one unit of the contractor, then the infrastructure architect will be quite enough.

In any project in which a system architect takes part, the latter must have the whole picture of what is happening on the project and monitor compliance with the customer’s requirements so that the proposed solution meets them (and this compliance is not “lost” in the implementation process) in terms of the standards established by the contract quality. It is the system architect who first understands (and more often determines) the sequence of design and project execution and can not only control, but also optimize the project execution time. Indirectly, it can also optimize the cost of the project, since the issue of optimizing the latter often arises in the process of almost any design. It is the system architect who first of all can indicate where to save money and what happens with time, quality, etc.

If we consider the design activity of the system architect as a whole, then he proposes a high-level solution decomposed into the following tasks for designers:

• compliance of the solution (project result) with the requirements of the customer (solution of the customer’s business problem);
• Work decomposition between performers (own and contract) and designer supervision;
• monitoring the performance and quality of the solution as a whole;
• cost optimization solutions.

An important aspect of the system architect’s activities is participation in contests (where time is money) where he is present more with his intellect and experience in order to promptly tell what exactly will work and what not, what technical parameters are feasible, what are the requirements and under what conditions are possible and , most importantly, what about the money you can meet.

In the “pyramid” shown in Fig. 3, the decomposition of the tasks of the complex project is shown and the conditional distribution of responsibilities of the actors involved is given. As can be seen, within the framework of the systems approach, the system architect and the project manager should go hand in hand with it.

RP - project manager
GIP - Chief Project Engineer
Fig.3. Decomposition of system requirements for a complex project

Of course, in the general case, each layer of the "pyramid" imposes requirements on the underlying, which can create the illusion of the possibility of a non-system approach or the fundamental uselessness of any complex architects at all. They say that the engineers of each layer will write technical requirements for "downstream" colleagues, and everything will be formed by itself. Everything would be so simple if it were not for the customer, who is often not limited to the requirements for business processes, but wants (it wants!) To have a certain ICT infrastructure, specific ventilation and air conditioning (for example, in the data center you must be able to manage individual conditioners), transparent elevators on the wall of the building, as well as the building itself. However, it is good when the client himself explicitly declares his wishes. But they can be present in an implicit form, which is to be recognized and translated into clear technical requirements by the system architect, who has the whole picture in his head.

A source

By the way, the same building may well be determined by business requirements. For example, it is logical to place an investment bank in the center of Moscow (where there are a lot of problems with communications, etc.), and not somewhere in a residential area (even if it’s 10 times cheaper there), which the engineers will most likely offer (and engineering side will be right). A separate “song” is the requirements for security, the numerous threats of which are multiplying before our eyes, and the client’s competence in this area is also constantly increasing. Therefore, it is advisable to consider the actual requirements arising on a typical project as shown in Figure 4, and all of them can be resolved only within the framework of a systematic approach.

Fig.4. A variety of requirements in a typical project

Returning to Fig. 3, it should be clarified that in the absence of the client’s special wishes about the construction and arrangement of engineering systems, the chief engineer of the project can easily cope with their creation without the involvement of a system architect.

At specialized forums, one can sometimes find arguments that the importance of having a system architect (usually actually more interested in its cost) in projects is greatly exaggerated, and, they say, for complete happiness, it is enough to have several competent engineers and programmers with different specializations. You don’t have to argue with such a position, you just have to offer all these wonderful people to write, for example, the concept or strategy of the modern development of an industry or some complex production such as the so-called digital enterprise, taking into account related trends, business processes, digital models , logistics, support, new business models, etc. (such tasks are increasingly common in the practice of system integrators), and everything will fall into place.

Enterprise architect

He is also called a corporate architect, who is the “alter ego” of the system architect of the executing company, but from the side of the client company of the project.

In fact, someone “from the other side” should understand well how the ordered project is being executed, as well as know the architecture of all the systems of our own company, enter new fragments in it, not to mention permanent corporate modernization. In the best case, the system architect and the enterprise architect should work closely together during the project.

And what is the result?

Currently, there is a lot of confusion with the glossary, which is different for all architects. In addition, there is always a moment of vanity in belonging to a prestigious profession, and often people tend to be called architects in order to attract more respect for themselves. At the same time, this confusion really complicates the search for architects (and this is a very scarce specialty) to personnel of personnel services and they themselves create chaos when job descriptions are published.

It is worth repeating again that the system architect also works with the system, but for him the system is a working business, a working enterprise, a working service. Even if the system architect performs a project to develop a certain information system, he is working on not just the system itself, but the result of the system’s work. He solves a business problem using technology and changing processes, rather than building a system of software and hardware. The difference here is about the same as between “building a railway and starting a train between two settlements” and “providing railway communication between two settlements”. Many will understand the task of how to build a road and start up trains, some will go further, and only a system architect will think about how to evaluate passenger traffic, think about the schedule, size and types of trains, types and sizes of stations and stopping points, number of ticket offices, ways and control payment, ensuring preferential travel, the possibility / need to transport goods along this line, provide for routine maintenance for trains and railways, safety of facilities in accordance with the requirements of the civil defense and emergency situations and accessibility to invo Alids ... Feel the difference?

Obviously, the above information is sufficient to clarify who the system architects are and what they should have, as well as to understand and appreciate the role of system architects in the whole way of project activities from expertise to implementation. Accordingly, the above should be taken into account in the implementation of various management activities. After all, its effectiveness is judged, including by the level and degree of use of the institute of system architects.

However, no matter how the community of system architects develops, something is not yet available to him. Take at least a well-known project that the Creator has managed to effectively implement in just 7 days. These are opportunities, these are competencies! There is something to learn and where to strive to be somewhere nearby. True, it sometimes takes a lifetime, but such is the profession. And it is not surprising that the “rare bird” of system (integrated) architects is younger than 30 years. What to do to become her?

Study, study and study again!

The article was published on the portal X.
Authors publication:
Golyshko A.V. - systems analyst at Technoserv Group
Grunin A.V. - Head of the System Solutions Department of the Technoserv Group of Companies
Guzhvenko D.B. - system architect of the GC "Technoserv"