Привет, Хабр! Меня зовут Олег Сало, я ведущий архитектор MTS Digital в центре IT-продуктов клиентского опыта B2C. Уже достаточно давно я занимаюсь разработкой и проектированием корпоративных информационных систем, в основном в области CRM и Customer Experience.
В больших компаниях архитектура любого уровня (Enterprise/Solution/Application) - всегда предмет горячих споров и обсуждений, как минимум потому, что каждое архитектурное решение затрагивает большое количество команд. И с мнением каждой команды нужно считаться, иначе вероятность превратить архитектуру в работающее решение стремится к нулю.
Сегодня я бы хотел рассказать про такую интересную технику, как Active Design Review, как мы ее попробовали применить у нас в компании и что из этого вышло.
Где проблема?
Типичная ситуация, с которой мы как архитекторы сталкиваемся — это «я придумал какую-то архитектуру, какое-то решение (solution для бизнес-проблемы, архитектуру какой-нибудь распределённой системы, модель данных, архитектурный гайдлайн и т.п.) и хочу его внедрить, хочу, чтобы оно заработало и им начали пользоваться».
Тут есть как минимум две сложности:
Учесть интересы задействованных команд.
Если то, что я спроектировал, реализует множество команд — важно уметь прийти к общему мнению. Между исполнителями, смежными командами, представителями IT-Governance (если они есть). Нужно учесть особенности компонентов решения, направления развития команд и продуктов, правила и ограничения, принятые в компании и т.п.Убедиться в работоспособности решения.
Ошибки проектирования, как известно, самые дорогие, а выявить их очень сложно, особенно на этапе, когда у нас есть только идея, а конкретной реализации, которую можно было бы протестировать, нет.
Итого - нужно как-то убедиться в том, что наше решение непротиворечиво и работоспособно. И сделать это как можно раньше.
Какие варианты решения?
Первый вариант: собираем всех причастных - архитекторов, разрабов, безопасников и запираем на два часа в комнате. Все ругаются, рисуют на флипчартах — отличная атмосфера.
Минусы в том, что часто вообще всех причастных в одной комнате в одно время не соберешь (у каждого свои срочные задачи, спринты горят, календарь забит, «давайте уже после праздников»), да и на доске всё не нарисуешь — все-таки нужен какой-то документ, в котором решение будет описано со всех сторон. А ещё обязательно появится кто-то, кто скажет «вы меня не звали, а я вообще-то против. Мой сервис не учли, решение так себе, ничего не заработает».
Второй вариант, с которым знакомы все, кто работал в большой компании — это классическое согласование документа. Всё описываем в документе/статье в конфлюенсе и просим всех причастных прокомментировать. Здесь плюс, что есть конкретный артефакт (документ), есть история согласований, но минусов куда больше. Тут и рецензенту очень тяжело ничего не забыть, и автору решения сложно свести воедино все комментарии. Ну и не забываем про того самого человека, который не читал, но не согласен. К тому же, такой подход попахивает формализмом.
Active Design Review — а попробуй сделать!
Есть и третий вариант, он называется Active Design Review. Описание этой техники есть в относительно старой научной работе 1985 года. Смысл техники в том, что вопросы задает не тот, кто рецензирует решение, а тот, кто это решение придумал и пытается согласовать. Работает это так.
Сначала готовим формальное описание решения (да, без документа/статьи/схемы тут не обойдётся).
Затем определяем фокус-группу: это все, кого потенциально затронет архитектурное решение.
Для них готовится набор заданий (или в более простом варианте - список вопросов), которые нужно решить.
Потом смотрим на решения или ответы и вносим правки.
Для себя мы сделали примерно так же, только мы использовали практические кейсы. То есть сделали описание архитектуры, придумали кейсы-задания для рецензентов и, не рассказывая ничего о материале, не пытаясь обосновать решение, просто дали людям кейсы, чтобы они их решали. И попробовали собрать их замечания по результатам решения.
Наш регламент, который мы для себя приняли в Active Design Review:
максимально широкий круг участников (есть возможность открытого входа);
максимум публичности внутри команды/компании (освещаем где только можно);
участникам рассказываем только то, где посмотреть само описание;
не обсуждаем архитектуру и не отвечаем ни на какие вопросы до решения кейсов.
Мы публиковали все в Confluence, завели чатик в Telegram и проводили небольшие синки по 30 минут для решения актуальных проблем.
Применяем Active Design Review на практике
На ревью мы выносили достаточно специфическую вещь: концептуальную модель данных клиентского домена. При обсуждении таких штук как модель данных, которую будет использовать вся компания, да ещё и в таком сильно связанном со всеми домене как Customer, всегда у каждого есть что сказать Соответственно, сделать её непротиворечивой и собрать по ней замечания очень сложно. Картинка здесь исключительно для примера, она сильно эволюционировала после ADR.
В качестве фокус-группы мы взяли solution-архитекторов, разрабатывающих сервисы, которые связаны с этим доменом, enterprise-архитекторов и всех желающих. Старались быть максимально публичными, мероприятие пиарили.
Задачи, кейсы, которые мы предлагали решить, мы поделили на три группы.
Реалистичные кейсы — задачи, с которыми сталкиваемся сейчас (обслуживание B2C, обслуживание B2B, продажи и т.д.). Задача — понять, как использовать эту модель на реальном кейсе, в реальных существующих сервисах.
Кейсы на расширение — это то, что у нас на горизонте (например, появление нового вида продукта). Задача — понять как модель поведет себя при развитии нашего ландшафта.
Фантастические кейсы, с большим допущением. Задача - пошатать модель ещё больше, понять, можно ли её «сломать» каким-то противоречием.
Сам кейс — это описание определенной ситуации на обычном человеческом языке, на котором, как правило, и выставляют бизнес-требования. К кейсу даём такие задания: описать эту ситуацию в терминах предложенной модели данных и спроектировать,конкретный сервис/процесс с использованием этой модели. Вот пример самого кейса и задания.
А вот какое решение предложил один из участников. В нем указаны сущности в терминах предлагаемой модели, которые будут затронуты при реализации бизнес-требования, и нарисована диаграмма последовательностей, описывающая, как будет работать конкретный сервис и указаны CRUD-операции над сущностями.
А что в итоге?
В итоге, в первую очередь, мы получили вовлеченность. Если бы эту картинку с КМД я просто заслал тем же людям на e-mail, уверен, что большинство получателей просто проигнорировали бы её. А тут коллеги активно участвовали в обсуждении и действительно погрузились в материал.
Ещё мы получили правки: в процессе решения у коллег возникали противоречия и проблемы (не подходили отношения между сущностями, их кратность, каких-то сущностей не хватало и т.д.) . Так получилось внести в модель более 15 согласованных между всеми (что важно) изменений. Ну и получили набор открытых вопросов — это зона для дальнейшего развития модели. Это тоже результат.
Работа над ошибками
Скажу и про ошибки, которые мы допустили, и каких можете избежать вы, если будете пользоваться техникой Active Design Review.
Выделение ресурсов. Решение задачек всё-таки требует больше времени, чем написание комментариев и у многих просто не получалось выделить нужный временной ресурс. Чтобы это реально работало, нужно несколько раз провести ADR, чтобы для себя и для компании понять, сколько времени эксперты тратят на решение таких задачек и согласовать выделение этого времени заранее.
Живое общение. В современных условиях это довольно сложно, но всё-таки здорово. Наша практика была до пандемии, но мы не встретились ни разу очно, хотя лучше все-таки один-два раза это сделать. Причем оригинальная методика как раз это рекомендует.
Обработка результатов. Нужно формализовать способ обработки и документирования принятых решений. Это самая важная зона развития, которую мы и у себя будем прокачивать, потому что я уверен, что мы эту технику будем дальше применять. Тем, кто заинтересовался ADR, рекомендую сразу подумать на эту тему, потому что в нашем случае к модели данных прилетело огромное количество замечаний и нестыковок, которые, по идее, нужно было учесть.
Вроде бы результат ревью понятен, очевидно, что «здесь надо переделать». Но обсуждение вопроса «как надо переделать» затянулось на продолжительное время и вышло за границы Active Design Review. Чтобы такого не было, нужно заранее продумывать подход, как результаты ADR обрабатывать и готовиться, что результатов будет много.
Но самое главное, что приносит эта методика, на мой взгляд — это радость. В процессе ADR коллеги погрузились в тему модели данных, разбирались в сущностях, связях и в том, как мы их видим едино в компании, решали задачи, рисовали кейсы, сиквенсы, разбирали их. Это было действительно продуктивно и весело. А элемент веселья, как мне кажется — только способствует плодотворной работе, особенно такой рутинной, как согласование архитектурного документа.