Event Storming

Вот так Notebooklm сжал теорию первого дня корп курса по Event Storming, очень хорошо сжал, я бы сказал. Никакой лишней информации нет, так что можно выложить :)

Темпоральность в Event Storming Вчера обсуждали с Геной Кругловым темпоральность в Event Storning, а сегодня выступал перед участниками IN HUB с темой «Картина производственной системы за часы» (домен промышленного производства и смежных отраслей) и был у меня в презентации такой слайд и вчерашнее обсуждение и сегодняшнее выступление привели к новым мыслям. Так вот, на этом слайде сразу четыре темпоральности (авторская интерпретация и она может измениться): ▪️Хаос (Chaotic Exploration) Здесь только темпоральность события как высказывания с точки зрения семантики (по модели Рейхенбаха). События концептуально относены ко времени. ▪️Хронология (timeline enforcement) Это интерсубъективно разделяемая хронология. Ключевой смысл в том, что здесь появляется темпоральность модели как структуры. В самой структуре появляется отношение порядка. Однако, пока только порядка (раньше/позже) и это важно. ▪️Контекст (обогащение модели, в первую очередь через Policy в рассматриваемом контексте) В хронологии появляется своего рода реактивная темпоральность. На самом деле это кусочки реактивной темпоральности. Политики позволяют отличить автоматизированную реактивность от человеческой и вводят критерий верификации модели: Почему эта команда выполняется? При каких условиях? Всегда ли? Отсутствие явных политик делает причинно-следственные связи неявными и модель теряет способность отвечать на вопросы «Почему?» и «В каком случае/когда?» ▪️История (Narrative / Reverse Narrative) А здесь самое интересное. Это нарративная темпоральность (Paul Ricoeur, Джером Брунер), история, общий нарратив, обеспечивает переход от «позже - не значит вследствие» к «это вследствие вот этого». Это усиление темпоральности модели причинно-следственными связями. А теперь прикладной вывод: если мы можем построить согласованную историю, построенную полностью на основе реактивной автоматизированной темпоральности (между каждым событием и командой поставить Policy), то мы можем с большей степенью уверенности говорить, что описанный процесс может быть реализован с помощью автономного ИИ-агента или мультиагентной системы. Однако на текущий момент требуется больше наработок, потому что: ▪️Не факт, что агенты способны интерпретировать все типы Policy ▪️Человеческий контекст и неформализуемые аспекты могут оказать существенное влияние ▪️Техническая реализуемость не следует прямо из концептуальной полноты модели

Формирование рабочей группы по разработке методологии «Стратегического Event Storming» На выходных меня не отпускала мысль, что что-то есть в предложении Юрия Куприянова интегрировать форсайт и Event Storming. Ведь фактически форсайт – это и есть варианты продолжения цепочек событий, но в будущее, а стратегическая сессия – это ограниченитель, фильтр для отбора вариантов. Когда кроссфункциональная команда создает событийную модель, на которой размещаются не только внутренние бизнес-события, но и внешние факторы – изменения в законодательстве, технологические сдвиги, действия конкурентов, макроэкономические тренды, – проявляются паттерны зависимостей между событиями разного масштаба и природы. Визуализация на единой временной шкале событий от глобального до корпоративного уровня создает естественную основу для интеграции с форсайтом – продления событийной модели в будущее, построения альтернативных сценариев и формирования адаптивных стратегий. Интересно, что подобного использования Event Storming практически нет в публичных материалах в международной практике – метод остается преимущественно в пространстве технического проектирования. Мы можем стать первыми, кто систематизирует этот подход и сделает его воспроизводимым инструментом! Что будем делать - Систематизируем опыт - Создадим методологическую базу - Подготовим к публикации - Протестируем Временные затраты 5-15 часов в неделю в течение 3 месяцев (февраль - апрель) Что получите - Соавторство - Опыт создания воспроизводимого метода с нуля - Новые связи среди единомышленников - Возможность применять результаты в своей практике - Что-то свое :) Сам я это воспринимаю как создание чего-то значимого, что будет использоваться другими в том или ином виде. Если вы готовы к серьезной работе с амбициозной целью – буду рад видеть вас в команде. 📝 Ссылка на анкету для подачи заявки на участие (будет отбор): https://forms.gle/WFSX6akDVA6NLqgY7 Дедлайн подачи заявок: 16 января 2026 Отбор и формирование рабочей группы: 16 января - 23 января Kick-off встреча: на неделе с 26 по 30 января PS: если знаете кого-то, кому может быть интересно, перешлите это сообщение :)

