Big Ball of Mud Сегодня – про классическую архитектуру и IT-стратегию, без нейронок. Хочется поговорить про Big Ball of Mud не на уровне термина, а на уровне конкретных проявлений. Представьте, – компания быстро растет, выделяется новая структурная единица, например, команда Финансы. Вроде понятный домен. Однако, акцентирую ваше внимание, выделена команда, не домен. Команда наращивает функциональность на работающую систему, без модульного дизайна и явных контрактов. Терпимо, пока система умещается в голове, но вот появляется вторая команда, добавляется координационная нагрузка поверх уже существующей сложности. Потом третья. В какой-то момент команды собираются, чтобы обсудить накопленные проблемы (не функционал) и проявляется следующее: ▪️В процессе обсуждения домены, сервисы и термины снова и снова переопределяются. Почему так? Один и тот же сервис трактуется в разных контекстах по-разному, потому что в нем смешаны модели из разных доменов. Договорились, перешли к следующей теме, снова он возник и снова, внезапно, легитимен в другом смысле. Нет устойчивой модели с явными границами. ▪️Домен может быть размазан тонким слоем по чужой логике. Например, бонусы лояльности. Все понимают, что это отдельная модель, но в реализации ее нет, – только сотни if-else, разбросанных по всему коду Финансов. ▪️Невозможно однозначно определить «как оно работает», потому что, опять же, в каждом месте смешаны разные доменные модели и чтобы разобрать одну, приходится тянуть весь хвост остальных. ▪️И очень конкретный, неявный и частый маркер – управление услугой смешано с исполнением услуги. Добавить новый продукт в поддержку и обслужить клиента по продукту – это разные домены. Добавить новый платежный инструмент и провести платеж – тоже разные домены. Они должны быть изолированы на уровне моделей, но на практике перемешаны. Что измерять? ▪️Cамое простое – Change Coupling. Считаем число доменов/репозиториев/сервисов, затрагиваемых одной фичей. При аккуратных git-коментах с трейсингом до задач в трекере можно взять эпик, посмотреть дочерние таски и собрать статистику изменений. Если p90 высокое и растет – изменения не локализуются. ▪️Число кросс-командных инцидентов, то есть «что ломалось вместе». Самый надежный индикатор при достаточной истории инцидентов. ▪️TTM в разрезе координационных затрат. Доля времени на ожидания, согласования и выяснение «кто владелец/где менять/какие последствия». Имеет смысл фиксировать при >30–40% координационных издержек. Проще всего достается из Kanban-системы, но требует затрат на дисциплину учета, что часто прям сложно достижимо. Итого, экономика BBoM складывается из связанности изменений и затрат на координацию. Риски в IT-стратегии выводятся прямо из метрик ▪️Низкая автономность доменов -> низкая автономность команд -> высокий Cost of Delay при запуске новых услуг. Любой запуск превращается в «сборку из кусочков» со спорными границами. ▪️Стратегические инициативы превращаются в программу работ сразу для нескольких доменов, а границы – спорные ▪️Регуляторные изменения повышают вероятность цепной реакции правок, а границы, все так же – спорные