В этой статье, я бы хотел разобрать основную проблематику и сложность работы архитектора решений (коим являюсь) и попытаться дать ответы (в том числе и себе) - как решать сложившиеся проблемы.
Прежде чем мы перейдём к основной зоне конфликта (а как мне видится, она заключается в медианной позиции архитектора решений по отношению к бизнесу и к разработке), я бы хотел разъяснить, для тех кто не знает о ком идёт речь, кто же такие архитектора решений.
Приведу слайд из моего выступления для студентов ОмГУ приуроченного к конференции "Молодёжь третьего тысячелетия" за 2021.
Как любая модель, это дерево является значительным упрощением действительности. Реальные карьеры специалистов могут сильно отличаться и вполне можно стать Архитектором Решений из DevOps-a, Эксперта по предметной области, Руководителя Проекта или Системного/Бизнес аналитика. Просто мой путь шёл от разработки. Но почему возникает такая вариация возможностей? Ведь сложно представить, что топовым разработчиком мог бы стать менеджер по персоналу, особенно без соответствующих навыков. Ответ кроется в областях знаний и ветках навыков, которые нужны для работы Архитектора:
Как видите, здесь лежат не только технические навыки, но и во многом навыки из области менеджмента и аналитики. Вообще, моё мнение - хороший Архитектор Решений, в отличие от Системного Архитектора, например - это в первую очередь специалист с максимально вкачанным навыком системного мышления и коммуникативными навыками, но на практике Архитекторов решений можно условно разделить на тех, кто пришли из Разработки и на тех, кто пришли из Процесного Управления. Соответственно и фокус оценки того или иного решения будет смещаться либо ближке к коду/дальше от процессов, либо наоборот.
В реальности, от размера компании и зрелости её процессов, количество этих архитектурных ролей может как расти, так и уменьшаться. От небольших компаний, где нет острой необходимости в проработке корпоративной инфраструктуры, большой работы с процессами и тех. стэком - может вообще не быть отдельного архитектора, а все архитектурные функции будут решаться командой; до крупных компаний где количество уровней будет увеличиваться, например на текущем месте работы их 6 (Системный Архитектор -> Архитектор Решений -> Архитектор Программы -> Архитектор ИТ-Ландшафта -> Архитектор Сегмента -> Корпоративный Архитектор). И если архитектор системы концентрируется на проектировании и реализации изменений в ИТ-системе, контролем её изменений с точки зрения реализации (в коде), определением DevOps процессов и автоматизации CI/CD, то чем же в таком случае занимается Архитектор Решений?
Прежде чем мы ответим на этот вопрос, нам необходимо понять, а из чего вообще состоит архитектура решения?
Ответ несколько зависит от методологии, на основе которой строится архитектура компании, стартовой моделью, от которой идут современные фреймворки принято считать Модель Захмана - на мой взгляд она наиболее полно описывает слои любой информационной системы, но разрабатывалась эта схема достаточно давно и полное моделирование информационных систем в этой методологии занимает достаточно много времени, что на мой взгляд реализуемо только в Водопадной модели проектирования систем. Современные фреймворки отказались от части слоёв и архитектурных срезов, сконцентрировавшись на более существенных аспектах разработки современных систем и де факто, стандартом индустрии принято считать TOGAF. Он делит архитектуру любого решения на 4 архитектурных слоя:
- Слой Бизнеса
- Слой Данных
- Слой Приложений
- Слой Инфраструктуры
И архитектор решения, в рамках отдельного проекта занимается всеми уровнями архитектуры, а не только слоями разработки приложения и его данными. Из чего и вытекает первая проблематика - люди, которые реализовывают систему - не всегда понимают, что делает архитектор решений. Поскольку добрая половина работы скрыта за слоями Enterprise-архитектуры, а не понимание процессов бизнес уровня приводит к сопротивлению в изменениях системы на всех последующих слоях.
В идеале, Архитектор Решения должен очень хорошо понимать процесс разработки, на каких этапах какие стороны принимают участие:
1. Уметь составлять дорожную карту движения по проекту.
Например: допустим системе требуется реинжиниринг и сейчас мы готовимся переносить наше решение из IaaS ландшафта в CaaS с разделением отдельных компонент по функциональной принадлежности на отдельные сервисы, затем выходим на интеграцию с корпоративной MDM системой для синхронизации по справочникам, и только после этого уже ведём интеграции с другими ИТ-системами в контуре компании, параллельно оценивая необходимость прямых интеграций или выбирая решение в сторону той или иной шины данных, проведя оценку передаваемых данных.
2. Уметь оценить пересечение функционала систем в той предметной области, в которой он занимается проектированием. Например, если компания занимается проектированием решений в капитальном строительстве, то архитектор решений должен понимать этапы стройки, их проблематику, существующие решения на рынке, уметь проводить сравнительный анализ этих решений, понимать какие решения уже есть в контуре его компании, какие функции будет покрывать текущая разработка и в случае необходимости подсвечивать для топ.менеджмента пересечение по функционалу между системами.
3. Прорабатывать все выше перечисленные архитектурные слои для заинтересованных в проекте стейкхолдеров, а также следить за их согласованностью друг с другом. Если это довольно крупная компания, то в ней должны быть внутренние органы, согласование которых необходимо на выделение бюджетных средств для старта разработки или новых этапов работы по проекту. Обычно их называют Инвестиционные Комитеты (Количество управляющих бюджетом органов будет варьироваться от компании к компании, тут важно понимать основное, что есть кто-то, кто даёт бабки на весь будущий цирк). Для принятия инвестиционных решений комитет опирается на мнение тех.экспертов компании (чаще всего здесь будут представители Корп.Архитектуры или каких-то отдельных тех.экспертов, CTO например), если это довольно грамотно организовано, то появляется Архитектурный Комитет, который осуществляет надзор за стадиями работы по проекту и Архитектор Решения должен защищать принимаемые им решения в проекте перед комитетом. В зависимости от количества, а также видов стейхолдеров принимающих участие в арх.комитете и будет зависеть перечень срезов архитектуры, необходимый для защиты перед ними: (Далее приведу достаточно подробный список арх. срезов, имеющий пользу для понимания разных аспектов ИТ-системы как продукта. На примере моего проекта по поливу растений)
- Бизнес-цели проекта, Ожидаемые результаты от его внедрения, затрагиваемые Бизнес-Процессы в компании, Органзиационный объём по внедрению этих решений, Бюджет, Класс Надёжности и Степень важности проекта.
- Более детализированное описание целей и задач проекта, а также предлагаемых решений.
- Описание расположения решения в ландшафте компании (в зависимости от крупности компании, там может быть довольно много уровней детализации, как со структурной, так и с функциональной точки зрения). Для инфраструктурных и сетевых проектов, могут быть соответствующие схемы с детализацией.
- Если компания не сама занимается разработкой, а нанимает подрядчика (например компания Интегратор), то будет сформировано описание того как происходил выбор конкретного вендора, по каким критерями, какие были кандидаты и где их нашли.
- Модель с запланированными инф. потоками данных между вашим решением и другими. Уже на этапе проектирования нужно прикидывать, с какими системами в будущем, можно будет с интегрироваться для получения тех или иных данных. Обычно, здесь может помочь наличие хорошо проработанного бизнес-процесса, а ещё лучше, описанного в какой-то нотации, по типу BPMN - это сильно упрощает понимание полезности предполагаемых интеграций (можно посмотреть какие стадии бизнес-процесса покрывают те или иные системы и понять какими объектами они оперируют). На этом этапе также прорабатываются так называемые КМД, причём я здесь имею ввиду что-то вроде будущих DTO, которые будут детализрованы на следующих этапах проработки. Это довольно полезный взгляд на систему для менеджеров и корп. архитекторов, но разработчику это может дать лишь понимание того, какие системы есть в окружении.
- Для уже запланированных интеграций может быть проработана более детальная схема, на которой отражены конкретные DTO, сетевые протоколы транспортного/прикладных уровней, API, Схемы трансформации объектов и сценарии интеграций.
- Список используемых в решении технологий и продуктов, в разрезах СУБД, Файловых Хранилищ, Операционных Систем, Системных Платформ, Прикладных платформ, Клиентского ПО, Браузеров пользователей, библиотек бэка и фронта.
- С какими данными работает система, какие политики по работе с данными и обеспечению их качества. Какие виды отчётности нужны бизнесу по этой системы, исходя из этого будет понимание о том, какие нужны дашборды, аналитики и отчётная документация.
- Описание выбора конкретного ЦОД-а, количества ит-ландшафтов (с точки зрения хранения единиц развертки: HaaS, IaaS, Caas, PaaS; С точки зрения сетевых сегментов: DMZ (CDMZ,TDMZ), WAN, InfraNet и т.д.) и звеньев развертки (DEV, UAT, PREPROD, PROD, Аппробационный Контур).
- Логические схемы, с представлением системы уже на уровне контейнеров (если опираться на терминологию C4). По ней уже можно понять из каких конкретно сервисов, монолитов, БД, файловых хранилищ, портов, направлений коннекта и протоколов будет состоять система.
- Требования по инфраструктуре, количество серверов с описанием потребности в (RAM, CPU и Памяти, Tier-ы надёжности и т.п.).
- Требования по лицензированию, если ваша контора играет в белую :). В РФ, в последние 1.5 года есть общая политика по импортозамещению иностранного ПО для гос. компаний например.
- Соблюдение требований от ИБ, есть персональные данные, коммерческая тайна, доступ к системе из интернета, взаимодействие с каким-то специфичным оборудованием. В общем всё, что захотят увидеть представители ИБ.
- Анализ Рисков проекта (отдельная огромная область знаний)
- Оценка стоимости проекта, включающая в себя стоимости на консультации и привлечение специалистов, стоимость инфры, сопровождения ПО сервисом, закупку специального ПО и аппаратуры, поддержки подрядчика (если он есть) и т.д.
- Некое обобщающий список принятых решений, а также вопросов, которые требуют дальнейшей проработки.
Это что-то вроде усредненного списка разных архитектурных видений системы для разного рода безопасников (Информационная безопасность, Экологическая безопасность, Экономическая Безопасность), Специалистов по оценке рисков и специалистов по инвестициям, Корп. Архитекторов, Сервисных команд и Бизнес Аналитиков, Специалистов по работе с данными (Data Officers). Как видите, здесь почти ничего про разработку! Разве что диаграммы компонент "на кошках", так сказать, объяснят что и с чем мы интегрируем в системе.
Приведу ещё один бытовой пример для понимания:
Конечному электрику вторая схема даёт намного больше информации о системе, но такая детализация требует значительного времени (а такого уровня проработки на ранних стадиях нет) да к тому же она будет непонятна бизнесу.
Почему так происходит?
Архитектор Решений мыслит и работает на уровне требований к продукту, концепта технологий, Концептуальных моделей данных (КМД), Концептуальных интерфейсов, паттернов архитектуры, а системные архитекторы и разработчики мыслят на уровне конкретных задач, конкретных DTO, Физических Моделей Данных (ФМД), Паттернов Разработки.
Т.е. когда архитектор решений (АР) продумывает и согласовывает схему взаимодействия системы с окружающей действительностью - разрабу не всегда ясна конкретика, когда думает о потоках данных в разработке - то они будут много раз меняться, а в физ. представлении таблицы в БД будут денормализованы и выглядеть иначе, атрибутный состав сильно расширится. АР исходит из требований и политик компании, а они могут меняться и нужно обосновывать этот разрыв с реализацией. АР работает над тем, чтобы решение органично вписалось в ландшафт компании, бизнес же заинтересован в развитии экосистемы своего продукта, да и разрабам не понятна 80% артефактов порождаемых АР-ом.
По итогу имеем:
- Разрабу не понятна польза от Архитектора Решений;
- Архитектура Решения исходит на основе регламентов, правил и ландшафта, а реализация на основе бабок. По итогу имеем то, на что хватило средств;
- Руководители и Администраторы считают Архитектуру Решения формальностью необходимой для инвестиций в проект;
- АР в силу объёма решаемых задач не имеет возможность погружаться в задачи разработки (до уровня кода);
- Сроки целевой архитектуры не удовлетворят заказчика;
- Заказчик в целом не понимает ценности архитектуры.
В хорошем сценарии, при опытном АР, грамотном Руководителе Проекта и достатке ресурсов система реализуется в полном объёме. В плохом сценарии - система превращается в бесконечно транзитное решение, между MVP и Целевым Видением.
Что с этим делать?
- Регулярно синхрониться с разрабами системы и с руководителями проектов. Формат представления должен отличаться для технарей и для бизнеса. Делать особый фокус на сквозных схемах, от верхнего к нижнему уровням.
- Делать заготовки для Руководителей, с пояснениями зачем мы делаем это и почему эти этапы разработки важны, указывать в чём их ценность.
- Плотно вовлекать тех.лидеров от разработки в процесс архитектурного проектирования, это поможет митигировать риски на дальнейших этапах.
- Донести до руководителей проекта необходимость - вовлекать архитектора в как можно большее количество коммуникаций с бизнесом, для обоснования решений, корректировки требований к системе.
- Стараться быть главным пользователем и потребителем разрабатываемого продукта (это верно кстати не только для АР).
- Прорабатывать бэклог проекта как можно более детально и на как можно более далёкую перспективу. Это поможет в формировании бюджета и отслеживании прогресса.