Ответ к заданию 1. Не нужно выбирать единый свимлейн на всю модель 2. Вход в модель по каналам (свои события входа, своя модель подтверждения личности, свой UX) 3. После того, как определено намерение клиента (это может быть проблема, информация) - канал перестает иметь значение. 4. После того, как определено, что нужно сделать, в игру вступают продукты – они обозначаются как системы, так как по отношению к предметной области поддержки клиентов они и являются внешними системами. Почему нет свимлейнов по типам клиентов (vip, …)? Тип клиента - это атрибут, а не процесс. Если выделить в отдельный свимлейн, то 90% событий будут дублироваться. Здесь как раз нужны политики (Policy) маршрутизации по типу клиента. Почему нет свимлейнов по продукту? Клиент живет в проблеме, а не продукте, а продукты – вообще внешние по отношению к рассматриваемой предметной области. Проблема «не прошла оплата» может относиться к множеству продуктов.

Разомнемся на выходных? :) Ситуация с которой вы столкнетесь не раз и не два. Итак, представьте. Вы проводите Event Storming в службе поддержки клиентов. Служба поддержки использует 7 каналов взаимодействия с клиентами (телефон, чат, почта, …), клиенты бывают 3 разных типов (vip, обычный+, обычный), количество продуктов на поддержке - 50+. Структуру можно организовать разными способами (слева направо, см пример на картирнке): - Свимлейны с каналами, и для каждого канала свимлейны с продуктами - Свимлейны с продуктами, и для каждого канала внутри свимлейны с каналами - Глобальные свимлейны для типов клиентов, внутри свимлейны для продуктов, внутри продуктов - свимлейны для каналов - … - и еще 11 способов (в том числе с только одним или вообще без свимлейнов) Отмечу, что все структуры будут корректными, они ведь все описывают одну и ту же предметную область, но форма будет отличаться и для конкретного этого примера есть одна наиболее подходящая форма представления. Вопрос: как бы вы визуализировали такую структуру и почему? UPD_1: Денис задал хороший вопрос: «смотря для чего проводим». Это очень правильный вопрос, так как Event Storming – лишь инструмент. Проводим для того, чтобы исследовать предметную область и из текущей реализации вынести специфичную для продуктов логику, тем самым защитив реализацию платформы поддержки от попадания элементов предметной области конкретных продуктов. То есть, чтобы сопоставить модель предметной области и модель текущей реалзации и выявить расхождения.

👆максимально полезно для Event Storming

О полноте стейкхолдеров При принятии решения, особенно при выработке «улучшающего вмешательства» критически важно учесть интересы стейкхолдеров. И не важно – это стратегическое решение или небольшое решение в рамках продукта. Любое решение на кого-то влияет (иначе зачем вы вообще его принимаете?). В этой части книги информация о том, как выявить максимально полное множество стейкхолдеров. От себя добавлю. Это «упражнение» тем проще, чем чаще его проводить. Чем уже скоуп, тем более стабильной будет структура стейкхолдеров. Для конкретного продукта она может меняться буквально на несколько стейкхолдеров от задачи к задаче, для ИТ-стратегии, за счет широты влияния, может меняться значительно сильнее, но и периодичность принятия решений отличается, что дает временнОе пространство для маневра.

