Системный архитектор кто это

Карьера в IT: должность Software Architect

Данная статья — вторая из серии «Карьера в IT», в каждом выпуске которой мы рассматриваем одну из должностей в сфере разработки ПО. В этой части обсудим высшую ступеньку непосредственно программистской карьеры в IT — Software Architect.

Software Architect — это IT-специалист, принимающий решения относительно внутреннего устройства и внешних интерфейсов программного комплекса с учётом проектных требований и имеющихся ресурсов.

По статистике ДОУ, среднему украинскому архитектору 30 лет, он имеет опыт работы и получает $4000.

Задачи и обязанности

Главная задача архитектора — поиск оптимальных (простых, удобных, дешевых) решений, которые будут максимально соответствовать потребностям заказчика и возможностям команды. На основании бизнес-требований этот специалист создает функциональную и техническую спецификацию системы, планирует и проектирует способы технической реализации, выбирает технологии.

Архитектор обязан иметь целостное видение всей системы и грамотно определять, как система будет разбита на модули, и как эти модули будут взаимодействовать между собой, — только после принятия этих решений команда разработчиков сможет приступить к работе над отдельными модулями.

В обязанности архитектора входит:
— Проектирование системы на основе требований заказчика;
— Определение архитектуры приложения или ее эволюции;
— Выбор технологии для каждого звена системы;
— Выбор способов взаимодействия между компонентами системы;
— Создание рабочего прототипа;
— Дизайн интерфейсов и компонентов приложения;
— Подбор или проектирование фреймворков;
— Анализ и исправление проблем производительности;
— Архитектурное ревью бизнес-требований;
— Ревью кода и дизайна при больших изменениях;
— Рефакторинг кода;
— Написание и поддержка стандартов кодирования, каталогов проектных паттернов и антипаттернов;
— Документирование всех архитектурных решений, постоянное обновление документации;
— Риск-менеджмент;
— Координирование архитектуры на протяжении последующего жизненного цикла ПО;
— Обучение и консультирование программистов.

«Архитектор ПО ничем не отличаются от других Архитекторов, которые строят мосты или дома. Приложение — это тоже строение: ему нужен правильный фундамент и сильные решения. Стоя под мостом во время проверки нагрузкой, нужно быть уверенным, что он не рухнет».

Необходимо стратегическое видение: проектные решения архитектора должны обеспечивать возможность корректных изменений или улучшений системы, ее дальнейшего расширения, создания следующих версий, а также возможность повторного использования кода в других проектах.

«В отличие от проектного менеджера, который фокусируется на вопросе, как успешно довести проект до конца в рамках текущих бюджетов и ресурсов, архитектор отвечает за то, как технически правильно довести проект до конца в рамках текущих ресурсов и не застрелиться при разработке последующих версий».

Кроме этого, от архитектора ожидается глубокое понимание предметной области бизнеса, знание основных стандартов и трендов, связанных с разрабатываемым продуктом. Или, если от противного, — незнание специалистом каких-либо бизнес-деталей, необходимых для проектирования, не может служить оправданием неспособности архитектора выполнить свою работу.

«Без знания предметной области ты остаешься на уровне сеньора. Чем больше ты понимаешь язык бизнеса, тем ты ценнее».

Еще одна особенность должности архитектора связана с необходимостью искать компромиссы. В каждом проекте фигурирует большое количество заинтересованных лиц (стейкхолдеров):
— Заказчик — заинтересован в решении проблемы, в минимизации стоимости решения, в однообразии всех технических решений, простоте их использования и поддержания;
— Топ-менеджмент — в максимизации прибыли;
— Менеджмент проекта — в своевременном и качественном выполнении проекта;
— Члены проектной команды всех ролей и специальностей — в интересной, комфортной работе, отсутствии давления, использовании удобных и современных инструментов и технологий.

У каждого из них есть свои интересы в данном проекте, и каждый предоставляет свои требования, пожелания, ограничения. Кроме этого, каждый разговаривает на своем языке (техническом или языке бизнеса), каждый понимает и воспринимает аргументы из своей области и не понимает чужих. Архитектору необходимо собирать общую картину требований и органичений всех стейкхолдеров, соединять их знания и интересы, обеспечивать эффективную коммуникацию между ними, вырабатывать решения, позволяющие оптимальным образом удовлетворить максимальное количество требований каждого.

«Умение выбрать оптимальное решение вместо лучшего — вот основная задача архитектора».

Таким образом, архитектор — это специалист, который хорошо знает возможности различных технологий. Его главные обязанности: устанавливать требования как к системе в целом, так и к каждому ее отдельному компоненту, определять дизайн решения и способы достижения цели. Он должен уметь оценить риски, связанные с выбранными технологиями, и подготовить альтернативны.

«Я занимаюсь не столько реализацией конкретных фич игры, сколько придумыванием того, как они должны быть реализованы вообще и каким будет их взаимодействие друг с другом. Например, при разработке игры от меня требуется выбрать технологии реализации клиента и сервера, выбрать способ коммуникации между ними, определиться, какие операции следует реализовать на клиенте, а какие — на сервере, и как все это будет храниться в базе. В мои обязанности входит работа над движком игры — как реализовать это всё, чтобы оно было легко переносимо и работало как можно быстрее. Допустим, наша новая игра дает всего лишь на первом iPad. Во всем виноват рендер, который должен отсортировать и нарисовать множество объектов. Моя задача: придумать более производительный алгоритм и реализовать его. Задача программистов: прикрутить его к конкретным проектам».

