Предисловие
Отрасль ИТ уже перестает быть загадочным миром. Большинство людей даже не работающих в этой сфере имеют общее представление о том, чем занимаются люди разных наиболее популярных профессий. Аналитики прорабатывают требования к программному обеспечению, разработчики по этим требованиям пишут код, тестировщики проверяют, как этот код работает. Конечно, если мы начнем уходить чуть‑чуть в детали, то скажем, что аналитики то бывают разные: может быть бизнес‑аналитик, а может быть системный. Разработчик может писать «бэкенд», а может «фронт». Тестировщик может проверять в ручную, а может писать автотесты, то есть программы, которые будут проверять другие программы. Однако еще есть профессии, которые люди, даже работающие в ИТ, не до конца понимают и не знают в чем обязанности данного специалиста, и как устроен его день. Одной из таких профессий является архитектор, а именно архитектор решений (Solutions architect). Часто сталкиваюсь с разными заблуждениями о том, кто он такой, чем занимается и что должен знать и уметь. Поэтому в этой статье я постараюсь сформировать у читателя общее представление о профессии, ответить на основные вопросы и развеять заблуждения о ней.
С чего я взял, что могу рассказать что-то полезное?
Меня зовут Харкевич Иван, на текущий момент я занимаю позицию архитектора стрима (департамента) в одном из крупных российских банков. Имеют опыт работы на разных позициях во многих проектах, а также являюсь одним из основателей развивающегося ИТ-стартапа.
В этой небольшой статье я постараюсь приоткрыть завесу, кто же такой архитектор решений, какие знания ему требуются и как обычно устроен его день.
Данный материал в первую очередь для начинающих специалистов в области ИТ, а также тех, кто только начинает свой путь в качестве архитектора или думает им стать. А может Вам просто хочется разобраться в вопросе, тогда эта статья тоже для Вас. Материал написан на основании моего личного опыта и наблюдений. Буду рад обсудить с вами Ваш мысли и ответить на вопросы в комментариях к статье.
Кто же все таки такой этот Архитектор решений?
Для начала надо отметить, что существует много типов роли архитектора: технический архитектор, архитектор приложений, архитектор решений, корпоративный архитектор, архитектор данных, архитектор облачных решений, архитектор инфраструктуры. Все эти названия вы можете встретить в описании вакансий. Проблема только в том, что очень часто люди путают эти роли между собой или смешивают несколько в одну. Я не буду подробно останавливаться на этом вопросе, который станет темой моей другой статьи. Сейчас же мы с Вами подробно разберем только роль архитектора решений.
Архитектор решений, как это принято говорить, является мостом между бизнесом и разработкой. Поэтому требуется не только быть экспертом в технических вопросах, но и понимать бизнес составляющую, а именно продукт, клиентский путь, бизнес-процесс, законодательные ограничения и т.д. На выходе главная задача архитектора решений это спроектировать архитектуру максимально удовлетворяющую потребности бизнес-заказчика. Важно сказать, что таких специалистов целесообразно привлекать на достаточно крупные проекты: в начинающем стартапе они просто-напросто не принесут никакой пользы.
Одно из главных заблуждений об этой роли заключается в том, что архитекторы “по локоть” в программном коде или что они постоянно взаимодействуют с технологиями. Это абсолютно не так! Большинство представителей этой профессии никогда не программируют и не взаимодействуют с технологиями, которые используются для реализации решений. По большому счету основные инструменты, которыми ежедневно пользуется архитектор это:
Microsoft Word, Excel и PowerPoint;
корпоративный вики и трекер задач. Например, Confluence и Jira;
какое-нибудь средство для рисования схем. Например, draw.io или diagrams.net;
также во многих крупных организациях используются средства проектирования, такие как SAP PowerDesigner, iServer, Microsoft Visio.
А что же они тогда делают, черт возьми?!
В первую очередь архитектор решений ответственен за то, чтобы понять требования бизнес-заказчика: понять их цели и задачи, их “боли”, понять клиентский путь, выяснить нормативные ограничения и нефункциональные требования. Для этого требуется умение общаться с людьми, так как общаться приходится очень и очень много. Ведь на сборе требований работа не заканчивается, а только начинается. Ведь после наступает этап проектирования. Проектирование решений в крупных компаниях никогда не выполняется исключительно одним человеком. Постоянно надо привлекать технических архитекторов, архитекторов данных, экспертов информационной безопасности, аналитиков, разработчиков и других специалистов, которые обладают более глубокой экспертизой: каждый в своем вопросе. И ведь со всеми необходимо провести встречу, а то и несколько. Также ключевым навыком здесь выступает умение задавать правильные вопросы, чтобы максимально точно сформировать контекст и понимание вопроса.
Результатом процесса проектирования должна стать архитектура решения. И это не какая‑то одна «схемка», как можно подумать. Это комплексный документ, описывающий реализацию на разных уровнях и с разных точек зрения. Важно! Состав скорее всего будет отличаться в зависимости от требований конкретной организации. То, что принято включать в одном компании, в другой назовут «бредом». Я же просто приведу наиболее широкий список того, что может входить в итоговый документ:
контекстная или концептуальная архитектура. Обычно это диаграмма, которая отражает верхнеуровневую реализацию: какие системы и приложения участвуют в решении, как они взаимодействуют и зачем. А также отражаются пользователи, их роли и их взаимодействия с приложениями;
схема взаимодействия. Это более детальная архитектурная схема, включающая в себя конкретные компоненты систем и направления, способы и протоколы взаимодействия между ними;
описание 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;
Это далеко не полный список категорий и самих технологий. Конечно невозможно знать все, и не факт, что каждое знание понадобится. Может получиться и так, что архитектор вообще не будет сталкиваться c вопросами о выборе языка программирования или балансировщика нагрузки. Тем не менее это формирует некую необходимую базу для понимания, как устроены современные корпоративные приложения в целом.
Паттерны
Конечно же мало знать только технологии. Надо уметь их правильно применять! С этой проблемой помогут архитектурные паттерны(рекомендации к решению типовых задач). Еще их также называют шаблонами. На просторах интернета можно найти великое множество статей и книг, описывающих различные паттерны. Я лишь снова укажу основные категории и несколько примеров для каждой из них:
архитектурные стили: монолит, микросервисы, 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-му человеку подряд, архитектор может дать ссылку на материал и позже просто ответить на парочку оставшихся вопросов. Более того, все это позволяет с гораздо меньшей болью при необходимости делегировать свои обязанности на других специалистов.
Звучит как то скучно…
Может показаться, что это скучная работа. На деле это абсолютно не так! Архитекторы ежедневно сталкиваются с множеством разнообразных задач и вопросов, для решения которых приходится выходить за рамки своего мышления. Даже имея за плечами большой опыт в этой роли человеку приходится постоянно развиваться: изучать новое и повторять хорошо забытое старое. От проекта к проекту меняются технологии, подходы, условия, ограничения и требования. Кто-то скажет, что базовые архитектурные паттерны остаются неизменными для любого проекта. И я даже соглашусь с этим. Но дьявол, как всегда в деталях, господа. А детали то всегда разные.
Поэтому если Вы начинаете свой путь в качестве архитектора решений или только думаете о том, чтобы им стать, то как минимум в одном вы можете не сомневаться - Вас ждет захватывающий путь!
Спасибо!
Спасибо Вам за потраченное время! Надеюсь мне удалось составить более четкую картинку того, кто такой архитектор решений и чем он занимается.
Буду рад Вашей обратной связи по поводу статьи в комментариях!