Наступает время личных и корпоративных стратегических выборов Стратегический выбор стоит начинать не с выбора решений, а с тщательного исследования Problem Space – что именно является проблемой, для кого и почему это вообще проблема. В связи с этим – полезный материал по изучению проблемы и выбора типов решений (полагаю, Тарасенко для большинства подписчиков моего канала – вовсе не новая фамилия, а для кого новая – рекомендую его работы). Отдельно добавлю про технологическую стратегию. Для нее это означает, что «правильность» выбора направления развития нельзя обсуждать в вакууме. Необходимо явно перечислить стейкхолдеров, их интересы и критерии (качество, риски, скорость, стоимость, комплаенс, …), потому что именно в Problem Space формируются ограничения и критерии будущих решений. Сама идея «улучшающего вмешательства» (никому не хуже, кому-то лучше) полезна как граница для технологических инициатив, то есть хорошая стратегия должна улучшать положение целевых групп и не создавать новых проблем для остальных (безопасность/эксплуатация/финансы/…). Это очень полезные 16 страниц 🚀

Фокус проведения Event Storming В четвертом квартале у меня сильно сместился фокус проведения сессий Event Storming. Причем, не постепенно, а достаточно резко. Проведено много сессий в рамках стратегический сессий, на которых Event Storming выступал как метод формирования общего представления о текущей реальности для того, чтобы сонаправить участников стратегических сессий. Интересно и то, что я не вижу подобного использования Event Storming в международных статьях и выступлениях. Как-будто мы снова проигрываем в международном PR, но при этом развиваем подходы достаточно активно и динамично. Ключевым вопросом, вокруг которого строится весь дизайн, становится: список уязвимых мест компании, которые сильнее всего зависят от внешних и внутренних потрясений и связь инициатив с этими уязвимыми местами. Часто на сессии приходят с уже проработанными уязвимыми местами и инициативами, стратегическая сессия выступает финализацией, способом сонаправить инициативы и заложить механизмы надежности, а Event Storming выступает в качестве карты, на которой отражены все ключевые и значимые для компании события. Представители различных блоков, обычно, хорошо понимают всю систему, однако понимание иногда расходится в детялях, либо упускает один два фактора, например, все учитывают: - Изменения в мировой финансовой системе - Технологические сдвиги - Поведение глобальных конкурентов - Поведение локальных конкурентов Но только часть серьезно учитывает климатическую повестку, и это как раз помогает в установлении сонаправленности. Приведу пример (из прошлого): Ратифицировано Парижское соглашение по климату (внешнее) Федеральный закон «Об ограничении выбросов парниковых газов» вступил в силу (внешнее) Принято обязательство о достижении углеродной нейтральности операционной деятельности (внутреннее) Паттерн: Международное обязательство страны -> Национальное законодательство -> Корпоративная стратегия

Продолжение про «похожие процессы» и про важность DDD. (кажется, получился очень глубокий и важный пост про важность DDD) Конкретным профессиям и их внутренней кухне (туризму, логистике, финансам, медицине) в профильных вузах учат годами. Для тех, кто прошел такой путь, типовые процессы внутри их отрасли выглядят очень похожими: одни и те же шаги, одни и те же риски, одни и те же точки принятия решений. Но есть один нюанс… Взять сферу туризма – это отдельная профессия, ей учатся по пять лет, чтобы нормально разбираться в маршрутах, сезонах, рисках, партнерах и ожиданиях клиентов. И взять разработчика – тоже лет пять только чтобы уверенно писать код, понимать архитектуру, паттерны, инфраструктуру. И вот спец по туризму открывает турфирму. Нанимает сотрудников, поднимает продажи, строит партнерства – бизнес как‑то работает. В какой‑то момент становится тесно в Excel и мессенджерах и он нанимает разработчиков: «пора автоматизировать». Что разработчик, который 5 лет учился на разработчика, знает о туризме? Ну… есть Турция, Египет, самолетом можно долететь, отели бывают с завтраком и без…. У него нет такого же целостного и глубокого представления о процессе, как у эксперта в туризме. Прилетает задача: «сделай бронь места в гостинице, вот тут предоплата, вот тут подтверждение». Он честно реализует эту отдельную фичу. Потом еще одну. Потом «быструю доработку к сезону». Потом срочный костыль «потому что партнер меняет правила». Со временем разработчик, конечно, начинает лучше понимать процесс, картинка становится целостнее…. но к этому моменту система уже обросла заплатками так, что ее страшно трогать. «Сначала требования определяют архитектуру, а затем живут в ней» (c) мой И вот в системе сотня мест, где бизнес-жвачка намотана на технический долг и любая попытка рефакторинга превращается в операцию на сердце. С должным усилием, упорством и желанием этот разработчик вырастает до архитектора. Он наконец смотрит на весь процесс целиком и понимает, что 90% кода можно выбросить и заменить несколькими коробочными продуктами, одним внешним сервисом и небольшим слоем кастома. Потому что реально уникальное – вот эти самые 5%, где и прячется конкурентное преимущество бизнеса, а все остальное – типовой, стандартный Generic. Вот эту проблему во многом и решает DDD вместе с практиками вроде Event Storming. Они как раз про то, как вытащить знание экспертов (в нашем примере – гуру в туризме), перевести его в общий язык и донести до разработчиков и архитекторов так, чтобы все видели одну и ту же цельную картину. Пока этого понимания нет, «в прод идут лишь предположения разработчиков о предметной области» (c) Альберто Брандолини Как только оно появляется – архитектура начинает работать на бизнес, а не наоборот.