Типичный рабочий день архитетора предпологает:
— участие в групповом планировании, митингах, совещаниях с заказчиком;
— консультирование команды по текущим вопросам;
— проектирование и написание технической документации;
— изучение новых технологий;
— работа с кодом проекта, прототипирование, оптимизация, рефакторинг.

«Всегда нужно быть готовым к переключению между задачами — это норма для архитектора».

Достоинства и недостатки

Должность архитектора привлекает разработчиков открытыми возможностями знакомиться с новыми технологиями и идеями, влиять на процесс разработки и судьбу проекта, а также решать глобальные задачи, оставаясь при этом программистом.

«Работая архитектором, я занимаюсь тем, что люблю — решаю сложные инженерные задачи, которые делают мир технологий лучше».

«Давно занимаюсь проблемой создания искусственного интеллекта, и моя работа помогает мне на нужном уровне абстракции понять предметные области, в которых ведет деятельность человек — как они функционируют и как их можно реализовать единообразно программным способом».

Недостатки: большая ответственность, необходимость тщательно взвешивать каждое принятое решение. Цена ошибки архитектора выше, чем цена ошибки другого технического специалиста на проекте.

Также архитекторы относят к недостаткам возрастание управленческой нагрузки, частые совещания и митинги, необходимость работать преимущественно с чужим кодом, а не с собственным.

«Иногда хочется просто программировать, а не решать вопросы вселенского масштаба о взаимодействии и принимать решения по снижению зависимости между частями каких-то систем. Например, написать код, реализовать какой-то алгоритм и отладить его. Скажу по секрету, иногда удается отбить у разработчиков интересную задачу!».

«Труд архитектора иногда менее заметен пользователями и менеджерами, чем труд разработчика. Последний добавил кнопку — пользователь рад, так как давно ее ждал. Архитектор сделал рефакторинг — программисты сказали „ОК“. Меньше откликов от конечных пользователей».

Как стать архитектором и куда идти дальше?

Должность архитектора является следующим этапом развития Senior/Lead-инженера, который не хочет уходить в менеджмент и отдаляться от технических задач.

Основные навыки и качества, которыми должен обладать специалист, желающий стать архитектором, — это системное мышление, склонность к анализу, большой опыт, коммуникативные способности. Важно умение доводить работу до конца, а также высокая скорость самостоятельного обучения и мотивация к получению новых знаний. Кроме этого, архитектор должен уметь подать и продать свое видение проекта в техническом плане.

«Быть очень сильным, умным специалистом, идти в ногу с развитием технологий, предугадывать их ход и быть всегда на шаг впереди, постоянно стремиться к оттачиванию своих умений, обладать хорошим абстрактным мышлением, вмещая сложные системы и процессы у себя в голове, и уметь четко и правильно аргументировать свои решения».

Из технических знаний: необходимо разбираться в алгоритмах и их сложностях, быть в курсе доступных платформ и технологий и знать их достоинства и недостатки.

Разработчик, решивший стать архитектором, должен быть готов к смене профессии и изучению ее основ, к выполнению новых активностей, к смещению фокуса с технических аспектов на другие. Помимо опыта программирования, огромным плюсом для будущего архитектора будет опыт работы в других сферах разработки ПО, таких как тестирование, менеджмент, разработка дизайна и юзабилити, бизнес анализ.

Согласно данным IASA, результаты опроса, в ходе которого архитекторов со всего мира просили оценить важность того или иного качества/умения в успешной работе, выглядят следующим образом:

Самые важные качества/навыки по категориям (по убыванию):

Human Dynamics:
— Collaboration and Negotiation
— Presentation Skill
— Leadership and Management

IT Environment:
— Platforms and Frameworks
— Application Development
— General IT Skills

Business Technology Strategy:
— Technology Strategy Development
— Requirements Discovery and Constraints Analysis
— Business Fundamentals

Design Skills:
— Architectural Description
— Design Analysis and Testing
— Decomposition and Reuse
— Design Methodologies and Processes

Quality Attributes:
— Reliability, Availability, Scalability
— Extensibility and Flexibility
— Security

«Быть архитектором — это работать, а не просто отрабатывать получаемую зп».

«Программист становится программистом не тогда, когда начинает писать работающий код, а когда начинает думать как программист. Это просто склад ума и характера — либо ты мыслишь как архитектор (или программист), либо нет».

«Нужно побольше работать над своими проектами в свободное время. Единственный способ стать архитектором — начать создавать архитектуры. Со временем начнет получаться. Еще через время начнет получаться хорошо. Когда у тебя уже готово 90% проекта, а ты внезапно осознаешь, что реализация оставшихся десяти займет больше времени и породит кучу костылей, и это проще переписать заново, чем закончить, то в будущем будешь уже продумывать все наперед. Правда тут тоже стоит меру знать. Желая сделать все идеально, можно и вовсе ни одного проекта не доделать».

«Я рекомендую при использовании какого-либо программного продукта стараться понять, как он устроен, и придумывать, как бы вы реализовывали ту или иную его функцию. Вот, предположим, есть в игре кнопка, при нажатии на которую, усиливаются щиты корабля. И я, играя в эту игру, стараюсь понять, как она отрисовывается на экране и как она сигналит о своем нажатии основному коду, как выполняется проверка на наличие доступной энергии и на отсутствие повреждений у системы щитов, как рассчитывается мощность щитов в зависимости от накачанной в них энергии и т. п. Разумеется, я не могу узнать, как оно там устроено на самом деле, но я могу прикинуть, как бы я это делал и что бы при этом использовал».

