Системный сдвиг

Интересный флешмоб: лучшие доклады 2024 года (из тех, что в открытом доступе). Целый канал под это! Если у вас найдется время на новогодних каникулах. Мой вариант — доклад Романа Цирульникова "Модель архитектуры предприятия на графе" с весенней конференции Flow. https://www.youtube.com/watch?v=cMQE_pXA260 (альтернативная ссылка в VK: https://vkvideo.ru/video-214741188_456239295) Мне кажется, это наметки на будущее системного анализа и архитектуры, где-то здесь может быть прорыв в технологическом плане. Раз у нас всё, как код, и архитектура как код, почему бы и требованиям не быть, как код? ;) Или как база данных, к которой можно делать запросы. Рекомендую посмотреть всем аналитикам для расширения понимания о том, что возможно. #лучшийдоклад2024_arch#лучшийдоклад2024_analyst #flowconf Присоединяйтесь, публикуйте самые заметные выступления в своих каналах с хэштегами! Правила флешмоба тут.

#flowconfДенис Бесков. Радикальное ускорение аналитических работ методикой Event Storming. Доклад из двух частей: проблемы классического подхода и Event Storming как метод решения этих проблем. Проблемная лично часть для меня - достаточно понятно и давно известна. Тем не менее, классические постановки по цепочке бизнес - модель бизнеса - требования - модель системы - система по-прежнему широко используются, потому что именно они положены в основу многих методологий. Именно поэтому фокусировка на этих проблемах - ценная часть доклада. Проблемы таковы. 1) Длинная цепочка преобразований, которая идет с искажением информации, особенно когда ситуация в бизнесе меняется в ходе проекта и надо изменить уже проработанные постановки. 2) Интервью с заказчиком дают противоречивую информацию, выявление противоречий и согласование - непросто и небыстро, особенно если интервью параллельно ведут несколько специалистов. 3) Описания бизнес-процессов в формальных нотациях (ARIS, IDEF0, BPMN, UML) непонятны заказчикам, они не могут их верифицировать, при этом создается ложное ощущение полноты информации. То же касается структур данных - диаграмм классов и ER-диаграмм. Впрочем, я лично тут не до конца согласен: да. полные нотации действительно непонятны, но если использовать ограниченные нотации и вести коммуникацию, то верификацию можно получить. 4) Требования часто скрытым образом содержат частные проектные решения, выработанные конкретным аналитиком, и неясно, что в них обусловлено предметной областью, а что - доопределено им произвольно. При этом решения являются фрагментарными, локальными. 5) Функциональные требования дают плохую основу для декомпозиции системы, так как не дают представления о структуре системы. Как эти проблемы решает Event Storming? Прежде всего, он заменяет длительную распределенную коммуникацию краткой синхронной, на встречу собирают представителей бизнеса и разработчиков вместе. Получается общее видение предметной области на общем языке, который разработчики узнают от бизнеса. Вместо процессного представления применяется гораздо более простой формализм: события и реакция на них людей с помощью существующих систем или в ручном режиме. При этом фиксируются проблемные точки и потребности автоматизации. При этом, за счет одновременного присутствия всех представителей бизнеса противоречия быстро вскрываются и обсуждаются на месте. Фиксируется необходимая информация и команды, которые дают люди, а при детальной проработке - агрегаты (бизнес-объекты), с помощью которых организуется процесс. Есть три уровня рассмотрения: на верхнем получается карта событий, роли людей в их обработке и команды, которые они выдают, на втором - события увязываются между собой в цепочки процессов и формулируются правила обработки, а на третьем как раз выявляют агрегаты информации, передаваемые по процессу и хранящие историю. Все это фиксируется с помощью карточек разного цвета, соответствующего разным типам объектов, на большой доске. В докладе были конкретные примеры Дениса из реальных проектах. Отметим, что такое представление о предметной области хорошо совместимо с современными шаблонами реализации. основанными на независимых сервисах, управляемой событиями (event sourcing) и сообщениями, и разделяющем чтение информации и команды (CQRS). Применение начать лучше внутри команды, для синхронизации контекстов и онбординга новичков. А далее можно попробовать с лояльным клиентом на небольшом проекте. получить опыт и расширять использование, делиться с коллегами. Event storming хорошо применим для большинства проектов. В нем нет необходимости для простых систем с CRUD операциями и слабой бизнес-логикой. Для отчетных систем есть модификация model storming - там нужен фокус на данных и их обработке. Источники на русском - Сергей Баранов и Евгений Пешков, на английском - Брандолини и khononov (в процессе перевода).