Как стать архитектором ПО в 2023 году

IT-архитектор — это проектировщик, который принимает ключевые решения по проекту. В банковской сфере IT-архитектору приходится строить сложные системы, учитывая такие особенности, как работа с большим количеством пользователей и объёмами данных.

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

Владимир Григорьев

Эксперт по архитектуре Газпромбанка

1. Специализации и задачи IT-архитектора
2. С какими областями знаний работает IT-архитектор
3. Что должен знать архитектор ПО
4. Софт-скилы ИТ-архитектора
5. Опыт — это проработка гипотез

Специализации и задачи IT-архитектора

В IT-архитектуре много направлений: enterprise, solution, system, data-архитектура. У каждой специализации свои особенности, которые в том числе зависят и от стека конкретной компании. Поэтому не так просто собрать универсальный пул навыков и технологий, подходящий любому IT-архитектору.

В больших компаниях задачи диверсифицированы по специалистам.

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

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

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

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

Что почитать: блог Мартина Фаулера про архитектуру ПО

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

С какими областями знаний работает IT-архитектор

Чтобы грамотно выстраивать проект, ИТ-архитектор в банке должен понимать, как устроены эти области знаний:

1. Реализация бэкенда. Где хранить данные, как к ним обеспечить доступ.
2. Реализация фронтенда. Работа с клиентом, интернетом, каналами.
3. Интеграционная архитектура. Возможности интеграции, как обеспечивать взаимодействие между системами, не положив ни одну из них.
4. Безопасная архитектура. Как правильно обеспечить взаимодействие клиентов, быстро проводить идентификацию, авторизацию клиента.
5. Использование MDM. Это системы, которые будут хранить мастер-данные по необходимым для проекта сущностям (данные клиентов, продуктов и т. д.).
6. Реализация справочников. Важно правильно распространять по своим сервисам справочную информацию.
7. Монолитная, сервисная и микросервисная архитектуры. Как они устроены, в чём разница, плюсы и минусы подходов.

Analysis Patterns: Reusable Object Models

Читать

Высоконагруженные приложения. Программирование, масштабирование, поддержка

Купить

Создание микросервисов

Читать

Что должен знать архитектор ПО

Архитектурный фреймворк TOGAF

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

Примечание 1Если при выходе из строя n-компонента система продолжает полноценно функционировать, то её можно считать устойчивой. N — величина динамическая и может изменяться в зависимости от критичности систем.

Примечание 2Если при увеличении нагрузки система так же качественно отрабатывает запросы, то её можно считать высокопроизводительной. Для банков этот параметр очень важен, ведь предусмотреть действия клиентов возможно далеко не всегда.

Бизнес-требования

IT-архитектор должен разработать технический сценарий реализации бизнес-задачи.

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

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

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

Важный момент, IT-архитектор также должен проанализировать и определить потенциальные изменения, чтобы при интеграции новой системы с другими системами не произошло сбоя. Нужно уточнять у бизнеса: «Если изменятся, например, фамилия клиента или поле в паспорте, это критично?». Если да, то всё заносится в бизнес-требования.

Техническая проработка

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

ИТ-архитектор указывает, какие технологии, фреймворки используются в задаче, на чём написано приложение. Мы в Газпромбанке пишем на Java. Но бывают коробочные решения, которые требуют дополнительного внимания. Например, сервис на REST придётся серьёзно переписывать, чтобы вызывать SOAP.

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

Архитектор учитывает требования безопасности. По сути, это контроль вызовов: кто вызывает сервис, а кто является вызываемым. Если компрометирующий сервис «А» знает, как вызвать сервис «Б» из защищённой системы, то вся система перестаёт быть защищённой. Тогда нужно прописать, что сервис «Б» должен вызывать сервис «А» из доверенной зоны и возвращать данные по своим каналам.