«Есть два вида разработчиков: те, кто делает поезда, и те, кто строит для них вагоны. Прежде чем сделать первый стоящий проект в качестве архитектора, я 6 с половиной лет клепал разного качества тележки. Понимание того, что ты можешь планировать и создавать архитектуру проекта, приходит вместе систематизацией большого количества знаний из разных областей программирования».

Перспективы карьерного развития архитектора имеют 2 ракурса: либо углубление в техническую часть и развитие «от маленьких систем к enterprise и управлению космическими кораблями в масштабах вселенной», либо переход в менеджмент на позицию СТО или VP of Engineering. Фактически архитектор — это финальный этап технического карьерного роста.

«Прелесть данной позиции именно в том, что в ней можно расти бесконечно — появляются новые технологии, проблемы, продукты».

С точки зрения профессионального роста можно выделить следующие направления:
— Рост в размере и сложности решаемых проблем;
— Развитие в «ширину» — изучение большего количества технологий, процессов и методологий, инструментов, архитектурных подходов;
— Развитие знаний в предметной области — «Людей, которые могут кодить в мире технологических компаний — пруд пруди, и их не ценят. А те, кто может кодить в биологии, медицине, политике, социологии, физике, истории, математике — уважаемые люди, способные делать удивительные вещи для развития своих дисциплин». (Zed. A. Shaw)

«О перспективах этой профессии на рынке Украины могу сказать, что для Software Architect все только начинается. Судя по опыту предыдущих годов, еще 5 лет назад никто даже не догадывался, что такая профессия есть. Но еще 7 лет назад никто в Украине не понимал, зачем нужно платить за интернет ресурсы и их разработку — как можно заплатить за то, что нельзя пощупать? Точно так же и с архитекторами».

P.S. Отдельное спасибо за помощь в написание статьи Максиму Ковтуну и 18 другим украинским архитекторам, которые поделились с DOU таинствами своей профессии. Приведенные в статье цитаты взяты из их рассказов.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

Системный архитектор. Кто этот человек?

Для кого эта статья? Эта статья, также как и первая, рассчитана на людей, работающих в сфере ИТ. Для разработчиков, тестировщиков, менеджеров разного уровня, аналитиков и т.д. Для расширения кругозора, она также может быть полезна и всем остальным, просто, чтобы иметь представление о том, чем занимается Системный Архитектор. Пригодится материал и тем, кто планирует развитие своей профессиональной карьеры, и тем, кто выкладывает такого рода вакансию и ищет специалиста в команду.

Что еще? Думаю что надо как то договорится о подаче материала. Здесь, как и в первой статье, я рассмотрю конкретный пример из своей практики, который, как мне кажется, максимально точно иллюстрирует специфику работу данного специалиста. Как и раньше, в заключении, попробую ответить на следующие вопросы: кто такой Системный Архитектор, какими навыками должен обладать и т.д. Поехали?

И последнее, думаю, надо представится. Меня зовут Владимир Воловиков. Опыт работы в сфере разработки программного обеспечения более 20 лет. В должности Системного архитектора и Программного архитектора, в общей сложности, более пяти лет. Имею четыре международных сертификата. Текущее место моей работы Системный архитектор, Банк ВТБ.

Ускорим работу

По каким принципам разбивают Монолит на Микросервисы? Вариантов много разных, но самый очевидный по бизнес возможностям. Начало моей работы над проектом, это начало работы над информационной системой, которая была выделена из Монолита в Микросервис по вышеуказанному принципу. Ну, и конечно, если бы работа была сделана удачно, то и делать тут Системному архитектору было бы нечего. Но, как правило, это не так.

Чтобы продолжить, нужно читателю дать понять, что значит “удачно”. “Удачно” — это значит, что новая информационная система удовлетворяет всем заранее оговоренным атрибутам качества. Атрибутов качества много разных, но есть два базовых атрибута — это надежность и производительность. Что такое надежность? Это в общем-то вероятность работы вашей системы в случае различных нештатных ситуаций. Выключили свет, нет связи, пожар, землетрясение и т.д.. Проектирование высоконадежных систем, это в первую очередь все возможное резервирование: основная база данных, реплика, избыточность в рамках одного ЦОД, автоматическая система переключения основной базы данных на резервную, геораспределение и т.д. Все это было сделано, поэтому, эту часть я пропущу и перейду к производительности.

Производительность — это, то, какую нагрузку может выдержать ваш сервис. Какое количество запросов в секунду может обработать с надлежащей скоростью. И вот тут возникают вопросы. Дело в том, что при некоторых сценариях, производительность не удовлетворяет потребителей. А потребители кто?

Оказывается у вновь разрабатываемой системы два абсолютно разных потребителя. Первый потребитель это человек, пользователь. Это различные “фронт” приложения. Нагрузка 1-2 запроса в секунду максимум. А второй потребитель — это внутренние информационные системы. И вот, как раз во втором случае, производительность системы оказывается недостаточной. В данном сценарии нагрузка может достигать 100 и более запросов в секунду. Скорость ответа варьируется от 0,8 до 2 секунд. И что тут такого? Ну 2 секунды, не 20-ть. Что тут может не удовлетворять потребителя?

