«Хорошо определённая проблема - это проблема наполовину решённая». Джон Дьюи.

Спойлер

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

Общий сценарий

Привет, хаброжители! Представьте в самых общих чертах сценарий при старте нового проекта или доработке существующей системы. Команды собирают всевозможные артефакты для изучения контрактов систем, устанавливают контакты – круг заинтересованных лиц и т.д. Далее команды собираются на встречах, где договариваются о дальнейших шагах интеграции. В идеальном случае архитекторы команд начинают взаимодействие с отрисовки контекстов систем и потоков их взаимодействия. Но зачастую на практике обсуждаются только общие моменты интеграции, под протокол фиксируются общие вопросы и команды расходятся с надеждой на уточнения в перспективе. В таком случае команды ожидают ряд рисков и проблем при реализации решения.

Отсутствие понимания границ взаимодействия — это риски

Приведу ряд рисков из практики:

Отсутствие схемы контекстов взаимодействия систем приводит к ряду уточнений архитектуры интеграции или проектирования проекта с нуля. Здесь имеем риски дискоммуникации, множественных встреч по пересмотру архитектуры, вскрытию неочевидных точек взаимодействия при реализации решения, например, взаимодействие сервисов A и B привело к необходимости извлечения данных из сторонней системы, с которой необходимо провести полноценную интеграцию с привлечением заинтересованных сторон и выставлением новых задач.
Отсутствие видения схемы взаимодействия систем при интеграции или границ нового проекта препятствует определению плана работ и привлечения ресурсов. Менеджер проекта не сможет конкретизировать сроки завершения работ.
Если архитектора не привлекали к первоначальной проработке решения в составе всех заинтересованных лиц или не прорабатывали схему контекстов взаимодействия, то возникает риск усложнения проектирования на уровне системного анализа. Аналитик вполне может взяться за архитектурный артефакт, например, построить схему в нотации C0, но есть риск пролонгации валидации схемы, поскольку архитектор не прорабатывал контексты и на уровне архитектуры потребуется ряд уточнений, а тут уже могут всплыть блокеры, которые препятствуют в целом реализации решения.
Финансовый риск очевиден - на все требуется ресурсы. Немаловажно отметить, что командам скорее тоже не понравится работать в хаосе, градус выгорания будет нарастать.
Последствия рисков вполне очевидны. В оптимистичном варианте интеграция или проект выйдут в продуктивный контур в условиях хаоса, но в перспективе придется допиливать технические долг. В худшем варианте развития событий – задача не будет реализована в срок, и компания понесет существенные убытки.

Определяем границы решения

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

Контекстная диаграмма – в общем случае представляет собой набор блоков (систем, сервисов, акторов…) и связей между блоками с указанием данных, которыми обмениваются системы/сервисы/акторы. О контекстной диаграмме и ее назначении очень хорошо написано в книге Карла Вигерса «Разработка требований к программному обеспечению». На практике, к сожалению, ей часто пренебрегают.

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

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

Вариант 1. Простая схема

Простая изображение контекстной диаграммы, не требует детализации

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

Вариант 2. Детализированная схема с архитектурной перспективой

Детализированная схема отображения контекстов взаимодействия систем

Детализированная схема позволяем вам уточнить детали, которые могут быть полезны для построения целевых архитектурных артефактов. Например, если у вас используется нотация C4, то из детализированного варианта отрисовки взаимодействия систем вы достаточно быстро перейдете как минимум к уровням C0, C1.

Избегайте формальностей - главное рисуйте!

Схема из «трех квадратиков» тоже вполне себе контекстная диаграмма, но если там внутри кроются детали, которые привнесут в ваш контекст еще пять «квадратиков», то лучше более детально нарисовать схему.

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

Видится, что если бы у вас была бы элементарная зарисовка проекта, то вам хотя бы наполовину было бы понятно, что вы собираетесь делать. Возможно, это позволило бы вам проверить комплектность деталей, с которыми вы бы реализовали решение. Если бы чего-то не хватило—вы бы сразу зафиксировали проблему и тем самым ускорили бы поиск компромиссов.

Как внедрить практику отрисовки контекстных диаграмм

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

Контекстная диаграмма — достаточно универсальный инструмент.

Итог

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

Желаю вам успехов в проектировании проектов!

Скетч системного дизайна: как одна схема решает множество проблем на старте проекта