Предисловие
Отрасль ИТ уже перестает быть загадочным миром. Большинство людей, даже не работающих в этой сфере, имеют общее представление о том, чем занимаются люди разных наиболее популярных профессий. Аналитики прорабатывают требования к программному обеспечению, разработчики по этим требованиям пишут код, тестировщики проверяют, как этот код работает. Конечно, если мы начнем уходить чуть‑чуть в детали, то скажем, что аналитики то бывают разные: может быть бизнес‑аналитик, а может быть системный. Разработчик может писать «бэкенд», а может «фронт». Тестировщик может проверять в ручную, а может писать автотесты, то есть программы, которые будут проверять другие программы. Однако еще есть профессии, которые люди, даже работающие в ИТ, не до конца понимают и не знают в чем обязанности данного специалиста, и как устроен его день. Одной из таких профессий является архитектор, а именно архитектор решений (Solutions architect). Часто сталкиваюсь с разными заблуждениями о том, кто он такой, чем занимается и что должен знать и уметь. Поэтому в этой статье я постараюсь сформировать у читателя общее представление о профессии, ответить на основные вопросы и развеять заблуждения о ней.
С чего я взял, что могу рассказать что-то полезное?
Меня зовут Харкевич Иван, на текущий момент я занимаю позицию архитектора стрима (департамента) в одном из крупных российских банков. Имеют опыт работы на разных позициях во многих проектах, а также являюсь одним из основателей развивающегося ИТ-стартапа.
В этой роли я относительно недавно, чуть больше двух с половиной лет. И одной из основных проблем, с которыми я столкнулся в начале пути, было отсутствие полноценного понимания карты навыков этой роли и направления(-ий), куда мне надо развиваться. В данной статье я постараюсь приоткрыть завесу, кто же такой архитектор решений, какие знания ему требуются и как обычно устроен его день.
Материал в первую очередь для начинающих специалистов в области ИТ, а также тех, кто только начинает свой путь в качестве архитектора или думает им стать. А может Вам просто хочется разобраться в вопросе, тогда эта статья тоже для Вас. Материал написан на основании моего личного опыта и наблюдений. Буду рад обсудить с вами Ваш мысли и ответить на вопросы в комментариях к статье.
Кто же все таки такой этот Архитектор решений?
Для начала надо отметить, что существует много типов роли архитектора: технический архитектор, архитектор приложений, архитектор решений, корпоративный архитектор, архитектор данных, архитектор облачных решений, архитектор инфраструктуры. Все эти названия вы можете встретить в описании вакансий. Проблема только в том, что очень часто люди путают эти роли между собой или смешивают несколько в одну. Я не буду подробно останавливаться на этом вопросе, который станет темой моей другой статьи. Сейчас же мы с Вами подробно разберем только роль архитектора решений.
Архитектор решений, как это принято говорить, является мостом между бизнесом и разработкой. Поэтому требуется не только быть экспертом в технических вопросах, но и понимать бизнес составляющую, а именно продукт, клиентский путь, бизнес-процесс, законодательные ограничения и т.д. На выходе главная задача архитектора решений это спроектировать архитектуру максимально удовлетворяющую потребности бизнес-заказчика. Важно сказать, что таких специалистов целесообразно привлекать на достаточно крупные проекты: в начинающем стартапе они просто-напросто не принесут никакой пользы.
Одно из главных заблуждений об этой роли заключается в том, что архитекторы “по локоть” в программном коде или что они постоянно взаимодействуют с технологиями. Это абсолютно не так! Большинство представителей этой профессии никогда не программируют и не взаимодействуют с технологиями, которые используются для реализации решений. По большому счету основные инструменты, которыми ежедневно пользуется архитектор это:
корпоративный вики и трекер задач. Например, Confluence и Jira;
какое-нибудь средство для рисования схем. Например, Microsoft Visio, draw.io или diagrams.net;
также во многих крупных организациях используются средства проектирования, такие как SAP PowerDesigner, iServer.
А что же они тогда делают, черт возьми?!
В первую очередь архитектор решений ответственен за то, чтобы понять требования бизнес-заказчика: понять их цели и задачи, их “боли”, понять клиентский путь, выяснить нормативные ограничения и нефункциональные требования. Для этого требуется умение общаться с людьми, так как общаться приходится очень и очень много. Ведь на сборе требований работа не заканчивается, а только начинается. Ведь после наступает этап проектирования. Проектирование решений в крупных компаниях никогда не выполняется исключительно одним человеком. Постоянно надо привлекать технических архитекторов, архитекторов данных, экспертов информационной безопасности, аналитиков, разработчиков и других специалистов, которые обладают более глубокой экспертизой: каждый в своем вопросе. И ведь со всеми необходимо провести встречу, а то и несколько. Также ключевым навыком здесь выступает умение задавать правильные вопросы, чтобы максимально точно сформировать контекст и понимание вопроса.
Результатом процесса проектирования должна стать архитектура решения. И это не какая‑то одна «схемка», как можно подумать. Это комплексный документ, описывающий реализацию на разных уровнях и с разных точек зрения. Важно! Состав скорее всего будет отличаться в зависимости от требований конкретной организации. То, что принято включать в одном компании, в другой назовут «бредом». Я же просто приведу наиболее широкий список того, что может входить в итоговый документ:
контекстная или концептуальная архитектура. Обычно это диаграмма, которая отражает верхнеуровневую реализацию: какие системы и приложения участвуют в решении, как они взаимодействуют и зачем. А также отражаются пользователи, их роли и их взаимодействия с приложениями;
схема взаимодействия. Это более детальная архитектурная схема, включающая в себя конкретные компоненты систем и направления, способы и протоколы взаимодействия между ними;
описание API (Application Programming Interface) сервисов, которое содержит описание способа интеграции, модель передаваемых данных, а также SLA (Service Level Agreement);
модель данных, например, с использованием нотации UML Class;
описание программного и аппаратного обеспечения, с требованиями к лицензиям и “мощностям”;
сетевая архитектура. Также обычно представляется в виде схемы, описывающей используемые сетевые узлы, их адреса и расположение, протоколы и порты для взаимодействия;
все это в идеале должно сопровождаться ADR (Architecture Decision Record), которые отражают причины, плюсы/минусы принятых архитектурных решений.
А что надо знать?
Технологии
Не смотря на то, что архитектор решений, как правило, не программирует и не реализует ничего «руками», ему все равно требуется отличное понимание технологий, их плюсов/минусов и возможностей. Поэтому, как правило, на эту позицию часто ищут людей с богатым опытом в разработке, которые успели поработать на разных позициях, в разных проектах, имеют опыт работы с различными технологиями и архитектурами. Итак, что же это за технологии? Кратко перечислю их основные категории с несколькими примерами для каждой:
Языки программирования: Java, Kotlin, JavaScript;
Средства интеграции: синхронные протоколы (REST, gRPC и тд) и брокеры сообщений (RabbitMQ, Apache Kafka и тд);
Базы Данных: реляционные (MySQL, PostgeSQL и тд) и нереляционные/NoSQL (MongoDB, Apache Cassandra, Neo4j и тд);
Инструменты отслеживания изменений данных (CDC): Debezium, Yandex Data Transfer;
Средства мониторинга и логирования/журналирования: Zabbix, Sentry;
Инструменты контейнеризации: Docker, Kubernetes, Istio (Service Mesh);
Балансировщики нагрузки и прикладные шлюзы: F5 Load Balancer, NGinx, WSO2;
Это далеко не полный список категорий и самих технологий. Конечно невозможно знать все, и не факт, что каждое знание понадобится. Может получиться и так, что архитектор вообще не будет сталкиваться с вопросами о выборе языка программирования или балансировщика нагрузки. Тем не менее это формирует некую необходимую базу для понимания, как устроены современные корпоративные приложения в целом.
Паттерны
Конечно же мало знать только технологии. Надо уметь их правильно применять! С этой проблемой помогут архитектурные паттерны(рекомендации к решению типовых задач). Еще их также называют шаблонами. На просторах интернета можно найти великое множество статей и книг, описывающих различные паттерны. Я лишь снова укажу основные категории и несколько примеров для каждой из них:
архитектурные стили: монолит, микросервисы, SOA;
стили и шаблоны интеграции: удаленный вызов, обмен сообщениями, вызов точка‑точка, публикация‑подписка;
шаблоны надежности и устойчивости: балансировка нагрузки, георезервирование, масштабирование;
имплементация бизнес‑логики: событийная архитектура, Saga;
общие шаблоны проектирования: DDD (Domain Driven Design), MDA (Model Driven Architecture);
отраслевые стандарты: TOGAF, BIAN (являются скорее фрейворками и нельзя назвать паттернами, но не хотелось делать отдельный раздел).
Нотации
Последнее, на чем хочется кратко остановиться, это нотации языков моделирования. Повторюсь, что в ежедневной работе, архитектор решений постоянно работает с диаграммами и схемами. Приходится как рисовать, так и читать чужие. Зачастую для их подготовки используются различные нотации. Среди самых распространенных можно выделить: Archimate, UML, BPMN, Data Flow Diagram, C4 Model (хотя формально это не нотация, а именно модель).
И как тогда выглядит рабочий день?
Допустим стало примерно понятно, зона ответственности архитектора решений и какими навыками он должен обладать. Но все еще непонятно, чем же он целый день занимается.
Вопреки распространенным романтическим представлениям обычный набор задач многим может показаться скучным. Также важно отметить, что рабочий день может сильно отличаться от компании, от того, на скольких проектах задействован архитектор, и на каких стадиях эти самые проекты находятся. Далее приведены цифры, сформированные на основании опыта моего и нескольких моих коллег и знакомых.
Около 50% уходит на встречи. Как я и описывал ранее, встречи проходят постоянно как по бизнес, так и по техническим вопросам. Бывают дни, а то и недели, когда первая встреча начинается в 9 утра, а последняя заканчивается в 6 вечера, а то и позже.
Еще 25% времени архитектора занимает работа с документацией. Сюда входит и чтение и проверка схем и документов, а также конечно архитектор и сам готовит большое количество документов, презентаций и архитектурных диаграмм. Порой может уйти несколько часов на выбор вида стрелочек и цвета кубиков на схеме...
До 10% времени может уходить на административные задачи, среди которых переписки в почте, назначение и управление задачами в Jira, подготовка разных отчетов и т. д. Да‑да, и архитекторы тоже должны всем этим заниматься.
Около 5% может уходит на «тушение пожаров». Под этим имеется ввиду участие в разборе «багов» и поиске способов их устранения. Зачастую именно наличие комплексного понимания у архитектора, как все устроено, дает ему возможность предложить наиболее оптимальное решение.
5% уходит на самообразование. Сюда входит изучение различных статей как на просторах интернета, так и во внутренней «вики» организации, прохождение курсов, чтение книг. Это критически необходимо для того, чтобы иметь возможность предлагать наиболее оптимальные и актуальные решения, выявлять технические долги приложения и качественно выполнять все остальные свои задачи. Маленькое примечание: тут речь только про рабочее время, которое тратится на решение рабочих задач. Никто не запрещает читать техническую литературу в свободные вечера или на выходных.
Для последних 5% напишу скорее мое желание и рекомендацию для начинающих специалистов. Оставшееся время я стараюсь тратить на передачу экспертизы своим коллегам: пишу информационные и учебные статьи на корпоративном вики, готовлю различные чек‑листы для упрощения работы команд, провожу митапы и воркшопы. Зачем заниматься таким альтруизмом? Ничего подобного! Эти казалось бы незначительные 5% на длинной дистанции позволяют экономить кучу времени архитектора. Ведь вместо того чтобы на очередной встрече отвечать на одни и те же вопросы 10-му человеку подряд, архитектор может дать ссылку на материал и позже просто ответить на парочку оставшихся вопросов. Более того, все это позволяет с гораздо меньшей болью при необходимости делегировать свои обязанности на других специалистов.
Звучит как то скучно…
Может показаться, что это скучная работа. На деле это абсолютно не так! Архитекторы ежедневно сталкиваются с множеством разнообразных задач и вопросов, для решения которых приходится выходить за рамки своего мышления. Даже имея за плечами большой опыт в этой роли человеку приходится постоянно развиваться: изучать новое и повторять хорошо забытое старое. От проекта к проекту меняются технологии, подходы, условия, ограничения и требования. Кто‑то скажет, что базовые архитектурные паттерны остаются неизменными для любого проекта. И я даже соглашусь с этим. Но дьявол, как всегда в деталях, господа. А детали то всегда разные.
Поэтому, если Вы начинаете свой путь в качестве архитектора решений или только думаете о том, чтобы им стать, то как минимум в одном вы можете не сомневаться — Вас ждет захватывающий путь!
Спасибо!
Спасибо Вам за потраченное время! Надеюсь мне удалось составить более четкую картинку того, кто такой архитектор решений и чем он занимается.
Буду рад Вашей обратной связи по поводу статьи в комментариях!