Чтобы читатель смог понять глубину проблемы, сделаю еще одно отступление. Представьте себе монолит. Представьте себе, например, интернет магазин и некий сценарий оплаты, который состоит из следующих этапов:

проверка наличие товара в конкретном магазине;
списание средств с карты пользователя;
резервирование товара;

Если бы мы писали программный код, как бы это все могло выглядеть?

if (Goods.available(shopId, userGoodsSelectedList)) < if (PaymentCard.getMoney(totalUserGoodsCost)) < if (Storage.reserved(shopId, userGoodsSelectedList ) < Response.send(INFO.GOODS_RESERVER); >else < Response.send(ERROR.GOODS_RESERVED); >> else < Response.send(ERROR.GET_MONEY); >> else

Мы видим три сущности: Goods, Payment, Storage. Каждая сущность имеет свои инкапсулированные методы и свойства. Как быстро все это будет работать? Да, мгновенно! Этот код весь в памяти. А теперь, давайте, сделаем из этого микросервисы. Разделим их по бизнес возможностям

Goods, Payments, Storage и PaymentsController — все это микросервисы, которые взаимодействуют друг с другом через HTTP интерфейс. Очевидно, что это медленнее, чем в случае с Монолитом. Уже есть накладные расходы. А что, если у нас взаимодействие не параллельное, как на схеме выше? Что если сервис, Goods, получив запрос от PaymentController, делает еще ряд таких же интеграционных запросов, например, получает дополнительную информацию о пользователях. Что если второй сервис, делает также запрос в некую третью систему. Сколько времени в целом будет затрачено на операцию? Пусть даже все блоки отработали со скоростью 0,5 мс. Три системы, умножив на 0,5 получаем 1,5 секунды. И вот в этой цепочке, кто-то решил, что может работать две секунды. “Ни айс” 🙂

Ну, что ж? Видим проблему, понимаем, откуда она взялась. Самое время заняться проектирование системной архитектуры. Дано:

Разделим “монолитный” микросервис на две части. Сделаем Микросервис для работы с внутренними потребителями и Микросервис для работы с внешними потребителями

Следующим шагом, нужно избавится или максимально исключить, количество интеграций в Микросервисе для внутреннего Потребителя. Вариантов тут два:

изучение бизнес-правил и их упрощение;
изменение архитектуры системы.

Что такое Бизнес-правила? Это, по сути, занесенные на бумагу правила, по которым работает бизнес. Это то, что отвечает на вопрос: ”Почему именно так работает, а не иначе?”. Приведу пример нескольких таких правил в разрезе нашего магазина

Номер

Описание

Для оформления заказа клиенту, сначала, необходимо произвести проверку наличия товара в указанном магазине, и только после нужно списать средства с карточки клиента и маркировать товар, как зарезервированный

Как только товар зарезервирован, необходимо отправить уведомление Менеджеру и Клиенту

Менеджер, получив уведомление о том, что Клиент зарезервировал товар, должен внести в График Доставки зарезервированный товар

Зарезервированный товар должен быть доставлен Клиенту не позднее, чем через 24 часа с момента резервирования

Функция формирования Графика Доставки зарезервированного товара должна быть доступна сотруднику с более высокой компетенцией и ответственностью

Изменение любого пункта из данного списка автоматически влияет на всю логику работы системы. Упростив БП1, вы автоматически уменьшите количество интеграций и, как следствие, система будет работать быстрей. Упростив БП5, ваша система будет проще. Не нужны будут ни какие Ролевые модели, создание AD групп и интеграций с этим сервисом. Будет работать надежнее.

Отлично. Мы изучили Бизнес-правила, и одно из них нам удалось упростить. Результат — на одну интеграцию стало меньше. Что будем делать с двумя оставшимися?

Что, если мы данные, за которыми ходим в эти сервисы, поместим к себе, внутрь нашего Микросервиса? В этом случае, делать интеграционные запросы нам уже будет не надо. Все будет у нас. Цена — избыточность информации. Мы ее понимаем и принимаем. Но как быть в случае, если информация изменится? У нас-то она останется старой. Нужна синхронизация. Давайте, попробуем рассмотреть различные варианты решения этого вопроса:

Интервальная синхронизация. Периодически, допустим, раз в сутки, производить запросы к Поставщикам информации и обновлять локальные данные.
Попросить Поставщиков информации отправлять нам уведомление о том, что информация изменилась.

В первом варианте, очевидно, что наша система будет производить неактуальные действия, основываясь на устаревшей информацией. Хорошо ли это? Системный архитектор не может на это ответить, ответ есть у бизнеса, и выглядит он как формирование и внедрение нового бизнес-правила. Принятие его. Например, вот такого

Номер

Описание

После изменения свойств товара оператором, изменение этих свойств на сайте должно появится не позднее 24 часов

Для реализации второго варианта, необходима доработка и нашего Микросервиса, и, возможно, сервиса Поставщика. Необходимо внедрение в архитектуру Шины Событий: Kafka, RabbitMQ и т.д.

В итоге, пусть один из наших сервисов, по разным причинам, не может работать с Шиной событий, а другой может. Итоговая картина будет выглядеть так как рисунке ниже

Теперь посмотрим на Базу данных. Что было, что стало? Идеология проектирования Микросервисов, это идеология инкапсулирования в одном месте логики, данных и команды. Изолированная зона ответственности. Давайте мысленно вспомним, что происходило с данными в результате наших манипуляций проделанных ранее

Единый Микросервис-монолит мы разбили на две части
Для каждого нового Микросервиса, мы выделили отдельную базу данных, по сути, сделав две ее копии
Базу данных Микросервиса для внутреннего потребления мы дополнили двумя таблицами: Данные от поставщика 1 и Данные от поставщика 2

Давайте, попробуем нарисовать Диаграмму сущностей и отношений опять же в разрезе нашего выдуманного интернет-магазина. Как было и как стало?

Стало, после разделения “монолитного” микросервиса на два

Стало, после добавление новых таблиц и уменьшения количества интеграций

Смотрим на то, что получилось и плачем. Решив одну проблему, мы породили целый ворох новых

Рассогласованность данных. Данные у Микросервиса для внешнего потребителя отличаются от данных у Микросервиса для внутреннего потребителя
Избыточность данных: по сути, две копии одного и того же
Отсутствует единый источник правды

Очевидно, что с таким багажом далеко не уедешь. Что то надо с этим делать? Вероятно, стоит попробовать перечислить все возможные варианты решения, дать оценку — поможет ли это в решении выявленных нами проблем или нет.

Физическая репликация

Первая идея состоит в том, чтобы настроить наши базы данных так, чтобы изменения данных в базе данных Микросервиса для внешнего потребителя, автоматические попадали в базу данных Микросервиса для внутреннего потребителя. Делается это настройками базы данных. Это отличное, простое и надежное решение, но это не наш случай. Наши базы данных отличаются друг от друга. Физическая репликация, это все же инструмент для организации надежности.

Логическая репликация триггерами

Вторая идея заключается в том, чтобы написать Триггер — хранимую процедуру. Триггеру, который вызывается при изменении каждой записи, доступно ключ этой записи, а также новое и старое значение. При необходимости триггер может сохранять новые значения строк в специальную таблицу, откуда специальный процесс на стороне реплики будет их вычитывать. В целом выглядит неплохо, но избыточность осталось. Плюс, какая-то сложность в разработке и отладке, возможно, есть варианты проще?

Прикладная репликация

Третья идея заключается в том, чтобы использовать уже заложенную в архитектуру шину событий. Сервер приложений Микросервиса для внешнего потребителя, после сохранения данных в своей базе данных, отправляет событие с данными через шину. Сервер приложений Микросервиса для внутреннего потребителя получает это уведомление и вносит изменение в свою базу данных. Тут тоже, как и в случае, с Логической репликацией триггерами присутствует избыточность и также есть какая-то дополнительная сложность в разработке. Более того, в случае, если кто-то сделает изменения прямо в базе, выполнив запрос, то синхронизации не будет. Это тоже нужно учитывать.

Схема с Прикладной репликацией с использованием шины данных

Общая база данных

И последняя идея заключается в том, чтобы сделать единую, общую базу данных для обоих наших микросервисов. Просто консолидировать ресурсы в одном месте. В некоторых случаях, это считается Антипаттерном, потому что противоречит основному принципу микросервисной архитектуре, а именно, инкапсуляции данных, ресурсов и т.д. в одном месте, в одной команде. В случае, если у нас два микросервиса разрабатываются двумя разными командами, но при этом, у них одна общая база данных, то автоматически возникают коллизии. Внесение изменения в эту базу, в ее структуру, будет также влиять на вторую команду. Но у нас одна команда и таких коллизий не будет, поэтому для нас это оптимальный вариант.

Итоговый вариант архитектуры ИС

Подведем итоги

Кто такой Системный архитектор?

Это специалист, который занимается проектированием архитектуры системы в целом для того, чтобы система могла обеспечить целевые показатели качества. Системный архитектор — специалист, способными вывести компанию на новый уровень бизнеса, выигрывать конкуренцию за счет разумного подхода и реинжиниринга процесса разработки.

Чем отличается Программный архитектор от Системного?

Область работы Программного архитектора — это программный код. Работа над архитектурой программного кода для того, чтобы работать над ним командой было просто. Для того, чтобы его можно было масштабировать и легко поддерживать. Системный архитектор, это, по сути, ступень выше. Системный архитектор манипулирует набором программных продуктов, в том числе, и системой, которую разработал Программный архитектор, как неким блоком, блоком, который выполняет определенную функцию. Комбинируя такие блоки, Системный архитектор строит информационную систему, которая способна выполнять бизнес-требования и соответствует нужным атрибутам качества.

Должен ли уметь программировать Системный архитектор?

Теоретически — нет. Путей ведущих к этой должности несколько. Одна из них через бизнес-аналитику. Другая — путь программиста. Может быть также путь Системного администратора. Но я лично не встречал Системного Архитектора, который не умел программировать или не программировал раньше.

Какими навыками должен обладать Системный архитектор?

Как бизнес аналитику, ему необходимо:

уметь внятно и точно выразить свои мысли
переложить их на бумагу
владеть несколькими UML нотациями, например, Диаграмма классов (Class Diagram) и Диаграмма деятельности (Activity Diagram), диаграмма последовательностей Sequence диаграмма. Возможно, также пригодиться Event Storming диаграмма
уметь выявлять бизнес правила (требования)

SOAP, REST, GRPC и т.д. Какие виды протоколов взаимодействия есть между системами. Плюсы, минусы, опыт работы с ними
Различные шины данных. Кеши и т.д. Также плюсы, минусы их
Какие базы данных существуют? Какие задачи решают? Репликация, шардирование и т.д.
Схемы построения надежности баз данных
Схема построения высоконагруженных систем

Сколько лет должно быть практики, чтобы быть Системным архитектором?

Если открыть список навыков, что был мной составлен на позицию Программного архитектора, то может показаться, что там список будет поболее. Но это только на первый взгляд. Системный архитектор — это опыт. С каким количеством баз данных вы работали? С какими протоколами? И если какие то навыки программный архитектор может получить самостоятельно, развернув один — два проекта, то развернуть экосистему с массой различных элементов, различных баз данных, различных протоколов, просто невозможно. Так сколько лет должно быть практики у Системного архитектора? Я бы смело добавил лет пять к тем значениям, что получились у Программного архитектора.

Заключение

Системный архитектор, это, безусловно, топ технической специальности. Это опыт, опыт и опыт. Это очень большой кругозор. И это уже конечно хорошо развитые “софт”- скилы. Без них уже никак. Как и что должно работать? Какие взаимодействия? Какая реакция системы? Как бизнес требования переложить в систему? Все это непростые навыки, развить которые, увы, невозможно ни на каких курсах

За помощь в подготовке данной статьи автор благодарит Балахчи Анну Георгиевну, Иркутский Государственный Университет, Факультет Бизнес-коммуникаций и информатики, зав.кафедры, кандидат физико-математических наук

разработка.
кодирование
teamlead
архитектор
architecture
паттерны проектирования
карьера программиста

Совершенный код
IT-инфраструктура
UML Design
Управление разработкой
Распределённые системы

Архитектор программного обеспечения

Архитектор программного обеспечения (системный архитектор, архитектор ПО, IT-архитектор) — специалист, который занимается построением сложных IT-систем для решения бизнес-задач. Системный архитектор хорошо разбирается в бизнес-процессах и видит, как можно решить бизнес-задачу с помощью разнообразных информационных технологий.
Проектирование ПО может включать применение и интеграцию широкого спектра продуктов, технологий и услуг, различных систем, приложений, оборудования и программного обеспечения. Как главный конструктор принимает решение, из каких деталей будет «собран» автомобиль, так архитектор программного обеспечения должен из доступных технологий сконструировать действующую IT-систему.

Например, к таким сложным системам относится интернет-банкинг. Если банк хочет предоставлять свои услуги не только в офисе, но и онлайн, то именно системный архитектор (а чаще и несколько архитекторов) продумывает, как разработать действующий онлайн-сервис для банка: настроить взаимодействие пользователей с банком через web-интерфейс, мобильные приложения, банкоматы, предусмотреть возможность не только снять и положить деньги на счет, но и сделать выписки, открыть вклад или взять кредит. В процессе проектирования сервиса системный архитектор должен предусмотреть удобство пользователя, простоту разработки, быстродействие, возможности масштабирования сервиса и безопасность финансовой информации. Данными вопросами будут заниматься уже разные специалисты – программисты, тестировщики, специалисты по информационной безопасности, UX-дизайнеры – но в проект, созданный архитектором, должны быть заложены будущие возможности для внесения изменений и развития.

Изучение предметной области для внедрения и/или разработки прикладных информационных систем
Изучает предметную область для внедрения и разработки прикладных информационных систем
Участвует в интервьюировании заказчиков, бизнес-экспертов и пользователей информационных систем на предмет изучения текущих принципов организации хода процессов
Изучает и систематизирует документацию по проекту
Готовит технические документы по описанию сущностей, взаимосвязей и процессов предметной области с использованием специальных нотаций
Участвует в постановке задач и разработке технического задания
Собирает, анализирует и документирует функциональные требования к программному обеспечению
Контролирует разработку
Участвует в подготовке схем тестирования функционала для выявления отклонений от сформулированных бизнес-требований и функциональных требований
Участвует в тестировании прототипа разрабатываемой системы
Участвует в обучении пользователей системы
Анализирует риски и причины возникновения ошибок при разработке системы

Где учиться

IT-специалисты считают, что для того, чтобы стать квалифицированным системным архитектором, необходимо начать свой путь с работы программиста. Только попробовав на практике различные технологии и языки программирования, решая прикладные задачи и разрабатывая сайты, можно приобрести бесценный опыт и видение бизнес-проблем.

Направления обучения:
Математика и механика (01.00.00)
Компьютерные и информационные науки (02.00.00)
Информатика и вычислительная техника (09.00.00)
Экономика и управление (38.00.00)

Московский Авиационный Институт (МАИ) Факультет № 3 «Системы управления, информатика и электроэнергетика», Факультет № 4 «Радиоэлектроника летательных аппаратов», Факультет № 8 «Прикладная математика и физика»
Московский Государственный Технический Университет «МАМИ» (МАМИ) Факультет автоматизации и информационных технологий
Московская академия рынка труда и информационных технологий (МАРТИТ) Кафедра прикладной информатики
Московский государственный технологический университет им. К.Э. Циолковского (МАТИ) Институт информационных систем и технологий
Московский государственный индустриальный университет (МГИУ) Институт информационных технологий и управления в технических системах
Московский государственный технический университет им. Н.Э. Баумана (МГТУ) Факультет «Информатика и системы управления»
Московский государственный технический университет гражданской авиации (МГТУ ГА) Факультет прикладной математики и вычислительной техники
Московский государственный технологический университет «Станкин» (МГТУ «Станкин») Факультет информационных технологий и систем управления
Московский государственный технический университет электроники и информатики (МИРЭА)
Национальный исследовательский ядерный университет «МИФИ» (МИФИ) Факультет экспериментальной и теоретической физики, Факультет кибернетики и информационной безопасности, Факультет очно-заочного обучения
Национальный исследовательский университет «МИЭТ» (МИЭТ) Факультет микроприборов и технической кибернетики, Факультет электроники и компьютерных технологий, Факультет прикладных информационных технологий
Московский технический университет связи и информатики (МТУСИ) Факультет информационных технологий
Московский государственный университет экономики, статистики и информатики (МЭСИ)
Национальный исследовательский университет «Высшая школа экономики» (НИУ ВШЭ) МИЭМ Факультет компьютерных наук
Московский государственный университет им. М.В. Ломоносова (МГУ) Факультет вычислительной математики и кибернетики
Московский физико-технический институт (университет) (МФТИ) Факультет инноваций и высоких технологий, Факультет нано-, био, информационных и когнитивных технологий, Факультет радиотехники и кибернетики, Факультет аэромеханики и летательной техники
Российский университет дружбы народов (РУДН) Факультет физико-математических и естественных наук
Российский университет транспорта (РУТ — МИИТ)
Московский технологический университет (МТУ (МИРЭА)) Факультет информационных технологий (ФИТ)
Российский государственный геологоразведочный университет имени Серго Орджоникидзе
Российская академия народного хозяйства и государственной службы при Президенте РФ (РАНХиГС
Государственный университет управления (ГУУ)
Российский экономический университет им. Г.В. Плеханова (РЭУ)
Московский энергетический институт (МЭИ)
Российский государственный гуманитарный университет (РГГУ)
Национальный исследовательский технологический университет «МИСиС»
Московская сельскохозяйственная академия им К.А. Тимирязева (РГАУ – МСХА)
Российский государственный университет нефти и газа имени И.М. Губкина
Московский педагогический государственный университет (МПГУ)
Национальный исследовательский Московский государственный строительный университет (МГСУ — МИСИ)
Финансовый университет при правительстве РФ (ФУ)
Московский финансово-юридический университет (МФЮА)
Российский новый университет РосНОУ
Московский государственный университет геодезии и картографии (МИИГАиК)
Московский технологический институт (МТИ)
Российский химико-технологический университет имени Д.И. Менделеева
Московский политехнический университет (Московский Политех)
Московский финансово-промышленный университет «Синергия»
Российский государственный социальный университет (РГСУ)
Московский государственный психолого-педагогический университет
Московский государственный университет технологий и управления им. К.Г. Разумовского (Первый казачий университет)
Московский государственный областной университет (МГОУ)
Московский государственный гуманитарно-экономический университет (МГГЭУ)
Белорусско-Российский университет
Государственный университет «Дубна»
Институт мировых цивилизаций (ИМЦ)
Российский университет кооперации (РУК)
Московский государственный психолого-педагогический университет

Где работать

Компании-разработчики (сервисы Booking.com, Mail.ru, Yandex, Unisender)
IT-отделы и отделы digital-маркетинга организаций (Сбербанк России, Газпром, Тинькофф банк)
Системные интеграторы (Крок, Softline, Техносерв, Ланит, Ай-Теко)

Кто такой системный архитектор и как им стать

Чем занимается системный архитектор, какими навыками и знаниями нужно обладать, чтобы им стать — рассказ практикующего специалиста.

Системный архитектор, он же главный инженер проекта (ГИП) — специалист, способный выстроить сложную ИТ-инфраструктуру под индивидуальные потребности заказчика. Разбираемся в тонкостях этой редкой профессии вместе с директором департамента системной архитектуры Rubytech Александром Палкиным.

Александр Палкин
директор департамента системной архитектуры Rubytech

Так же, как и в строительстве зданий, главная задача архитектора ИТ-инфраструктуры — спроектировать все так, чтобы конструкция была надежной, элементы идеально сочетались между собой и бесперебойно выполняли свои функции. Это ответственная работа, требующая глубокой экспертизы в ИТ и развитых управленческих навыков.

Цена ошибки здесь крайне высока. Уязвимости и сбои в ИТ-инфраструктуре крупных заказчиков могут привести к потере прибыли в миллиарды рублей, а в случае с нефтяными компаниями или производствами — и вовсе грозить экологической катастрофой. Системный архитектор — это важный человек, который предотвращает подобные сценарии еще на этапе планирования. Справиться с такой работой может только специалист с высоким уровнем квалификации.

Так как потребности у каждого бизнеса разные, универсальных алгоритмов и типовых кейсов на рынке практически нет — каждый проект уникален. И несмотря на кажущуюся монотонность, это по-настоящему творческая работа, в которой можно в полной мере реализовать свой потенциал.

Чем занимается системный архитектор

Системный архитектор подключается к проекту на этапе пресейла и полностью отвечает за всю техническую часть. Он участвует в разработке технико-коммерческого предложения, в деталях продумывает каждый элемент будущей системы. Он же и согласовывает концепцию проекта и «продает» ее заказчику — убеждает его в правильности и оптимальности каждого решения.

После подписания контракта системный архитектор выступает в роли технического руководителя проекта: собирает команду, распределяет роли и курирует все процессы вплоть до реализации инфраструктуры. Свою работу он ведет в тесном сотрудничестве с руководителем проекта, детально погружаясь в особенности ИТ-инфраструктуры заказчика и учитывая все специфические требования.

Где востребованы такие специалисты

Везде, где происходит цифровая трансформация, создаются мощные и комплексные ИТ-инфраструктуры. Например, в проектах для крупных госкорпораций, которые отличаются не только масштабом, но и высоким уровнем критичности и важности.

Чаще всего такие проекты реализуют силами системных интеграторов, в которых и работают системные архитекторы. В зависимости масштаба проекта, принимать участие в нем может как один, так и несколько системных архитекторов.

Ключевые навыки системного архитектора

Позиция подразумевает многолетний опыт работы. Поэтому одними только теоретическими знаниями здесь не обойтись. Необходимо понимать, как разные решения сочетаются между собой, где могут возникнуть проблемы, уметь досконально просчитывать риски. Важно видеть картину в целом, но при этом отлично знать каждую составляющую ИТ-инфраструктуры. Наработать это можно исключительно практикой. В случае с госсектором необходимо также учитывать требования, связанные с политикой импортозамещения, и ювелирно внедрять российские решения в уже работающие системы.

Нужны ли вашему проекту микросервисы? Вопросы, которые помогут разобраться

Помимо обширных знаний в ИТ, архитектор должен обладать рядом надпрофильных навыков или soft skills. В первую очередь — коммуникационных. Он должен грамотно формулировать свои мысли как письменно, так и устно. Ему предстоит много общаться заказчиками, вежливо, но настойчиво отстаивать свою точку зрения, ставить задачи и мотивировать команду. А в отдельных случаях — работать в связке с другими архитекторами.

Необходимо уметь планировать и проводить презентации, «продавать» свои идеи. Еще один важный навык — тайм-менеджмент, так как придется распоряжаться не только своим временем, но и грамотно распределять нагрузку внутри проектной команды.

Как стать системным архитектором

Поскольку должность подразумевает большой опыт работы с ИТ-инфраструктурой, системными архитекторами не становятся сразу после выпуска из университета. Выбирая это направление деятельности, важно понимать, что карьерный рост не будет стремительным. Зато специалисту гарантирована интересная работа в солидных и стабильных компаниях.

Так как найти на рынке готового профессионала с правильным бэкграундом и нужной экспертизой не так уж легко, интеграторы предпочитают развивать специалистов внутри своих компаний. Они активно вкладывают в обучение и всеми доступными средствами стараются удерживать талантливых и мотивированных сотрудников как можно дольше, чтобы эти инвестиции не пропали зря. Именно поэтому в известных ИТ-интеграторах обычно очень низкая текучка кадров.

Опыт Rubytech показывает: чаще всего системными архитекторами становятся сотрудники, которые начинали свою карьеру с должности эксперта-проектировщика. В некоторых компаниях их называют техническими писателями. И это не случайно, ведь проектирование документации — одна из ключевых функций специалистов по разработке системной архитектуры. Чтобы успешно реализовать масштабный проект, требуется его детальное описание. Оно включает обоснование выбора архитектуры каждого из предлагаемых решений и подробные инструкции по их эксплуатации для администраторов со стороны заказчика. Проектировщик занимается проработкой всех этих аспектов на уровне документации.

Параллельно он развивается по индивидуальной траектории — прокачивает свои знания и навыки под руководством старших наставников, проходит внутреннее и внешнее обучение и сертификацию у вендоров. Постепенно берет на себя все более сложные, творческие и ответственные задачи — из младшего эксперта становится старшим, затем — ведущим. Следующая ступень — уже системный архитектор.

Как долго ждать карьерного роста

Темпы роста у всех очень разные. Случается, что молодые специалисты с большими амбициями, резво стартовав, перестают развиваться на середине пути. А бывает — ровно наоборот. Например, в Департаменте системной архитектуры Rubytech, которым я руковожу, есть сотрудница, которая поначалу не демонстрировала впечатляющих карьерных результатов, просто аккуратно выполняла свою работу. А недавно — попала на большой и сложный проект, проявила самостоятельность, приняла несколько грамотных управленческих решений, показала высокий профессионализм и после медленного разгона совершила качественный профессиональный скачок.

В целом именно так и бывает — специалисты быстро вырастают на непростых проектах, которые обычно длятся не меньше года. За это время можно научиться многому и ярко проявить себя. Поэтому я советую молодым сотрудникам быть инициативными и искать для себя вызовы. Если на проекте легко и комфортно — значит, вы его переросли.

Что нужно знать и уметь на входе в профессию

Чтобы попасть на работу проектировщиком, нужно иметь представление о базовых понятиях и принципах построения ИТ-инфраструктуры, знать основных вендоров и разбираться в их продуктах. Необходимо иметь законченное техническое образование. Как и на любой должности в сфере технологий, нужно уметь читать и составлять документацию на русском на английском языке.

Но главное — иметь непреодолимое желание трудиться в сфере ИТ, способность быстро обучаться и усваивать огромные массивы информации. Внимание к деталям — еще один немаловажный фактор, без которого невозможна успешная работа в должности проектировщика.

Коротко о главном

Системный архитектор — значимый специалист в структуре системного интегратора, без которого невозможно построить ни одну ИТ-инфраструктуру.
Чтобы работать системным архитектором, необходимо иметь большой опыт и глубокие познания в ИТ.
Помимо этого, важно обладать отличными коммуникативными навыками, уметь проводить презентации и руководить командой.
До системного архитектора можно дорасти через позицию проектировщика, эксперта или инженера.
Быстрый рост обычно происходит на самых сложных проектах.