Hello, Habr! My name is Sergei Terekhin, and I am a systems architect. Even IT-savvy people do not always know the specifics of my work. I will tell you how I managed to become a systems architect, what I do, and also about the charms, pains and prospects of this profession.
A systems architect is more of a role than a specific position. No university teaches this profession. And the paradox is that these same mythical system architects are in high demand and without their participation, no large business based on IT could normally function.
If you think that the world of bloody Enterprise is dying and one day all corporate IT will be out of the cloud, a wave of indignation rises in you and your hands reach for tomatoes to launch into the author … Wait. In reality, the monsters of Russian business still prefer to build their IT differently. And the role of the system architect in this approach to infrastructure is very important. These people analyze the tasks that the business sets for IT, what exactly needs to be done and how best to achieve the goals. They choose the tools that are optimal for a particular situation, come up with the architecture of the future computing complex as a whole, and sometimes each individual module in it. And most importantly, system architects see the overall strategy for implementing the infrastructure and make sure that all parts of the chosen solution fit into this general canvas.
So what are they, that is, we, in fact, do?
Three types of architects
The easiest way to understand this is by understanding what architects are in IT.
There is the most common and understandable definition “Solution architect” or “Solution-architect” Is a specialist who understands how a certain application system is arranged and should work (web service, social network, ERP system, etc.). He keeps the development teams within the scope of the terms of reference and helps create solutions by focusing on the business problem, not just the functional requirements of the executable code. Any application should work on something, and the data with which it operates should be stored for a long time and without loss. The solution architect can only formulate what resources are required and how quickly the fallen service should rise. Who will make this a reality?
This is where the “System architect”… He is a guru in the creation of IT infrastructure, including data centers, hardware, networks, various storage systems and server platforms. Its main task is to prepare the infrastructure for the requirements that applications dictate to it. A systems architect may be responsible for many systems that are in one way or another at the infrastructure level, providing the required performance, reliability, and availability. But this does not change the essence – the system architect comes up with what the IT infrastructure as a whole will look like and what it should “be able to”.
Ideally, the synergy of system and solution architects should give the company the same impetus for development. In reality, there is an abyss between them. Solution architects don’t know how the infrastructure works, and system architects are often not interested in understanding how software works. That is why there appears above them “Enterprise architect” Is a superman capable of connecting two segments of architecture. This is not some separate “biological” species, but rather a new evolutionary form of development of a system and solution-architect. Usually it connects two banks over the same abyss.
My personal experience
Personally, I started out as a simple engineer. While still a student, he worked as an enikeishik, then headed a small department of three people in a company in Primorye. After that he moved to St. Petersburg and there he first encountered a full-fledged IT infrastructure, becoming the head of the server and storage systems operation group. After some time, Moscow attracted me. For several years, I became the head of the IT infrastructure directorate, where, in addition to the position and the new scale of tasks, I was given a set of administrative and, as I later understood, architectural tasks. It was necessary to deal with this on the go, and a lot of things were easy to take and do with your own hands. Often for the first time.
In fact, I was already a systems architect then, but without a title; performed certain functions not for customers, but for the employer, designing virtualization systems, designing domain forests from scratch, rebuilding storage networks in a new topology. Once at Jet Infosystems, I finally officially began to bear the proud title of a system architect.
Football and chess players
Our company conducts many large and complex projects, and therefore I am not the only system architect on our staff. It turns out that this position can be reached in different ways. For example, I am a “football player”. Throughout my career I have been “playing on the field”: running around data centers, physically dealing with equipment, knowing its features, solving problems in a real environment. But there are excellent architects “chess players”. They develop from deep theorists who were initially engaged only in design and do not have rich “field” experience.
Each career path has its own pros and cons. I once attended a meeting where my fellow architects were preparing a comparison table for two backup systems. This was strange to me, because, as a practitioner, I knew perfectly well how much one solution is better than another. What is there – a cut above! Practice provides good support in making decisions. At the same time, theorists are more impartial in evaluating all possible options, especially when everything is confusing and downright bad. So the difference between practitioners and theorists does not affect the quality of the decisions made.
Ultimately, today, as a systems architect, I belong exactly to theorists. After “field” work on a medium-sized IT infrastructure, I moved to the major league, but not “football”, but “chess”. For some time I had to get used to it: change the nature of my thinking and work a lot with people.
What skills does an IT architect need?
Ability to abstract
IT architects design complex solutions for unique business challenges. There are no standard cases on the market that can be used anytime, anywhere. How in chess, out of 32 pieces, you can get 10120 chess games, as well as the same set of solutions and products can be combined into various IT systems, have a different structure and, as a result, get unique functionality. It is important for an IT architect to develop the flexibility of thinking in order to look at the project from a different angle, be able to break it down into logical parts and find the most appropriate solution.
Management and love for people <3
An architect is more than just IT-savvy and capable of blindfolded designing and building a multi-component infrastructure. It is also a great manager who interacts with people. Introverts in this position can be difficult because it involves continuous contact with their project team and client. Moreover, in addition to technical requirements, almost every task comes with a weighty baggage of “political” conditions.
Somehow on the project we ran into the “human factor”. The DBMS specialist was a cool DBA. He also had a straightforward and stubborn character. The application migration was long and painful, and he was tired of a million questions about each system. Once he stopped giving out the necessary information on the database. The migration has stalled.
Then I stopped all migrations and began to figure out what was going on. I have never endured so much indignation and disagreement from colleagues! But why suffer and support a process that is worse than ever? While the engineers were focusing on other tasks, we drew a common sizing for all servers and DBMS clusters, made a table, and I personally went to that specialist, whom everyone was already afraid of at that time. We sat, talked, found common themes. We discussed the “footcloth” for 100 database servers. So finally there was a migration map for all databases until the end of the project. It was no longer necessary to go to the DBA with every little thing, and the migration process got back on track.
High learning ability
IT, as an industry, includes so many areas that it is unrealistic to be an expert in each of them. The systems architect looks in breadth rather than in depth. But he should be able to understand any topic based on his basic knowledge, even if this area is completely new to him.
The desire to be “on the crest of the wave”
A system architect is obliged to follow foreign trends in the development of IT infrastructure and work with it. It is better for such a specialist to speak at least one foreign language, regularly attend professional conferences and improve their qualifications. Preferably, at the expense of the employer.
Business language proficiency
An architect is expected not only to have expert knowledge, but also to be able to present a project to a customer, including top management. At the same time, you need to operate with values and arguments from the business world. Executives are not interested in the Nimbus-2000 broom because it is the most current and fastest model. But it will be attractive if you correctly prove how buying it will help you to solve your business problems as efficiently as possible.
We joke with colleagues that the main task of an IT architect is to deal with uncertainty. We have to act in conditions when there are more questions than answers. How to do this without making mistakes? No answer. When making a decision, an IT architect begins to be responsible for it from that very second. And eliminate the consequences of their mistakes, if any. It is impossible to eliminate errors, but you can minimize them. There is only one “antidote” – accumulated experience. When you already have a field with a rake behind you, most often you know in advance where the pitfalls are hidden and how to get around them.
The IT world today is divided into two camps. In the first, those who believe in clouds, in the second, those who face the reality of “big IT” and understand that the digital era still has a long way to go. The former consider the latter to be dinosaurs whose days are numbered. But in fact, on-premise is not yet giving way to clouds, as analysts and experts predicted. Both directions are developing in parallel. And system architects are in high demand. And more and more, taking into account the growing role of IT in recent years in various areas of business.
Many people forget that under the most sophisticated and user-friendly systems, including those that allow getting IT services on the fly in the clouds, there is good old iron. And so that each of us can fully enjoy using any application without brakes, freezes and “black screens”, some system architect must thoughtfully do his job and put a properly designed IT infrastructure under it.
Author: Sergey Terekhin, Head of Complex Projects Department, Jet Infosystems