Публичный кейс :) https://scrumtrek.ru/cases/eventstorming-v-ecom-tech/

Это из видео про цунами, кому интересно, отсюда - https://www.youtube.com/watch?v=lTxfNHx93hI&t=2203s :)

Вот тут Event Storming и DDD практически вне конкуренции в части эффективности, причем это индустриально подтвержденные подходы.

По просьбам подписчиков попробую пересказать предыдущий пост простыми словами. Онтология отражает язык вашей предметной области, на котором вы разговариваете каждый день в своей работе. Этот язык не нужно придумывать — его нужно «вытащить на поверхность» и оцифровать. Когда вы создаёте онтологию, вы формализуете этот язык, чтобы его одинаково понимали и вы, и ваши коллеги, и машины. В процессе создания онтологии вы и другие эксперты договариваетесь о терминах и делаете неявные знания явными. Одновременно вы создаёте и «скелет» знаний для LLM — основу, на которую модель сможет опираться при решении ваших задач. LLM прекрасно натренированы на синтаксисе формальных онтологий (например, Turtle) и хорошо его понимают. Передавая онтологию в контекст LLM через промпт (in-context learning), вы выполняете «заземление» рассуждений модели (grounding) и резко снижаете вероятность галлюцинаций. Модель буквально начинает говорить на вашем языке. Структура формальных онтологий (тройки субъект-предикат-объект) естественным образом отображается на структуру графовых баз данных. Разрабатывая онтологию, вы фактически проектируете схему вашей будущей графовой базы данных. А дальше — всего один шаг, чтобы начать разговаривать с вашими данными в графовой БД на вашем языке. Отдельный вызов — научиться фреймить контексты, чтобы не перегружать LLM и управлять её вниманием. То есть не просто передавать в модель всю онтологию, а динамически собирать из неё релевантные подграфы — «подъязыки», соответствующие конкретным задачам. О многом из сказанного в этом тексте я уже писал в своих предыдущих постах — и пытливый ум при желании мог воссоздать эту «картину» ещё несколько месяцев назад.

🗓️ Вебинар 30 октября в 19:00 Ведущий: Сергей Баранов Модульность без фанатизма: о чем на самом деле книга Balancing Coupling Встречаемся с Владом Хононовым — архитектором и автором книг «Learning Domain-Driven Design» и «Balancing Coupling in Software Design». Именно об идеях из второй книги мы и поговорим. Этот вебинар пройдет в формате живой беседы-интервью. Обсудим, как находить баланс между связанностью и модульностью, избегать крайностей в архитектурных решениях и почему связанность не всегда зло — иногда она делает систему прочнее. Разберем модель Strength–Distance–Volatility и покажем, как применять эти принципы при проектировании устойчивых распределенных систем. 🚀 Приглашаем архитекторов, тимлидов и разработчиков, которые хотят глубже понять тему модульности. Посмотрим на практические подходы к архитектуре и убедимся, что структурная связанность может стать основой надежности и эволюционного развития системы. 👉 Регистрация по ссылке

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

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

Еще более простая конструкция сбора метаинформации.