Волновая модель в продуктовой разработке

Изначально волновая модель была сформулирована как архитектурный паттерн для разработки сложных клиентских приложений и применялась исключительно разработчиками ПО для анализа и поддержки уже существующей кодовой базы. Со временем паттерн развился в полноценную методологию CROSS-F, а также был разработан механизм логгирования операций, что в итоге привело к обнаружению волновой природы информационных взаимодействий. Для анализа волн была разработана принципиально новая аналитическая система Fractalog, «заточенная» под сбор, хранение и обработку не только аналитических событий, но и причинно-следственных связей между ними. Интерференционная картина этих связей позволила выявить в системе новые сущности:

• независимо действующие волновые субъекты (источники волн);
• порождаемые субъектами артефакты (события, которые «запускают» волны).

Описание источников волн и порождаемых ими артефактов позволило сформировать четкие контракты (API) между программными сущностями, которые обеспечивали запуск и распространение волн. Вместе с тем разработчикам и аналитикам не доставало понимания природы (причин) изменений, регулярно возникающих в этих API-контрактах. Как правило, изменения в продуктовых требованиях являлись функцией некоторых бизнес-метрик, что привело к идее также и эти метрики увязать с наблюдаемыми волновыми процессами. Так появилась концепция резонансных информационных взаимодействий и BI-система ResonanceBI, где явление резонанса используется в качестве универсального индикатора эффективности бизнес-процессов.

Таким образом, архитектура CROSS-F позволяет легко извлекать волны, используя структуру кодовой базу, Fractalog обеспечивает интерференционную картину полученных волн, а ResonanceBI опирается на Fractalog в задачах бизнес-анализа. Совокупность этих технологий формирует инструментарий для методологии AIRModel – современного подхода к задачам проектирования, разработки и анализа уже существующих систем. Вместе с тем область применения волновой модели шире: резонансные взаимодействия между волновыми субъектами можно и нужно анализировать на этапе подготовки продуктовых требований.

Проблематика

Конфликт интересов ролей

Общепринятые методологии продуктовой разработки, такие как User Stories или Customer Journey Map, позволяют сформировать требования к разрабатываемой системе, исходя из интересов одной конкретной выбранной роли. Вместе с тем в любой информационной системе всегда задействовано несколько ролей: даже в обычном однопользовательском приложении-блокноте пользователь может выступать как в роли писателя, так и в роли читателя.

Разные User Stories, сформулированные для разных ролей (или даже для одной и той же роли), могут конфликтовать между собой по противоположным целям/метрикам, однако общепринятой методологии устранения таких конфликтов не существует. Как итог сформулированные аналитиком продуктовые требования могут наследовать конфликты интересов описываемых ролей.

Квадратичная сложность

Всякая дополнительная User Story вносит дополнительные логические развилки в общую бизнес-логику. Если система реализована в виде общей state-машины, то каждая бинарная логическая развилка удваивает количество возможных состояний системы, которые нужно закодировать и протестировать. Сложность стейт-машины растет квадратично: O(N^2). При достижении некоторого порогового объема разработка системы становится нерентабельной: стоимость реализации в системе новой User Story начинает превышать потенциальные доход и/или экономию от ее применения.

Волновая модель как решение

Устранение конфликта интересов ролей

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

Если между двумя волновыми субъектами устанавливается устойчивое периодическое взаимодействие, то мы говорим о резонансе. Резонанс означает, что каждому из субъектов выгодно участвовать во взаимодействии: в результате каждой итерации обе стороны фиксируют улучшение своих метрик. Если улучшения метрик хотя бы у одной из сторон не происходит, то периодичность (устойчивость) взаимодействий снижается автоматически. Волновой субъект, эмитирующий волны и не получающий резонансного отклика, рано или поздно потеряет всю свою энергию (израсходует ресурсы) и больше не сможет участвовать во взаимодействиях.

Таким образом, волновая модель предлагает проектировать и разрабатывать резонансные взаимодействия, а не отдельные User Stories. Как бы ни конфликтовали между собой отдельные метрики, резонансное взаимодействие по определению являются компромиссным решением. Самим фактом своего существования резонанс свидетельствует об улучшении индивидуальных метрик обеих сторон.

Устранение квадратичной сложности

Волновая модель позволяет отказаться от общей глобальной стейт-машины с квадратично растущей сложностью O(N^2) в пользу распределенного состояния с ростом сложности O(N * Log N). Такой результат достигается за счет особого подхода к архитектуре, где все акты доступа к состоянию на чтение либо запись инкапсулированы в операциях, на которые налагаются следующие ограничения:

• операции выполняются строго последовательно, одновременное выполнение нескольких операций запрещено;
• операция атомарна и всегда возвращает результат, неопределенный результат операции запрещен.

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

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

• внутренний контекст – собственное накопленное ресурсом состояние;
• внешний контекст – параметры, которые операция передает ему на вход.

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

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

«Зум» сложности через фрактализацию волнового контекста

Сложность каждого отдельного резонансного взаимодействия определяется длиной цепочки операций в вихре. Все вихри в совокупности формируют фрактальную структуру, поскольку всякое волновое взаимодействие по своей природе носит фрактальный, иерархически самоподобный характер. Совокупная сложность всех вихрей растет как O(N * Log N).

Иерархия вихрей основана на иерархии задействованных артефактов. Артефакты позволяют волновым контекстам преодолевать границу между вычислительными волновыми узлами. Например, пользователь клиентского приложения, нажимая на кнопку, взаимодействует с приложением-узлом, получая отклик в виде изображения на экране устройства. Нажатие на кнопку и ответное изображение на экране – это артефакты. Из головы пользователя волновой контекст через артефакт-нажатие попадает в приложение, а из приложения ответный артефакт-изображение возвращается к пользователю. Пользователь видит изображение и обновляет свой контекст. Внутри узла-приложения нажатие порождает цепочку операций, каждая их которых выполняет запрос к некоторому API. В границах узла-приложения эти запросы являются атомарными операциями. Вихрь взаимодействия между пользователем и приложением на этом «уровне зума» может быть описан одной короткой волной, распространяющейся внутри приложения. Вместе с тем каждое из обращений к API на сервере может порождать целый каскад вторичных обращений к микросервисам, кешам, базам данных и т.д. Получается, что на «уровне зума» клиент-серверного взаимодействия исходно атомарная операция уже является отдельным самостоятельным взаимодействием-вихрем. Этот вихрь состоит из набора операций, определенных в границах узла-сервера.

Взаимодействие между пользователем-субъектом и системой можно фрактально «зумить» до тех пор, пока не доберемся до взаимодействия между этой же системой и другим пользователем-субъектом. «Другой» всегда есть, в противном случае существование самой системы-волновода лишено смысла. Каждый из пользователей взаимодействует с системой через приложение, однако при полном развертывании фрактала мы получаем полностью детализированное описание резонансного взаимодействия между парой конечных пользователей.

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

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

Волновая модель как основа для применения ML и LLM

Аналитическая система, отслеживающая цепочки выполняемых операций (волновые трейсы), «из коробки» предлагает размеченный массив данных, подходящий для машинного обучения (ML). Если в рамках выбранного резонансного взаимодействия в конкретном трейсе некоторая операция привела к нарушению периодичности (потере резонанса), то мы автоматически пополняем коллекцию трейсов, «неудачных» в контексте этого взаимодействия. Напротив, если в трейсе наблюдается периодичность, то мы пополняем набор трейсов, «успешных» в контексте выбранного взаимодействия. Доступность размеченных данных позволяет автоматизировать обучение и/или переобучение ML-моделей. Используя обученные модели, мы можем распознавать поведенческие паттерны в режиме реального времени и персонализировать сервис «на лету».

Набор представленных в системе операций формирует некоторый конечный лексический словарь (или алфавит). Всякий волновой трейс можно рассматривать как «текст» из слов, содержащихся в словаре. Описание бизнес-процессов в виде волнового «текста» позволяет воспользоваться алгоритмами обучения больших языковых моделей (LLM). Кроме того, выбор конкретного резонансного взаимодействия естественным образом ограничивает объём контекста, который необходимо передавать на вход модели для генерации предсказания поведения. Получая такой контекст, волновая LLM может сравнительно быстро предсказать «следующий символ», т.е. операцию и/или цепочку операций. Как и в случае с классическим ML, это открывает дорогу к автоматически реализуемой персонализации, в том числе и в режиме реального времени.

Всякая операция в волновом трейсе имеет некоторую семантику, которую формируют разработчики. Доступ к описаниям операций и описанием целевых резонансных взаимодействий позволяет LLM общего назначения «понимать» суть каждого конкретного трейса. Анализ массива трейсов можно выполнять апостериорно, после чего LLM может сформулировать конкретные продуктовые предложения, во-первых, на естественном языке, во-вторых, с привязкой к семантике операций.