Также важно понимать, какие данные передаются в этом потоке: только общедоступная информация или ещё и персональная. Если уровень критичности этих данных высок, то нужно принять дополнительные меры по их сохранности, например, выстраивание DMZ (более защищённых зон) для работы с ними.

Архитектура данных

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

Базы данных

В начале 2000–х были две–три основных базы данных: Oracle, MySQL. Сейчас появляется множество новых реализаций: колоночные, документоориентированные, key-value БД. Их назначение примерно одинаковое — они хранят данные, но подходы к записи, чтению, масштабированию у них абсолютно разные.

Нужно понимать, какие существуют базы данных и какая между ними разница, что они позволяют делать, почему при использовании реляционных БД не всегда можно достичь большего профита. Например, если нет потребности в ACID (Atomicity, Consistency, Isolation, Durability), то можно рассмотреть NOSQL БД. Это даст возможность записывать большие объёмы данных в БД, к тому же масштабировать хранилище будет проще, чем при использовании реляционной БД.

Что почитать по теме:Как разобраться в видах СУБД
NoSQL базы данных
Популярные реляционные базы данных

Интеграция

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

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

Кого почитать: Максим Смирнов о сценариях интеграции приложений

Паттерны проектирования

Event-driven архитектура

Это удобный паттерн с большими функциональными возможностями: одно и то же событие могут принимать сразу несколько сервисов, по-разному на них реагируя. Здесь нет сильной связности между поставщиком и потребителем, они существуют автономно. Как маршрутизатор событий тут актуален Kafka.

Материалы по теме:
Что такое EDA и как для её построения использовать KafkaЧто такое Kafka и как начать с ним работу

Domain-driven design (DDD)

В этом случае все данные делятся на домены. Здесь нужно на ранней стадии спроектировать систему так, чтобы не допустить протекания доменов.

Подходы domain-driven design очень актуальны в больших компаниях. Если заранее не «нарезать» предметную область и не определить основные сущности этих доменов, то со временем данные могут задублироваться в разных частях системы, и синхронная актуализация этих данных вызовет трудности.

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

GitHub про DDD: книги, видео, комьюнити, обучающие курсы.

Onion-архитектура

При проектировании системы за основу берётся независимый Core-уровень, на который накладывается второй, уже зависимый от первого. На второй уровень накладывается третий, который зависит от второго и так далее. При таком подходе верхний UI-слой не сможет управлять Core-уровнем или ходить напрямую в бэкенд, обходя сервисный слой.

Подход CQRS

CQRS (Command and Query Responsibility Segregation) — это парадигма, при которой операции записи отделены от операций чтения. Она необходима, когда нагрузка на чтение и запись данных распределена несимметрично. Например, когда большая часть бизнес-логики и сложных проверок приходятся на write-систему, а чтение данных происходит чаще, чем вставка изменений.

Также почитайте о плюсах и минусах паттерна CQRS.

Инструменты визуализации решений

• Бизнес-вижн прописывается с помощью BPMN-подходов моделирования.
• Для построения архитектурных схем можно использовать UML или Archimate нотации. Мы используем Visio, либо аналог Visio (draw.io).

Описание движения сущности в информационной архитектуре.

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

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

Софт-скилы ИТ-архитектора

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

При этом также важны умение работать в команде и лидерские качества. Нужно доносить важность проекта до разработчиков: уметь мотивировать, находить к ним подходы, объяснять важность задач и правильно ставить их приоритетность.

Как пасти котов. Наставление для программистов, руководящих другими программистами

Купить

Нужно развивать критическое мышление. В этом помогает концепция helicopter view: быть больше своих задач, смотреть выше. Это даёт более объёмную картину устройства проекта. Нужно анализировать, какой у задач бизнес-эффект, какой эффект будет при интеграции с другими сервисами продукта. Чем выше ты смотришь, тем больше вопросов себе задаёшь: действительно ли здесь нужно сделать именно так, или можно по-другому.

Опыт — это проработка гипотез

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

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

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