«Эти архитекторы делают непонятно для кого», «Я тут в Miro накидал», «Нарисуй там что-нибудь архитектурное, а то мы уже код пишем» – знакомо?

Привет! Меня зовут Ущаповский Антон, я архитектор решений в МВС ИИ, последние несколько лет активно погружаюсь в различные аспекты разработки ПО и в ИТ-архитектуру, в частности. Как следствие, накопилось некоторое количество повторяющихся «болей», которые встречаю из раза в раз и наблюдаю их на регулярной основе практически на каждом ИТ-продукте.

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

Непонимание задачи решаемой архитектурой

Рисуй давай, зря что ли архитектора взяли.

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

Сами потребители не знают что хотят, пробуют выразить свое желание через фразу «Нарисуй мне архитектуру». На вопрос «Какую именно?», могут растерянно ответить «Техническую» или «Логическую», а вот попытка выяснить какую технику или логику там хотят увидеть, а главное зачем, уже вызывает заметные сложности.

Работа над архитектурой – это такой же важный шаг в разработке ПО, как и написание кода. Вы получаете артефакт, где описывается разница между AS IS и TO BE состояниями вашего ИТ-продукта, а также способ перехода в TO BE (включая не только саму разработку, но, при необходимости, и различные миграции состояний).

Базовая задача архитектуры: кратко, но ёмко показать, как ИТ-продукт устроен сейчас и что надо изменить, чтобы разработать требуемые хотелки.

Создание неиспользуемых артефактов (частный случай непонимания)

Лежит диаграмма, никто не смотрит.

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

Каждый архитектурный артефакт описывается, чтобы что-то рассказать о вашем ИТ-продукте или изменениях в нём. Он должен приносить пользу, устранять какой-то заметный гэп в понимании. Это позволит четко представлять какие артефакты необходимы и как именно они будут использованы для описания ИТ-продукта и при реализации (разработке) перехода AS IS -> TO BE.

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

Отсутствие быстрого ощутимого результата

Если хочешь идти быстро – иди один, если хочешь идти далеко – рисуй архитектуру.

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

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

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

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

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

Оторванность от реальности

Надо, очень надо, но смотреть не будем.

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

Маркерные фразы: «Мы там сами нарисовали, можешь перерисовать к себе», «У нас АПИ-контракты, которым пользуются разработчики, лежат отдельно от тех, что делают архитекторы», «Да мы уже весь код написали, потом твою архитектуру проревьюем», «Мы уже всё по-другому закодили» и т.п.

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

Незнание типовых нотаций

Рисую быстро, но красиво.

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

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

В первом приближении вам с головой хватит UML, C4 model или Archimate core framework.

Отсутствие сквозных артефактов

Множество копий вместо набора единых состояний.

Это про случай, когда существую десятки, сотни или больше, документов (например, в confluence или miro) где в каждом из них хранятся какие-то разрозненные схемы, диаграммы или даже АПИ-контракты. Поддержание консистентных изменений становится всё дороже и дороже с каждым новым документом.

Что, в конечном, итоге приводит:

• Удорожанию архитектурного процесса (тяжело отслеживать необходимые изменения).

• Отрыву от реальности (появляется всё больше архитектурных представлений, не соответствующих действительности, так как протухли).

В результате получается затратное нечто не приносящее внятной пользы.

Как только начинаются сложности, чтобы по существующим архитектурным артефактам понять AS IS состояние ИТ-продукта, то есть приходится перечитывать пачку документов, чтобы разобраться, что там сейчас актуально – это отличный момент начать работу по вынесению части артефактов (например описание работы основных функций) в сквозной вид.

Мы считаем нормальным, когда в репе с кодом есть главная ветка, где лежит всё актуальное состояние. Но для других артефактов (архитектурных и аналитических) допускаем размазывание по огромному количеству мест.

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

Вместо вывода

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

Потребителями могут быть и разработчики (чтобы реализовать спроектированную логику), и девопсы (чтобы выполнить развертывание), и ИБшники (чтобы проверить на соответствие своим регламентам) и т.д.

Архитектура, как самостоятельный набор артефактов, часто является следствием развития ИТ-системы (или ИТ-продукта), в виде понимания необходимости вынести описание системы в более краткие и информативные сущности. Это потребует изменения процесса разработки, чтобы была возможность поддерживать консистентность между кодом и архитектурными артефактами. Так и до design first недалеко.

А вообще, не берите в голову и просто пишите код, ведь он сам себя не напишет, как и резюме ;)

Удачного дня, мои дорогие коллеги.